Art of MySQL Replication.

  • 16,010 views
Uploaded on

hbstudy #13: Art of MySQL Replication.

hbstudy #13: Art of MySQL Replication.

More in: Technology
  • Full Name Full Name Comment goes here.
    Are you sure you want to
    Your message goes here
  • always read your post, best regards.
    Are you sure you want to
    Your message goes here
No Downloads

Views

Total Views
16,010
On Slideshare
0
From Embeds
0
Number of Embeds
5

Actions

Shares
Downloads
379
Comments
1
Likes
56

Embeds 0

No embeds

Report content

Flagged as inappropriate Flag as inappropriate
Flag as inappropriate

Select your reason for flagging this presentation as inappropriate.

Cancel
    No notes for slide

Transcript

  • 1. Art Of MySQL Replicaton 〜 10 年の歴史を誇るレプリケーションの妙技〜 奥野 幹也 @nippondanji mikiya (dot) okuno (at) gmail (dot) com
  • 2. 免責事項 ● 本プレゼンテーションにおいて示されている見解は、 私自身の見解であって、オラクル・コーポレーション の見解を必ずしも反映したものではありません。ご了 承ください。
  • 3. 自己紹介 ● 今日は個人として来ています。 – http://nippondanji.blogspot.com/ – Twitter: @nippondanji ● 現職は MySQL サポートエンジニア。 – 2000 年にサン・マイクロシステムズ入社 – 2007 年に MySQL KK へ転職 – 気付くとまたサン・マイクロシステムズに・・・ – 現在は日本オラクルに在席。 ● 日々のしごと – MySQL トラブルシューティング全般 – Q&A 回答 など
  • 4. レプリケーションの 仕組み!!
  • 5. レプリケーションの仕組み
  • 6. レプリケーションの仕組み ● マスターとスレーブが同じデータを持っている。 – 同じデータに対して同じ SQL 文を実行すれば、同じ 結果になるんじゃね? ● 不定なヤツはどうするの?( RAND() とか。) ● マスターの更新はバイナリログに記録する。 – バイナリログってなにもの?! ● スレーブの 2 つのスレッド – I/O スレッド : マスターからバイナリログのデータを 受け取ってリレーログへ記録 – SQL スレッド : リレーログの中身を実行
  • 7. 設定方法概要 ● マスターでバイナリログを有効化 ● マスター上にレプリケーション用のユーザーを作成す る。 ● マスターのデータをスレーブにコピー – mysqldump --master-data=2 ... ● マスターとスレーブで server_id を設定 ● スレーブの設定 – CHANGE MASTER TO ... – START SLAVE;
  • 8. レプリケーション進化の軌跡 ● バージョン 3.23 – シングルスレッド – ステートメントベース ● バージョン 4.0 – バイナリログの受信と適用が別スレッドに ● 遅延の解消! ● バージョン 5.1 – 行ベースレプリケーション – MySQL Cluster レプリケーション ● バージョン 5.5 – Semi-Synchronous!!
  • 9. Semi-Synchronous レプリケーション
  • 10. 免責事項 - その 2 ● 現時点( 2010 年 7 月)の段階では、 MySQL 5.5 は マイルストーンリリース( β 版)です。機能や実装 については、予告無く変更される場合がありますので ご注意ください。
  • 11. トポロジのお話。
  • 12. 利用可能なトポロジ Master/Slave Dual Master Master Slave Master Master Cascading Master Slave Slave Circular 1:N Master Slave Master Master Slave Slave Master
  • 13. さらにその組み合わせ Slave Slave Slave Master Slave Master Slave Slave Master Slave Slave Slave Slave Slave
  • 14. バイナリログ!
  • 15. バイナリログのレイアウト タイムスタンプ 4 バイト タイプコード 1 バイト ヘッダ サーバ ID 4 バイト イベント長 4 バイト 次イベント開始位置 4 バイト イベント フラグ 2 バイト データ 追加ヘッダ 可変長( 0 〜 x ) http://forge.mysql.com/wiki/MySQL_Internals_Binary_Log
  • 16. バイナリログフォーマットの種類 フォーマット 説明 サイズ Non- Trigger determi nistic SBR ステートメント( SQL 文) 小 がそのままバイナリログ に記録される。 × ○ 更新されたデータそのも 大 ○ × RBR のが記録される。 小 ○ MBR SBR と RBR を状況に 応じて切り換える。 △
  • 17. Non-deterministic って? ● 非決定性な SQL 文=実行するたびに結果が変わる可能性 がある。 – UUID() 、 UUID_SHORT() – USER() – FOUND_ROWS() – LOAD_FILE() – SYSDATE() – GET_LOCK() 、 RELEASE_LOCK() – IS_FREE_LOCK() 、 IS_USED_LOCK() – MASTER_POS_WAIT() – SLEEP() – VERSION() – ソートなしの LIMIT 句 – UDF 、非決定性のストアドプロシージャ / ファンクション – INFORMATION_SCHEMA の参照 – READ-COMMITTED/READ-UNCOMMITTED
  • 18. SBR でも OK!! ● NOW() – バイナリログに記録されたタイムスタンプを利用する ことで、スレーブでも同じ時刻に! – SYSDATE() は実時間なので非決定性 ● RAND() – シードをバイナリログに記録。スレーブ側ではシード を元に同じ乱数を生成 ● LOAD DATA INFILE – ファイルをスレーブへ転送 ● REPEATABLE-READ – 本来、順番に実行すると同じ結果になるという保証が あるのは SERIALIZABLE だけでは? – Next-key Locking!! ファントムよ、さようなら。
  • 19. InnoDB の分離レベル 分離レベル 分離性 性能 ダーティ 反復不可能読 ファントム リード み取り READ- 低 低 O O O UNCOMMITTED READ- 高 X O O COMMITTED REPEATABLE- 高 X X X READ SERIALIZABLE 高 低 X X X
  • 20. バイナリログの管理 ● 有効化 --log-bin=binlog ● 一覧表示 SHOW BINARY LOGS; ● 中見 – SHOW BINLOG EVENTS IN 'binlog.000001' – mysqlbinlog binlog.000001 ● 削除 PURGE BINARY LOGS TO 'binlog.000002' ● 自動削除 --expire-logs-days=30
  • 21. 負荷の分離!
  • 22. マスターから負荷のかかる操作を分離 アプリケーション マスター マスター HA スタンバイ バックアップ スレーブ スレーブ レポーティング
  • 23. ワンポイントアドバイス ● レポート作成中は SQL スレッドを停止しておく。 – STOP SLAVE SQL_THREAD – レポート作成がスムーズに! – バイナリログだけは受け取っておく! ● --dump-slave オプション – MySQL 5.5 の mysqldump コマンドに実装。 – マスター上で --master-data オプションを使ったとき と同じ効果。
  • 24. 特定のデータを捨てる。 マスター スレーブ TABLE 1 TABLE 1 INNODB INNODB TABLE 2 TABLE 2 Black INNODB hole
  • 25. スレーブ de トリガ マスター スレーブ SBR Black INNODB hole トリガなし。 トリガ実行
  • 26. スケールアウト!
  • 27. スケールアウト戦略 更新処理 アプリケーション マスター スレーブ スレーブ スレーブ スレーブ スレーブ スレーブ 参照処理
  • 28. 気合いの多段構成 マスター スレーブ スレーブ スレーブ スレーブ スレーブ スレーブ スレーブ スレーブ スレーブ スレーブ スレーブ スレーブ
  • 29. Sharding 更新処理 マスター マスター マスター スレーブ スレーブ スレーブ スレーブ スレーブ スレーブ スレーブ スレーブ スレーブ スレーブ スレーブ スレーブ
  • 30. High- Availability
  • 31. スレーブを待機系に使う。 ● 利点 – HA と違ってリカバリ不要! ● 超高速フェイルオーバー – レプリケーションはデフォルトで使える機能 ● 課題 – 非同期だから最後に更新したデータを一部失う覚悟が 必要。 – 1:N 構成では昇格に工夫が必要。 – 自動化。 マスター 更新 スレーブ 非同期
  • 32. Semi-Synchronous レプリケーション
  • 33. InnoDB のログを同期しないという選択 ● innodb_fush_log_at_trx_commit=0 ● スレーブに更新が転送されてるから 失うものは何も無い! ● マスタークラッシュ時にはマスターのデータは破棄 – スレーブからデータを再度転送・同期
  • 34. ベンチマーク結果 600 sysbench MySQL 5.5.5-m3 Athlon 64 2 Core 500 7200rpm SATA Gigabit Ether 400 単位 : TPS 300 ディスク同期あり ディスク同期なし 200 100 0 Normal Semi-Sync Read-Only
  • 35. スレーブの昇格! ● 何が問題か? – 1:N 構成 ● スレーブ間に差異が生じてしまう。 ● レプリケーションが成立するためには、開始時には 同じデータでなければならない。 ● --log-slave-updates をしても、スレーブのバイナリ ログの位置はマスターの位置とズレがある。 – イベントのサイズが違う!! ● スレーブを自動的に同期する方法はない。
  • 36. スレーブ間の差異:一般的な解決法 ● スレーブ間の差異を無視する。(運がよければ大丈夫・・・) ● マスターの OS が再起動するのを待って、マスター上のバイナ リログから差異を抽出する。 – クラッシュ時にバイナリログが欠損すると使えない。 – --sync-binlog=1 は遅い。 ● スレーブ上のバイナリログを活用する: --log-slave-updates – 頑張ってスクリプト書く書くしかじか?! – Auto-inc カラムを使って目印に。 ● Global Transaction ID – 自動化が出来る素晴らしい!けど・・・ – Google Patch の適用が必要。 – MySQL 5.0 しか対応してないよね・・・
  • 37. スレーブ間の差異をなくす新手順 ● Xid を使おう! – XA トランザクションの ID という意味だが、 XA でな いトランザクションを利用していると、 COMMIT 時にバイナリログに記録される。 – マスターの query_id (単調増加の 64 ビット整数) ● マスターが再起動しない限り ID が被らない! – リレーログにもそっくり同じ Xid が記録される。 ● リレーログの差異を特定できる!!
  • 38. Xid イベント BEGIN /*!*/; # at 174 #100723 0:21:27 server id 1 end_log_pos 269 Query thread_id=8 exec_time=0 error_code=0 use test/*!*/; SET TIMESTAMP=1279812087/*!*/; insert into t2 values(1),(2),(3) /*!*/; # at 269 #100723 0:21:27 server id 1 end_log_pos 296 Xid = 73 COMMIT/*!*/; DELIMITER ;
  • 39. 手順その1 ● 前提 – 1:N 構成 – XA トランザクションは使用しない。 – InnoDB を利用する。 ● リレーログの設定 – リレーログを一定期間保存: relay_log_purge=0 – 合計サイズの上限: relay_log_space_limit=1G – 各ファイルサイズ: max_relay_log_size=64M – ファイル名を分かり易く: relay_log=relay-bin – スレーブのバイナリログは空にしておく: log_slave_updates=0
  • 40. 手順その2 ● マスターがクラッシュ! – スレーブのデータは同期していない(差分がある)も のとします。 ● 各スレーブのリレーログに含まれる Xid を調べて、 「最も進んでいるスレーブ」を特定する。 – DDL など、 Xid が含まれないイベントが最後尾にある 場合には、イベントの数をカウントする。 – SHOW SLAVE STATUS を使っても OK ● 「最も進んでいるスレーブ」を新たなマスターとし て、更新を開始する。 – 新マスターのバイナリログは、昇格前は空。
  • 41. 手順その3 ● 全てのスレーブにおいて、リレーログの適用が終わるのを 待つ。 ● mysqlbinlog コマンドで、「最も進んでいるスレーブ」の リレーログから各スレーブごとの差分を抜き出す。 ● 差分を各スレーブに適用する。 – 適用が完了した時点ではどのスレーブも同じデータ。 ● CHANGE MASTER TO でレプリケーションを開始! – 新マスターは、昇格する前のバイナリログは空なので、バ イナリログに含まれるのは「昇格後になされた更新すべ て」 – スレーブはバイナリログを最初から全て適用すればよい – CHANGE MASTER TO でファイル名とポジションの指定 が不要!!
  • 42. スレーブ昇格手順の課題 ● mysqlbinlog コマンドは Xid を使って開始位置を指定 することが出来ない。 ● Xid は単調増加ではない。 – query_id は単調増加。 – query_id はクエリ開始時につけられる。 – クエリ終了時点では順序が入れ替わってるかも。 ● 現時点ではまだ PoC – さっさとスクリプト書こうず。 ● 監視
  • 43. ディザスタ リカバリ!
  • 44. 拠点間でレプリケーション! ● データ圧縮!! – slave_compressed_protocol=0 – 貴重な帯域を節約しましょう。 ● 暗号化して送信 – CHANGE MASTER TO で SSL オプションを指定。 – クラウドでも安心! – SSL の設定方法については鍵の本 P.441 を。 ● 非同期で。 – レイテンシーが大きいので Semi-Sync は使っちゃダ メ。
  • 45. 拠点間でレプリケーションの図 インターネット 更新 (圧縮+暗号化) スレーブ マスター 非同期
  • 46. MySQL Cluster!!
  • 47. MySQL Cluster 概要 アプリケーション SQL SQL SQL ノード ノード ノード 管理 NDB API ノード データ データ 管理 ノード ノード ノード データ データ ノード ノード
  • 48. MySQL Cluster Replication SQL ノード 更 新 Binlog write 更新 NDB binlog スレーブ ストレージ Injector エンジン データ データ ● 通常のレプリケーショ ノード ノード ンと同じプロトコル ● RBR のみ ● 競合検出機能 !! データ データ ノード ノード
  • 49. 苦手な JOIN を克服する!! アプリケーション JOIN 更新 マスター スレーブ SQL SQL SQL INNODB ノード ノード ノード データ データ スレーブ ノード ノード INNODB データ データ ノード ノード スレーブ INNODB : :
  • 50. PBXT!!
  • 51. Engine Level Replication? 更 新 マスター スレーブ ● MVCC Snapshot Transfer ● Asynchronous Replication ● Synchronous Replication – Real-time feedback – No log fush binlog relay-log – Bi-directional PBXT PBXT http://pbxt.blogspot.com/2010/03/pbxt-engine-level-replication-works.html
  • 52. 課題!
  • 53. できないこと。 ● 並列化 ● マルチソースレプリケーション ● 行単位でフィルタリング
  • 54. SPIDER ストレージエンジン APP1 APP2 APP3 APP4 n1 n2 n3 n4 SPIDER SPIDER SPIDER SPIDER n5 n6 n7 n8 INNODB INNODB INNODB INNODB
  • 55. パラレルレプリケーション! APP1 APP2 APP3 APP4 n1 n2 n3 n4 SPIDER SPIDER SPIDER SPIDER n5 n6 n7 n8 INNODB INNODB INNODB INNODB slave slave slave slave INNODB INNODB INNODB INNODB SPIDER slave
  • 56. マルチソースレプリケーション Multi Master Master Master Multi Source Master Master Slave
  • 57. 偽マルチソースレプリケーション 更 新 マスター スレーブ 1 スレーブ 2 DB 1 DB 1 DB 1 DB2 DB2 更 新
  • 58. SPIDER によるマルチソース Master Master Slave Slave SPIDER SPIDER Slave INNODB
  • 59. 行単位のフィルタリング マスター スレーブ SBR Black INNODB hole トリガなし。 更新 INNODB トリガ実行
  • 60. まとめ!
  • 61. 様々な利用シーン Master Slave Master 高可用性 バックアップ Slave Slave レポーティング Slave Master Internet Slave Master 圧縮+暗号化 Slave Slave ディザスタリカバリ スケールアウト
  • 62. まとめ MySQL 人気の秘訣 レプリケーションは やっぱり凄かった! デフォルトで使えるのに! 簡単なのに!
  • 63. Q!! & ご静聴ありがとうございました。 A!!