Art of MySQL Replication.
Upcoming SlideShare
Loading in...5
×
 

Art of MySQL Replication.

on

  • 16,979 views

hbstudy #13: Art of MySQL Replication.

hbstudy #13: Art of MySQL Replication.

Statistics

Views

Total Views
16,979
Views on SlideShare
16,915
Embed Views
64

Actions

Likes
54
Downloads
374
Comments
1

11 Embeds 64

http://s.deeeki.com 18
http://paper.li 16
http://wiki.onakasuita.org 14
http://192.168.33.10 4
http://a0.twimg.com 3
http://slideshare-download.seesaa.net 3
http://embed.ly 2
http://b.hatena.ne.jp 1
http://www.linkedin.com 1
http://localhost 1
https://twitter.com 1
More...

Accessibility

Categories

Upload Details

Uploaded via as Adobe PDF

Usage Rights

CC Attribution-NoDerivs LicenseCC Attribution-NoDerivs License

Report content

Flagged as inappropriate Flag as inappropriate
Flag as inappropriate

Select your reason for flagging this presentation as inappropriate.

Cancel
  • Full Name Full Name Comment goes here.
    Are you sure you want to
    Your message goes here
    Processing…
  • always read your post, best regards.
    Are you sure you want to
    Your message goes here
    Processing…
Post Comment
Edit your comment

