スライド 1

Transcription

1 1

2 MySQL レプリケーション最新実装解説 日本オラクル株式会社山崎由章 / MySQL Senior Sales Consultant, Asia Pacific and Japan 2

3 以下の事項は 弊社の一般的な製品の方向性に関する概要を説明するものです また 情報提供を唯一の目的とするものであり いかなる契約にも組み込むことはできません 以下の事項は マテリアルやコード 機能を提供することをコミットメント ( 確約 ) するものではないため 購買決定を行う際の判断材料になさらないで下さい オラクル製品に関して記載されている機能の開発 リリースおよび時期については 弊社の裁量により決定されます Oracle と Java は Oracle Corporation 及びその子会社 関連会社の米国及びその他の国における登録商標です 文中の社名 商品名等は各社の商標または登録商標である場合があります 3

4 5.6 での強化ポイント パフォーマンス マルチスレッドスレーブ スレーブの行検出アルゴリズムの追加 バイナリログのサイズ削減 バイナリログ書込み時のロック削減 バイナリログのグループコミット フェイルオーバー & リカバリ グローバルトランザクションID(GTID) mysqlfailover mysqlrepladmin ユーティリティ クラッシュ後の不完全なバイナリログを自動修復 クラッシュセーフなスレーブ 信頼性向上 チェックサムの追加 開発生産性 運用性向上 MySQL レプリケーションユーティリティ サーバUUIDの生成 バイナリログへの追加情報出力 スレーブが使用するNICの指定 バイナリログのリモートバックアップ 遅延レプリケーション 4

5 レプリケーションの基礎 5

6 レプリケーション MySQL の標準機能 シンプルな設定 マスター スレーブ 多数 Web での実績 非同期型 or 準同期 特長 参照性能を向上させる構成 バックアップ用途での利用も 基本は一方向でのデータコピーだが 双方向や循環型での利用も可能 ( データの更新には注意が必要 ) 更新ログ (bin-log) を利用 Web アプリケーションでは参照が 95% ( Digg.com ) 更新が 5% というケースも > シンプルなスケールアウト構成によって簡単に 20 倍以上の性能向上が図れる 6

7 非同期レプリケーション 7

8 準同期レプリケーション 8

9 MySQL レプリケーションの構成パターン マスタ > スレーブマルチマスタ > スレーブ ( マルチソース ) マスタ > マルチスレーブ マスタ < > マスタ ( マルチマスタ ) マスタ > スレーブ > マルチスレーブ 循環型 ( マルチマスタ ) 9

10 パフォーマンス 10

11 マルチスレッドスレーブ スレーブの SQL スレッドを複数起動可能 slave_parallel_workers オプションで設定 複数の worker thread が起動し SQL スレッドはコーディネーターとして動作 並列化の単位はスキーマ ( データベース ) マルチテナントシステムと相性がいい マスターとスレーブでは トランザクションの実行順序が異なる可能性がある データベース内での整合性は保証されている 複数データベース間での整合性は 結果整合性 (eventual consistency) 11

12 マルチスレッドスレーブ Transaction apply path at the slave. 12

13 マルチスレッドスレーブ 5 倍の性能向上 Sun Fire X4170 M2 Server 64bit OEL GB RAM 2 sockets, 6 cores with hyperthreading, 2930MHz Workload: Sysbench (10 schemas, 1 table/schema) 13

14 スレーブの行検出アルゴリズムの追加 1 つの行イベントが複数行を変更する場合がある 行を特定するのに最も適切なインデックスが使われる 主キー ユニークキー (NULL を含まない ) 通常のインデックス テーブルスキャン 行の特定に新しいアルゴリズムが追加された : HASH_SCAN インデックスが無い場合の複数回のテーブルスキャンを回避する スレーブスレッドのアルゴリズムを選択する方法 ( 少なくとも 2 つのアルゴリズムを指定する ) 14

15 スレーブの行検出アルゴリズムの追加 INDEX_SEARCH : インデックスを使って行を探す ( インデックスが使える場合 ) TABLE_SCAN : テーブルスキャンを使って行を探す HASH_SCAN : 多くとも1 回のテーブルスキャンでイベント内の全ての行を探す delete update 処理時に影響する (insert 処理は行の特定が不要 ) 15

16 バイナリログのサイズ削減 RBR(Row Based Replication) の場合 バイナリログへの記録内容を変更可能 binlog_row_image オプションで設定 (full, minimal, noblob) full の場合 変更前 / 変更後の全カラムのイメージを保持 ( 従来のフォーマット ) noblob の場合は BLOB 列を省き minimal の場合は主キーと変更された列のイメージのみを保持する メモリ使用量 ネットワーク転送量 ディスク使用量を削減可能 レプリケーションを正しく反映するために 以下の点に注意 テーブル定義を同一にする 主キーを付ける 16

