システムの高可用性/耐障害性は、すべてのシステム操作および保守担当者が非常に懸念しているトピックです。高可用性がうまく機能して初めて、地域のシステム災害に落ち着いて対処できます。そして、データは保護する必要があるコアです。
AWSクラウドプラットフォームデータベースに基づいて、どのような高可用性アーキテクチャ設計を行うことができますか？
現在中国には、北京と寧夏という2つの独立した地域があります。RDSについては、マルチAZを構成できるだけでなく、AWSはRDSのリージョン間マスタースレーブ同期もサポートしています。
今日は、Mysqlベースの高可用性/災害耐性アーキテクチャのパフォーマンステストについて説明します。
1.レプリカスレーブを作成する
2.ここでは、「北京リージョン」または「寧夏リージョン」にレプリカスレーブを作成することを選択できます。
3.北京と寧夏回族自治区の間の距離が原因で、誰もが北京マスターと寧夏回族自治区レプリカの同期について心配することになりますが、ネットワークの遅延により遅れは大きくなりますか？
今日は、ネットワーク遅延がマスターとスレーブの同期にどの程度影響するかを確認するテストを実施します。
（注：北京リージョンと寧夏回族自治区の間には直接の接続はありません。つまり、顧客のEC2または他のサービスのリージョン間データ同期は、パブリックネットワークまたは自分で準備した専用回線を介してのみデータを送信できます。ただし、AWS内では、 RDSのマスタースレーブ同期と S3のクロスリージョンレプリケーション機能のための専用ラインを 提供し、各アカウントに特定の帯域幅を提供します）
テスト環境の準備、
<1。EC2 m4.xlarge（4CPU 16G） <2。RDS db.r4.xlarge（4CPU 16G）Mysqlバージョン5.7.12 <3。主に同期を比較するために、Ningxia と北京に1つずつ、2つのレプリカを作成します。状況、ネットワーク要因の違いの確認と区別 <4。Mysqlは20個のテーブルを作成し、各テーブルには1000Wのデータ行があり、データ量は約40G 未満<5。メインライブラリはストレステストにsysbenchを使用し、sysbenchの使用方法のリファレンス： https：// blog.51cto.com/hsbxxl/2068181 <6。メインライブラリのパラメーターを変更する binlog_format = row <7。ライブラリから次のパラメーターを設定して、5.7 slave_parallel_workers = 50のリレー作業の同時パフォーマンスを使用する
4. sysbenchスクリプト
タイミングタスクを通じて、sysbenchスクリプトを5分ごとに実行します。 ＃crontab -l * / 5 * * * * /root/test.sh は、毎回150 秒実行し、50セッションは、それぞれ1000W行の20テーブルを同時に読み書きします。データ ＃cat test.sh 日付>> sync.log sysbench /usr/share/sysbench/tests/include/oltp_legacy/oltp.lua \ --mysql-host = bjs.cbchwkqr6lfg.rds.cn-north-1.amazonaws。 com.cn --mysql-port = 3306 \ --mysql-user = admin --mysql-password = admin123 --mysql-db = testdb2 --oltp-tables-count = 20 \ --oltp-table-size = 10000000 --report-interval = 10 --rand-init = on --max-requests = 0 \ --oltp-read-only = off --time = 150 --threads = 50 \ run >> sync.log
5.メインライブラリでのsysbenchテストデータ出力は次のとおりです。出力に基づいて、メインライブラリの読み取りおよび書き込みデータを参照用に決定できます。
[10秒] thds：50 tps：1072.24 qps：21505.53（r / w / o：15060.08 / 4296.37 / 2149.08）lat（ms、95％）：89.16 err / s：0.00 reconn / s：0.00 [20s] thds：50 tps：759.83 qps：15195.04（r / w / o：10640.78 / 3034.21 / 1520.05）lat（ms、95％）：215.44 err / s：0.00 reconn / s：0.00 [30s] thds：50 tps：631.10 qps：12645.47 （r / w / o：8853.55 / 2529.71 / 1262.21）lat（ms、95％）：262.64 err / s：0.00 reconn / s：0.00 ...... [130s] thds：50 tps：765.94 qps：15295.77 （r / w / o：10701.91 / 3062.27 / 1531.59）lat（ms、95％）：125.52 err / s：0.00 reconn / s：0.00 [140s] thds：50 tps：690.08 qps：13776.96（r / w / o ：9636.39 / 2761.41 / 1379.16）lat（ms、95％）：150.29 err / s：0.00 reconn / s：0.00 [150s] thds：50 tps：749.51 qps：15033.64（r / w / o：10532.97 / 3000.45 / 1500.22 ）lat（ms、95％）：147.61 err / s：0.00 reconn / s：0.00 SQL統計： 実行されたクエリ： 読み取り：1458030 書き込み：416580 その他：208290 合計：2082900 トランザクション：104145（689.50 /秒） クエリ：2082900（13790.04 /秒） 無視されたエラー：0（0.00 /秒） 再接続：0（0.00 /秒） 一般統計： 合計時間：151.0422 秒 イベントの合計数：104145 待ち時間（ミリ秒）： 最小：8.92 平均 ：72.39最大：7270.55 ：72.39 95パーセンタイル：167.44 合計：7538949.20 スレッドの公平性： イベント（avg / stddev）：2082.9000 / 18.44 実行時間（avg / stddev）：150.7790 / 0.44
次に、北京と寧夏の2つのレプリカの同期を見てみましょう。
6.インジケーターレプリカラグ（ミリ秒）
北京と寧夏のレプリカの同期パフォーマンスは基本的に同じで、150秒の書き込みサイクルごとに遅延が増加し、基本的な遅延は約40〜50秒です。これは、北京のレプリカとマスターが同じAZの同じサブネットにあるため、ネットワークがボトルネックになっていないことを示しています。
北京
寧夏回族自治区
7.上の図の結果によると、マスターとスレーブの遅延が、Mysql自体の再生プロセスによる遅延に追いついていないことが分析できます。
そこで、2つのレプリカのRDSモデルを8CPU 32Gにアップグレードしてテストし、結果を比較しました。
モデルのアップグレードが引き続き役立ち、遅延が大幅に減少し、遅延が20〜30秒に維持されていることがわかります。
北京
寧夏回族自治区
また、北京と同じラグを維持しています。これは、ネットワークが同期のボトルネックではないことを示しています。Mysql自体の再生ログはパフォーマンスのボトルネックです。
8. CPU使用率を再度観察します
2つのレプリカには同期されたデータの負荷のみがあるため、同期されたデータのパフォーマンス消費はわずか15％であることがわかります。
後者の曲線は、8CPU 32Gにアップグレードした後のわずか7.5％の負荷です。ハードウェアリソースは十分であることを示していますが、Mysql自体の理由により、同期ラグが発生します。
北京
寧夏回族自治区
9. IOPSを書き込む
4000前後で安定しており、実際には6000 IOPSを割り当てているため、ディスクはボトルネックになりません。さらに、マスターライブラリは読み取りおよび書き込み操作を完了することができますが、理論的には、スレーブライブラリは書き込み操作のみを実行し、負荷は低くなります。物理ハードウェアリソースは制限ではありません。
北京
寧夏回族自治区
10.メインライブラリのパフォーマンスインジケーターから、同じ構成に対してメインライブラリのリソースがまだ十分であることがわかります。読み書きのニーズを満たすことができます。
CPUパフォーマンスインジケーター
11. IOPSパフォーマンスインジケーターの記述
12. IOPSパフォーマンスインジケーターの読み取り
13.スループットパフォーマンスインジケーターを書き込む
14.データベースはリソースをホストしているため、ネットワークはボトルネックになりません。次に、Mysql自体の問題、徐々に調整する必要があります。
次に、mysqlのパラメーターを調整して最適化します。
上記の最適化は、スタンバイデータベースの関連パラメーターの影響を最小限に抑え、基本的にすべてのIO関連パラメーターを閉じ、OSレベルのメカニズムに従って注文を行うことです。
実際、レプリカのデータセキュリティ要件はマスターデータベースの要件よりもはるかに小さいため、スレーブデータベースの同期速度が遅い場合は、実際の状況に応じて以下のパラメーターを調整すると大きな効果があります。
innodb_flush_log_at_trx_commit = 0 innodb_flush_neighbors = 0 innodb_flush_sync = 0 sync_binlog = 0 sync_relay_log = 0 slave_parallel_workers = 50 master-info-repository = TABLE relay-log-info-repository = TABLE
15.チューニング後の結果
寧夏回族自治区
パラメータを調整した後、40秒の遅延から約5秒の遅延効果がすぐに現れます。
16.北京のレプリカをもう一度見てください（Mysqlパラメーターは調整されていません）。
以前のラグは引き続き維持され、遅延は50秒に維持されます。
北京
17.最後に、パラメーターを調整してワーカーを並列にします。デフォルトでは、このパラメーターはデータベースです。つまり、複数のデータベースが変更された場合にのみ、ワーカーは並列で動作します。実際には、ほとんどの顧客は1つのデータベース（スキーマ）に複数のテーブルを持っています。したがって、パラメーターをLOGICAL_CLOCKに変更して、並列の役割を果たすようにします。
slave_parallel_type ＝ LOGICAL_CLOCK
ワーカーが並列の場合、マスター/スレーブの遅延は2S以内に減らすことができ、基本的にほとんどのビジネスシナリオを満たすことができます。
18.テストの概要
以下の条件に基づく
ハードウェア：4CPU 16Gメモリ6000IOPSディスク
同時50の場合、毎秒700 TPS、1.5W QPS、1W書き込み。
Mysqlのマスターとスレーブは、北京から寧夏まで10秒以内に遅延を制御できます。
レプリカのデータセキュリティ要件が比較的高い場合、つまり、Mysql配置のパラメーターを調整しない場合、遅延は40〜50秒の範囲になります。
実際の状況によると、mysqlパラメータを調整してレプリカモデルを増やすことで、より良い同期パフォーマンスを得ることができます。
オープンソースのRDBMSとして、MysqlはOracleの技術サポートで大きな進歩を遂げました。ただし、OracleのDataguardの同期と比較すると、レプリカのパフォーマンスには依然として大きなギャップがあります。
Mysqlをより高速に同期させる方法については、引き続き調査します。
19. Mysqlマスター/スレーブ同期のチューニングについて：
<1。MySQLデータベースのマスター/スレーブ同期遅延原理。
回答：MySQLデータベースのマスターとスレーブの同期遅延の原則について述べると、まずmysqlデータベースのマスターとスレーブのレプリケーションの原則から始める必要があります。MySQLのマスターとスレーブのレプリケーションはシングルスレッド操作です。マスターデータベースはすべてのDDLとDMLのバイナリログを生成し、binlogは順次書き込まれます。 、したがって、効率は非常に高いです。ログをフェッチするためのメインライブラリへのSlave_IO_Runningスレッド、効率は非常に高く、次のステップ、問題が発生します。スレーブのSlave_SQL_Runningスレッドは、スレーブのメインライブラリのDDLおよびDML操作を実装します。DMLとDDLのIO操作はシーケンシャルではなくランダムであり、コストがはるかに高くなります。また、スレーブの他のクエリに対してロック競合が発生する可能性があります。Slave_SQL_Runningもシングルスレッドであるため、DDLカードマスターの実行には10分かかります。その後、後続のすべてのDDLはこのDDLの実行を待機してから続行し、遅延が発生します。「メインライブラリの同じDDLも10分間実行する必要があります。スレーブが遅延するのはなぜですか？」答えは、マスターは同時実行できますが、Slave_SQL_Runningスレッドは同時実行できないということです。
<2。MySQLデータベースのマスタースレーブ同期の遅延はどのように発生しますか？
回答：メインライブラリのTPS同時実行性が高い場合、生成されるDDLの量がスレーブのSQLスレッドが耐えられる範囲を超えると、遅延が発生します。もちろん、スレーブの大きなクエリステートメントでロック待機が発生する場合があります。
<3。MySQLデータベースのマスター/スレーブ同期遅延ソリューション
回答：スレーブ同期遅延を減らす最も簡単な解決策は、アーキテクチャを最適化し、メインライブラリのDDLをすばやく実行することです。sync_binlog = 1、innodb_flush_log_at_trx_commit = 1など、より高いデータセキュリティを備えたメインライブラリも記述されていますが、スレーブはそのような高いデータセキュリティを必要としません。sync_binlogを0に設定したり、binlogをオフにしたりすることは完全に可能です。 innodb_flushlogを0に設定して、sqlの実行効率を向上させることもできます。もう1つは、メインライブラリよりも優れたハードウェアデバイスをスレーブとして使用することです。
参照文書：
https://www.cnblogs.com/cnmenglang/p/6393769.html
https://dev.mysql.com/doc/refman/5.7/en/replication-options-slave.html