Art of MySQL Replication. Art of MySQL Replication. Presentation Transcript

  • Art Of MySQL Replicaton 〜 10 年の歴史を誇るレプリケーションの妙技〜 奥野 幹也 @nippondanji mikiya (dot) okuno (at) gmail (dot) com
  • 免責事項 ● 本プレゼンテーションにおいて示されている見解は、 私自身の見解であって、オラクル・コーポレーション の見解を必ずしも反映したものではありません。ご了 承ください。
  • 自己紹介 ● 今日は個人として来ています。 – http://nippondanji.blogspot.com/ – Twitter: @nippondanji ● 現職は MySQL サポートエンジニア。 – 2000 年にサン・マイクロシステムズ入社 – 2007 年に MySQL KK へ転職 – 気付くとまたサン・マイクロシステムズに・・・ – 現在は日本オラクルに在席。 ● 日々のしごと – MySQL トラブルシューティング全般 – Q&A 回答 など
  • レプリケーションの 仕組み!!
  • レプリケーションの仕組み
  • レプリケーションの仕組み ● マスターとスレーブが同じデータを持っている。 – 同じデータに対して同じ SQL 文を実行すれば、同じ 結果になるんじゃね? ● 不定なヤツはどうするの?( RAND() とか。) ● マスターの更新はバイナリログに記録する。 – バイナリログってなにもの?! ● スレーブの 2 つのスレッド – I/O スレッド : マスターからバイナリログのデータを 受け取ってリレーログへ記録 – SQL スレッド : リレーログの中身を実行
  • 設定方法概要 ● マスターでバイナリログを有効化 ● マスター上にレプリケーション用のユーザーを作成す る。 ● マスターのデータをスレーブにコピー – mysqldump --master-data=2 ... ● マスターとスレーブで server_id を設定 ● スレーブの設定 – CHANGE MASTER TO ... – START SLAVE;
  • レプリケーション進化の軌跡 ● バージョン 3.23 – シングルスレッド – ステートメントベース ● バージョン 4.0 – バイナリログの受信と適用が別スレッドに ● 遅延の解消! ● バージョン 5.1 – 行ベースレプリケーション – MySQL Cluster レプリケーション ● バージョン 5.5 – Semi-Synchronous!!
  • Semi-Synchronous レプリケーション
  • 免責事項 - その 2 ● 現時点( 2010 年 7 月)の段階では、 MySQL 5.5 は マイルストーンリリース( β 版)です。機能や実装 については、予告無く変更される場合がありますので ご注意ください。
  • トポロジのお話。
  • 利用可能なトポロジ Master/Slave Dual Master Master Slave Master Master Cascading Master Slave Slave Circular 1:N Master Slave Master Master Slave Slave Master
  • さらにその組み合わせ Slave Slave Slave Master Slave Master Slave Slave Master Slave Slave Slave Slave Slave
  • バイナリログ!
  • バイナリログのレイアウト タイムスタンプ 4 バイト タイプコード 1 バイト ヘッダ サーバ ID 4 バイト イベント長 4 バイト 次イベント開始位置 4 バイト イベント フラグ 2 バイト データ 追加ヘッダ 可変長( 0 〜 x ) http://forge.mysql.com/wiki/MySQL_Internals_Binary_Log
  • バイナリログフォーマットの種類 フォーマット 説明 サイズ Non- Trigger determi nistic SBR ステートメント( SQL 文) 小 がそのままバイナリログ に記録される。 × ○ 更新されたデータそのも 大 ○ × RBR のが記録される。 小 ○ MBR SBR と RBR を状況に 応じて切り換える。 △
  • 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
  • SBR でも OK!! ● NOW() – バイナリログに記録されたタイムスタンプを利用する ことで、スレーブでも同じ時刻に! – SYSDATE() は実時間なので非決定性 ● RAND() – シードをバイナリログに記録。スレーブ側ではシード を元に同じ乱数を生成 ● LOAD DATA INFILE – ファイルをスレーブへ転送 ● REPEATABLE-READ – 本来、順番に実行すると同じ結果になるという保証が あるのは SERIALIZABLE だけでは? – Next-key Locking!! ファントムよ、さようなら。
  • InnoDB の分離レベル 分離レベル 分離性 性能 ダーティ 反復不可能読 ファントム リード み取り READ- 低 低 O O O UNCOMMITTED READ- 高 X O O COMMITTED REPEATABLE- 高 X X X READ SERIALIZABLE 高 低 X X X
  • バイナリログの管理 ● 有効化 --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
  • 負荷の分離!
  • マスターから負荷のかかる操作を分離 アプリケーション マスター マスター HA スタンバイ バックアップ スレーブ スレーブ レポーティング
  • ワンポイントアドバイス ● レポート作成中は SQL スレッドを停止しておく。 – STOP SLAVE SQL_THREAD – レポート作成がスムーズに! – バイナリログだけは受け取っておく! ● --dump-slave オプション – MySQL 5.5 の mysqldump コマンドに実装。 – マスター上で --master-data オプションを使ったとき と同じ効果。
  • 特定のデータを捨てる。 マスター スレーブ TABLE 1 TABLE 1 INNODB INNODB TABLE 2 TABLE 2 Black INNODB hole
  • スレーブ de トリガ マスター スレーブ SBR Black INNODB hole トリガなし。 トリガ実行
  • スケールアウト!
  • スケールアウト戦略 更新処理 アプリケーション マスター スレーブ スレーブ スレーブ スレーブ スレーブ スレーブ 参照処理
  • 気合いの多段構成 マスター スレーブ スレーブ スレーブ スレーブ スレーブ スレーブ スレーブ スレーブ スレーブ スレーブ スレーブ スレーブ
  • Sharding 更新処理 マスター マスター マスター スレーブ スレーブ スレーブ スレーブ スレーブ スレーブ スレーブ スレーブ スレーブ スレーブ スレーブ スレーブ
  • High- Availability
  • スレーブを待機系に使う。 ● 利点 – HA と違ってリカバリ不要! ● 超高速フェイルオーバー – レプリケーションはデフォルトで使える機能 ● 課題 – 非同期だから最後に更新したデータを一部失う覚悟が 必要。 – 1:N 構成では昇格に工夫が必要。 – 自動化。 マスター 更新 スレーブ 非同期
  • Semi-Synchronous レプリケーション
  • InnoDB のログを同期しないという選択 ● innodb_fush_log_at_trx_commit=0 ● スレーブに更新が転送されてるから 失うものは何も無い! ● マスタークラッシュ時にはマスターのデータは破棄 – スレーブからデータを再度転送・同期
  • ベンチマーク結果 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
  • スレーブの昇格! ● 何が問題か? – 1:N 構成 ● スレーブ間に差異が生じてしまう。 ● レプリケーションが成立するためには、開始時には 同じデータでなければならない。 ● --log-slave-updates をしても、スレーブのバイナリ ログの位置はマスターの位置とズレがある。 – イベントのサイズが違う!! ● スレーブを自動的に同期する方法はない。
  • スレーブ間の差異:一般的な解決法 ● スレーブ間の差異を無視する。(運がよければ大丈夫・・・) ● マスターの OS が再起動するのを待って、マスター上のバイナ リログから差異を抽出する。 – クラッシュ時にバイナリログが欠損すると使えない。 – --sync-binlog=1 は遅い。 ● スレーブ上のバイナリログを活用する: --log-slave-updates – 頑張ってスクリプト書く書くしかじか?! – Auto-inc カラムを使って目印に。 ● Global Transaction ID – 自動化が出来る素晴らしい!けど・・・ – Google Patch の適用が必要。 – MySQL 5.0 しか対応してないよね・・・
  • スレーブ間の差異をなくす新手順 ● Xid を使おう! – XA トランザクションの ID という意味だが、 XA でな いトランザクションを利用していると、 COMMIT 時にバイナリログに記録される。 – マスターの query_id (単調増加の 64 ビット整数) ● マスターが再起動しない限り ID が被らない! – リレーログにもそっくり同じ Xid が記録される。 ● リレーログの差異を特定できる!!
  • 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 ;
  • 手順その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
  • 手順その2 ● マスターがクラッシュ! – スレーブのデータは同期していない(差分がある)も のとします。 ● 各スレーブのリレーログに含まれる Xid を調べて、 「最も進んでいるスレーブ」を特定する。 – DDL など、 Xid が含まれないイベントが最後尾にある 場合には、イベントの数をカウントする。 – SHOW SLAVE STATUS を使っても OK ● 「最も進んでいるスレーブ」を新たなマスターとし て、更新を開始する。 – 新マスターのバイナリログは、昇格前は空。
  • 手順その3 ● 全てのスレーブにおいて、リレーログの適用が終わるのを 待つ。 ● mysqlbinlog コマンドで、「最も進んでいるスレーブ」の リレーログから各スレーブごとの差分を抜き出す。 ● 差分を各スレーブに適用する。 – 適用が完了した時点ではどのスレーブも同じデータ。 ● CHANGE MASTER TO でレプリケーションを開始! – 新マスターは、昇格する前のバイナリログは空なので、バ イナリログに含まれるのは「昇格後になされた更新すべ て」 – スレーブはバイナリログを最初から全て適用すればよい – CHANGE MASTER TO でファイル名とポジションの指定 が不要!!
  • スレーブ昇格手順の課題 ● mysqlbinlog コマンドは Xid を使って開始位置を指定 することが出来ない。 ● Xid は単調増加ではない。 – query_id は単調増加。 – query_id はクエリ開始時につけられる。 – クエリ終了時点では順序が入れ替わってるかも。 ● 現時点ではまだ PoC – さっさとスクリプト書こうず。 ● 監視
  • ディザスタ リカバリ!
  • 拠点間でレプリケーション! ● データ圧縮!! – slave_compressed_protocol=0 – 貴重な帯域を節約しましょう。 ● 暗号化して送信 – CHANGE MASTER TO で SSL オプションを指定。 – クラウドでも安心! – SSL の設定方法については鍵の本 P.441 を。 ● 非同期で。 – レイテンシーが大きいので Semi-Sync は使っちゃダ メ。
  • 拠点間でレプリケーションの図 インターネット 更新 (圧縮+暗号化) スレーブ マスター 非同期
  • MySQL Cluster!!
  • MySQL Cluster 概要 アプリケーション SQL SQL SQL ノード ノード ノード 管理 NDB API ノード データ データ 管理 ノード ノード ノード データ データ ノード ノード
  • MySQL Cluster Replication SQL ノード 更 新 Binlog write 更新 NDB binlog スレーブ ストレージ Injector エンジン データ データ ● 通常のレプリケーショ ノード ノード ンと同じプロトコル ● RBR のみ ● 競合検出機能 !! データ データ ノード ノード
  • 苦手な JOIN を克服する!! アプリケーション JOIN 更新 マスター スレーブ SQL SQL SQL INNODB ノード ノード ノード データ データ スレーブ ノード ノード INNODB データ データ ノード ノード スレーブ INNODB : :
  • PBXT!!
  • 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
  • 課題!
  • できないこと。 ● 並列化 ● マルチソースレプリケーション ● 行単位でフィルタリング
  • SPIDER ストレージエンジン APP1 APP2 APP3 APP4 n1 n2 n3 n4 SPIDER SPIDER SPIDER SPIDER n5 n6 n7 n8 INNODB INNODB INNODB INNODB
  • パラレルレプリケーション! 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
  • マルチソースレプリケーション Multi Master Master Master Multi Source Master Master Slave
  • 偽マルチソースレプリケーション 更 新 マスター スレーブ 1 スレーブ 2 DB 1 DB 1 DB 1 DB2 DB2 更 新
  • SPIDER によるマルチソース Master Master Slave Slave SPIDER SPIDER Slave INNODB
  • 行単位のフィルタリング マスター スレーブ SBR Black INNODB hole トリガなし。 更新 INNODB トリガ実行
  • まとめ!
  • 様々な利用シーン Master Slave Master 高可用性 バックアップ Slave Slave レポーティング Slave Master Internet Slave Master 圧縮+暗号化 Slave Slave ディザスタリカバリ スケールアウト
  • まとめ MySQL 人気の秘訣 レプリケーションは やっぱり凄かった! デフォルトで使えるのに! 簡単なのに!
  • Q!! & ご静聴ありがとうございました。 A!!