17 バイナリログのサイズ削減 17

18 バイナリログ書込み時のロック削減 MySQL 5.1 全てのイベントはシリアライズされて書込まれ 書込みの間ログロックが保持される MySQL 5.5 DDL とトランザクションの境界となるイベントがシリアライズされて書込まれ 書込みの間ログロックが保持される MySQL 5.6 イベントはシリアライズされ ログロック無しで書込まれる ( インシデントイベントを除く ) 18

19 バイナリログのグループコミット Session T1 T3 T2 T4 Binary Log 複数トランザクションの情報をまとめてバイナリログに記録 Sync_binlog=1 の場合のオーバーヘッドを削減 Master Database Group commit バイナリログコミット部分のソースをリファクタし よりメンテナンスしやすいコードに改善 19

20 Q u e r i e s p e r S e c o n d バイナリログのグループコミット T h r e a d s M y S Q L N o B i n l o g M y S Q L s y n c _ b i n l o g = 1 M y S Q L 5. 6 J u n e - s y n c _ b i n l o g = 倍の性能向上 (5.6.5 のバイナリログ未設定時との比較 ) 3.5 倍の性能向上 (5.6.5 のバイナリログ設定時との比較 ) Sysbench R/W 8 x Socket / 6-core Intel Xeon 7540, 2GHz 512GB RAM Sync_binlog = 1 SSD 20

21 Queries Per Second バイナリログのグループコミット Threads MySQL 5.6 June No Binlog MySQL 5.6 June - sync_binlog = 0 MySQL 5.6 June - sync_binlog = 1 平均 11% のオーバーヘッド (sync_binlog = 1 との比較 ) 0%-10% のオーバーヘッド (sync_binlog = 0 との比較 ) Sysbench R/W 8 x Socket / 6-core Intel Xeon 7540, 2GHz 512GB RAM SSD 21

22 フェイルオーバー & リカバリ 22

23 グローバルトランザクション ID(GTID) 複数台のレプリケーション環境でも容易にトランザクションの追跡 / 比較が可能 トランザクションを一意に識別できる識別子をバイナリログに記録 フェイルオーバーのために 最も最新のスレーブを自動認識 多段構成のレプリケーションが容易に Slave Master GTID= GTID= Slave Slave GTID= GTID=

24 グローバルトランザクション ID(GTID) コミット時に GTID が生成される server_uuid:number a61678ba e58-45ba840af334:1 server_uuid によって サーバを一意に識別できる number は 各サーバ単位でトランザクション毎に 1 ずつ増加する GTID はバイナリログに記録される GTID によって スレーブによるトランザクションの再実行を防ぐ 24

25 グローバルトランザクション ID(GTID) フェイルオーバー トポロジ変更時の動作 ( 例 : マスターを変更 ) スレーブは新しいマスターに実行が完了している GTID を伝える で実行が完了した GTID を確認できる 確認例 ) マスターの変更時 ポジションは自動的に認識される 管理の手間削減 CHANGE MASTER TO MASTER_AUTO_POSITION = 1 25

26 グローバルトランザクション ID(GTID) mysqlfailover mysqlrepladmin ユーティリティ mysqlfailover レプリケーショントポロジの監視 フェイルオーバー mysqlrpladmin 計画停止時のスイッチオーバー 参考情報

27 クラッシュ後の不完全なバイナリログを自動修復 マスターのクラッシュ後 破損したバイナリログでは適切にリカバリができない バイナリログに部分的にイベントが記録されている状態 インデックスファイルが破損すると 適切なログファイルを見つけ出せない インデックスファイルに部分的にエントリが記録されている状態 27

28 クラッシュ後の不完全なバイナリログを自動修復 MySQL 5.6 では 自動的にバイナリログの破損部分を取り除く トランザクションはバイナリログの内容に従って ロールバック / コミットされる MySQL 5.6 では サーバは自動的にインデックスファイルを更新する 28

29 クラッシュセーフなスレーブ ポジションの情報はファイルに格納されている master.info relay-log.info スレーブサーバにおいて Commit と fsync の間でクラッシュが起きたら? ポジションとデータのミスマッチが発生 リカバリ時に 間違ったポジションからログを適用してしまう 手動でポジションを修正するか スレーブの再セットアップが必要 29

30 クラッシュセーフなスレーブ master.info relay-log.info の情報を InnoDB 上のテーブルに格納可能 データとポジションの情報をトランザクショナルに書込み可能 master-info-repository relay-log-info-repository で設定 スレーブサーバがクラッシュしても マスターとの同期が崩れない より強靭なレプリケーション環境が構築可能 30

