Amazon Aurora MySQL v3からv2に逆方向のレプリを貼ってみたら一応動く

技術本部 サービスリライアビリティグループ(SRG)の鬼海(@fat47)です。
#SRG(Service Reliability Group)は、主に弊社メディアサービスのインフラ周りを横断的にサポートしており、既存サービスの改善や新規立ち上げ、OSS貢献などを行っているグループです。
本記事は、SRG 内にある DBWG(DBワーキンググループ)が全社内向けに提供しているデータベースに関する資料を公開します。
なにかの役に立てば幸いです。
 

!! 注意 !!


この記事の内容はMySQL的にもAWS的にも非推奨の構成となっています。
あくまでも動いたよという報告なのでご注意ください。

逆方向のレプリ?


Aurora Version3をSource、Version2をReplicaとしてクラスタ間でレプリを貼っている状態です。
v2からのバージョンアップ作業で、v2へ切り戻しを行いたいとなったときの為に非推奨ではあるが逆行したバージョンのレプリケーションを貼ります。
 

素のMySQLだと普通に逆方向のレプリ組むとエラーになる


過去にこのブログで記事にしたことがあります。
 
MySQL8.0をSource、MySQL5.7をReplicaとしてレプリケーションを組むと、レプリケーションはエラーですぐに停止してしまいます。
これはMySQL5.7にはcollationのが組み込まれていないが、MySQL8.0から流れてくるbinlogファイルには (utf8mb4_0900_ai_ci)が指定されるので、エラーになってしまうという理由になります。
 
これを回避するには、MySQL8.0の設定に下記を指定することで、collationのデフォルトの挙動をutf8_general_ciに固定する必要があります。
ちなみにですがAuroraではdefault_collation_for_utf8mb4の設定は適用できません。

Aurora MySQLだとなぜ大丈夫なのか


こちらも過去に記事の記事から一部抜粋します。
 
Aurora Version2(MySQL5.7互換)には、本来のMySQL5.7には入っていないcollationのutf8mb4_0900_ai_ciが独自に実装されています。
 
そのため、Aurora v3をSourceとしてAurora v2をReplicaにしたレプリケーションを構成しても、
collationのエラーでレプリケーションが停止することはないのです。

終わりに


あくまでもこれらは非推奨の方法となりますので、ご注意ください。
 
SRG では一緒に働く仲間を募集しています。 ご興味ありましたらぜひこちらからご連絡ください。
 
このエントリーをはてなブックマークに追加