"MySQL 5.7 初心者向けセミナー"に参加した(後半)
レプリケーション編
高可用性構成
重要なのはSlaveはバックアップではないという事です。MasterでDROPしたらSlaveにも伝搬するため、バックアップとしては使えません。 また、マルチソースレプリケーションはn台マスターから、n台のスレーブに反映できます。
レプリケーションの仕組み
MasterDBのbinary logをSlaveサーバに送る、Slaveサーバはrelay_logで受け取り、 relay_logからSlaveDBに反映する。
バイナリログの種類
- SBR(Statement Based Replication)
SQLとPositionが格納されています。
そのため、SYSDATE()など実行タイミングに依存するSQLはレプリケーションに使えません。
ちなみにNOW()とはじめ書いていたが、あれは勘違いでした。資料でもNOW()とは書かれていません。
NOW()の実行結果をバイナリにログに保存しているため、SlaveDBで再度実行される事はありません。
yoku0825.blogspot.jp
- RBR(Row Based Replication)
変更された結果とPosition情報をバイナリログに書き込んでいます。
そのため、UPDATE文でWHEREをつけずに100万行更新した場合に、差分も確保する必要があるため変更前と変更後の200万行分のバイナリログが生成されます。SBRはSQLを出力しているだけのため、1行で済みます。
Position情報を含んでいるという事を失念していましたが、MBRやその他の処理を行う上でPosition情報を更新しないと、障害になるわけで大変重要な事を記載漏れしていました。
- MBR(Mixed Based Replication)
RBRとSBRを状況に応じて切り替えます。
MySQL 5.1.12以降は、デフォルトで採用されています。
5.1系の5.1.12~5.1.28の間だけがbinlog_format=MIXEDがデフォルトでした(5.1のGAは5.1.30なので、GA期間はずっとSTATEMENT) それ以外は5.6とそれ以前でSTATEMENT, 5.7とそれ以降でROWがデフォルトです。
詳しくは追記参照
時間ができた際には切り替え条件を調べたいと思います。
レプリケーション種類
- 非同期レプリケーション
非同期レプリケーションはコミットで返しつつ、裏でレプリケーションを実施します。
- 準同期レプリケーション
relay_logに入れてからコミットします。 言い換えるとrelay_logからSlaveDBには"まだ"反映されていないため、障害発生時に差分が発生する可能性があります。
GTID
MySQL5.6で追加された機能で今後主流になるかもな機能です。
まだ、理解が浅いので実際にサーバを立てる事で理解が進むんじゃないかなと思ってます。
障害発生時にmaster昇格する際にPOSITIONの状況を見て、昇格するGTID(サーバ)を指定する運用になるそうです。
リストア後にはスレーブのauto.cnfを削除します。これはmasterのUUIDが変わるためです。
物理のフルバックアップからリストアした時に、auto.cnfを削除します。 これは既存のスレーブと同じserver_uuid(auto.cnfに保管される)が指定されるのを防ぐためです。
追記参照です。
GTIDが有効な場合にはsql_slave_skip_counterはサポートされませんが、
代替手段があるため、過去やらかした私としては大変ホッとしました。
資料にはそれ以外にも設定情報などが記載されていますが、
これは実際に構築してみないとピンとこなそうなため、今回は割愛。
「mysqlnd_ms」なるエクステンション情報を得たのだけど、PHP7対応がなされていなそうだったのでフィードバックをしました。
まとめ
レプリケーションの設定方法とポイントを学べたのが大変ためになりました。 また、今回のセミナーはOracle様から直接教えて頂き、初心者がDB構築し、レプリケーションの設定まで出来るようになるというとても素晴らしいセミナーでした。インフラエンジニアもさることながら、MySQLを操作する人も積極的に受けた方が良いのではと思いました。
追記
yoku0825さんにアドバイスを頂き、ブログを修正しました。 圧倒的感謝🙇
アンサーソング(?)をしたためましたので、よろしければご確認ください!https://t.co/meSNxkZH4Q
— yoku0825 (@yoku0825) 2017年6月5日