31 信頼性向上 31

32 チェックサムの追加 バイナリログにチェックサムを記録可能 (CRC32) binlog-checksum オプションで有効 / 無効を制御 マスターは バイナリログにイベントを記録する時に CRC32を生成 複数個所で誤り検出可能 マスターとスレーブでの誤り検出は 個別に有効 / 無効の設定が可能 (master-verify-checksum option slave-sql-verify-checksum ) イベント毎に CRC を記録 Binary Log File 32

33 チェックサムの追加 誤りが早期に検出されることにより データの破損を防ぐ 誤り発生個所をより正確に特定可能 (disk network memory) サポート時間の削減 内部テストでは チェックサム使用時に大きなオーバーヘッドは検出されず (STATEMENT ROW MIXED の全てにおいて ) 33

34 開発生産性 運用性向上 34

35 MySQL レプリケーションユーティリティ Check Repl Show HA Python スクリプトで実装された各種ユーティリティを提供 スクリプトをカスタマイズ可能 MySQL Workbench のプラグインとして GPLv2 ライセンスで提供 ダウンロード先 dev.mysql.com/downloads/workbench/ Windows 版の必要要件 dev.mysql.com/resources/wb52_prerequisites.html 35

36 MySQL レプリケーションユーティリティ mysqlrplcheck : レプリケーション要件の確認 mysqlreplicate : 新しいサーバへのレプリケーションスレーブ設定 mysqlrplshow : レプリケーション構成の可視化 mysqlfailover and mysqlrpladmin : ステータスの監視 問題の発見とフェイルオーバー 36

37 サーバ UUID の生成 各サーバが自動的に UUID(Universally Unique Identifier) を生成 データディレクトリの auto.cnf ファイルに記録 MySQL Enterprise Monitor のレプリケーショントポロジ自動検出機能が強化 複雑なレプリケーション構成でもサーバの識別が容易に show slave status の Master_UUID で マスターの UUID を確認可能 37

38 バイナリログへの追加情報出力 RBR(Row-Based Replication) 利用時 その更新の元になったステートメントに関する情報をバイナリログに記録可能 binlog_rows_query_log_events で制御 レプリケーションの追跡 / デバッグに役立つ 38

39 スレーブが使用する NIC の指定 スレーブが複数の NIC を持っている場合 マスターとの接続に利用する NIC を選択できる CHANGE MASTER TO コマンドの MASTER_BIND オプションで指定 39

40 バイナリログのリモートバックアップ mysqlbinlog コマンドを使って リモートサーバのバイナリログをコピー可能 バイナリログのコピーのために SSHの設定不要 最新のバイナリログをコピーし続けることも可能 接続先ホストを自ノードに設定すれば 自ノード内でバイナリログをコピーすることも可能 ( バイナリログのバックアップとしての利用 ) レプリケーションを利用したリアルタイムでのバックアップがより容易に 40

41 バイナリログのリモートバックアップ 実行例 指定したバイナリログ (binlog ~000132) をコピー mysqlbinlog --read-from-remote-server --host=host_name --raw binlog binlog binlog 指定したファイル以降に生成されたバイナリログを全てコピー mysqlbinlog --read-from-remote-server --host=host_name --raw --to-last-log binlog 指定したファイル以降に生成されたバイナリログを全てコピーし その後生成されたファイルもコピーし続ける mysqlbinlog --read-from-remote-server --host=host_name --raw --stop-never binlog

42 遅延レプリケーション 42

43 遅延レプリケーション スレーブ側でのデータ更新を任意の時間遅らせることが可能 CHANGE MASTER TO コマンドのMASTER_DELAY オプションで 秒単位で指定可能 特定のスレーブだけ遅延させることが可能 使用例 遅延が発生している状況を想定したシステムテスト デバッグ マスター側でのオペレーションミス対策 バックアップを利用しなくても過去のデータを確認可能 (1 日前のデータをスレーブから確認 など ) 43

44 まとめ 44

45 MySQL 5.6 では レプリケーション機能が大幅に機能強化 グローバルトランザクション ID(GTID) MySQL レプリケーションユーティリティ バイナリログのグループコミット MySQL の標準機能だけで 高可用性 高パフォーマンスなシステムを柔軟に構築可能 45

46 参考資料 Enabling the New Generation of Web and Cloud Services with MySQL 5.6 Replication Eliminating Downtime with MySQL Replication MySQL Replication Utilities: Video Tutorial MySQL 5.6 Replication - Enabling the Next Generation of Web & Cloud Services 46

47 The world's most popular open source database 世界で最も普及しているオープンソースデータベース 47

48 48

49 49