12
5

Delete article

Deleted articles cannot be recovered.

Draft of this article would be also deleted.

Are you sure you want to delete this article?

More than 5 years have passed since last update.

Aurora小ネタ/MySQLレプリケーションでのしくじりポイント

Last updated at Posted at 2017-07-23

先に、**オンプレMySQL~RDS for MySQL/Aurora間のレプリケーションにおけるタイムゾーン設定**という記事を書きましたが、それ以外にもAuroraでのMySQLレプリケーションでいくつか問題に遭遇しましたので、書き残しておきます。

しくじり1. そもそもレプリケーションが開始できない

Auroraがマスターになるケースで、

  • バイナリログの出力をON(MIXEDまたはROW)にした
  • バイナリログの保存期間も設定した(mysql.rds_set_configurationプロシージャで)
  • スレーブに対してREPLICATION SLAVE・REPLICATION CLIENT権限を付与した
  • スレーブ側でCHANGE MASTER TOコマンドはエラーにならずに通った

にもかかわらず、スレーブ側でSTART SLAVE後にレプリケーションが開始されない場合、セキュリティグループやNACL、ルートテーブル、(オンプレ環境にレプリケーションする場合)オンプレ側のファイアーウォールポリシーなどのネットワークの問題ばかり気にしがちですが(実際、そちらに原因があることも多い)、

「MySQLのレプリケーションで設定可能なマスターホスト名は60文字までである」

という制限に引っかかっていることもあります。

東京リージョンでAuroraのクラスターエンドポイント(IPアドレスではなくFQDN指定で)を使う場合、

  • 読み書き可能 : 【クラスター識別子】.cluster-XXXXXXXXXXXX.ap-northeast-1.rds.amazonaws.com
  • 読み取りのみ : 【クラスター識別子】.cluster-ro-XXXXXXXXXXXX.ap-northeast-1.rds.amazonaws.com

ということで、クラスター識別子以外の文字数が、前者で54文字、後者で57文字もあります。

つまり、「クラスター識別子を極端に短く設定しないと、クラスターエンドポイントをMASTER_HOSTに指定できない」(指定できるけど動かない)ということになります。

このクラスターエンドポイント、パブリック公開しない(=プライベートIPアドレスが返る)場合でも外部から引くことができるので(RFC的にどうなの?というツッコミは一旦置いておいて)、オンプレ環境のスレーブサーバーとVPN等経由でレプリケーションする場合にも便利なのですが、こういうトラップもありますので、注意しましょう。

なお、最初のほうにさらっと、

  • バイナリログの保存期間も設定した(mysql.rds_set_configurationプロシージャで)

と書きましたが、この設定を忘れると(何事もなくレプリケーションを開始できてしまうのですが)予期せぬタイミングでレプリケーションが続行不能になる可能性があるため、こちらも注意が必要です(単位は日数ではなく時間=hours)。

8/1追記:
コメントをいただきましたので補足します。
この件について回避策は書かなかったのですが(理由は**「状況によって最適解が変わってくるから」**です。極端な話、「特定のインスタンスのIPアドレスを直接指定する」というのが最適なケースもあると思います)、コメント欄に参考になる情報へのリンクを載せておきましたので、必要であればご覧ください。

しくじり2. レプリケーションが途中で止まる

こちらも、原因は色々ありますが(レプリケーションを開始するときのマスター/スレーブの状態に差があった、読み込むバイナリログの開始ポジションを誤った、マスター側/スレーブ側でアクセス権限に差があるのに、うっかりマスター側にしか存在しないユーザーを変更/削除しようとした、など)、

「Auroraでは、MySQL(5.6)の既知のバグが全てフィックスされているわけではない」

点に注意が必要です。

私の場合、MySQLのBug #69861(MySQL 5.6.15でBug #17234370とともにフィックス)に引っかかって、

[1]オンプレ ⇒ [2]Aurora ⇒ [3]オンプレ

の環境で、[3]オンプレへのレプリケーション時に**「LAST_INSERT_ID()の実行結果が0になる」**不具合に遭遇しました。

[2]のAuroraでバイナリログの形式をMIXEDからROWに変更することで解決しましたが、このようなレアなユースケース(まさか、AuroraをMySQLレプリケーションの「中継サーバー」に使うとは、AWSの中の人も思わない…?)で問題になるようなバグはフィックスされていない可能性があるので、本家MySQLのChangelogとAuroraのバグフィックス情報を見比べて確認しておいたほうが良いでしょう。

[参考]

2018/4/19追記:
Bug #69861はバージョン1.17(2018/3/13リリース)でFixされました。


【おまけ】
Amazon Aurora関連投稿記事へのリンクを集めました。

12
5
5

Register as a new user and use Qiita more conveniently

  1. You get articles that match your needs
  2. You can efficiently read back useful information
  3. You can use dark theme
What you can do with signing up
12
5

Delete article

Deleted articles cannot be recovered.

Draft of this article would be also deleted.

Are you sure you want to delete this article?