第二世代のMySQL 5.6にデータを書き込むプロジェクトがあります。
マスターの書き込み動作:1秒あたり平均70回の書き込み操作。実は1日2回、アプリケーションは毎回3時間にわたってデータを書き込みます。そして、それぞれが毎秒2500オペレーションを書き込みます。
この書き込み操作が原因でレプリケーションの遅延が止まらないと思います。レプリケーションの遅延が始まると、回復できません。レプリカのソース(CPUとメモリ)を増やしても機能しません。
レプリカを同期させるにはどうすればよいですか?マスター/スレーブアーキテクチャは、この書き込み操作のソリューションではないと思います。
マスタースレーブの代わりに、より大きなマスターを読み取りと書き込みの両方の操作に使用する必要がありますか?
ありがとうございました。
現在のマスター:4CPU 15GB RAMおよび900GB SSD
現在のレプリカ:8cpu 30gb ramおよび900gb ssd
[〜#〜]編集[〜#〜]
これは、1つのトランザクションで50kの挿入が行われるように発生します。レプリケーションは行ベースです。インサートはバッチ処理できます。マスターには他のデータベースが存在しますが、すべての操作は単一のデータベースに行われます。 5.7へのアップグレードはおそらく可能です。
スーパー特権のためグローバル変数を設定できないため、外部リードレプリカを作成しようとしています。あなたが説明するように、私はマルチスレッドレプリケーションとinnodb_flush_log_at_trx_commitの並列ワーカーを増やします。
また、許可された最大パケット数を試します。遅延したレプリカは破棄されます。したがって、以下のステータスと変数はマスターを表しています。
これはAmazon RDSで多く発生します。これは、行ベースのレプリケーションで発生し、マスターが大量の書き込みでハンマー処理され、1つのI/Oスレッドにシリアル化されます。
あなたがすべきことは、動的に以下を変更することです:
SET GLOBAL innodb_flush_log_at_trx_commit = 2;
問題は、Amazon RDSでもGoogle CloudSQLでも許可されていない [〜#〜] super [〜#〜] 特権が必要なことです。 Amazon RDSの場合、DBパラメータグループ(MySQLインスタンスのサーバーオプションのリスト)の値を変更します。 Google CloudSQLプラットフォームのオプショングループを使用して動的オプションを変更できる場合、これは変更するオプションです。レプリケーションが回復したら、1に戻します。
Rick Jamesによって投稿された回答 は、CloudSQLインスタンスに複数のデータベースがある場合に最適です。彼は言った
すべての操作が単一のデータベースに入る? 5.6以降にアップグレードする可能性があります。マルチスレッド複製が役立つ場合があります。
今のところ動的オプションを変更して、現在のレプリケーションラグを取り除いてみてください MySQL 5.7を使用するという彼の提案を試して、マルチスレッドレプリケーションを長期的なソリューションとしてセットアップしてください 。
My.cnf-ini [mysqld]セクションで検討すべき提案
innodb_log_file_size=2G # from 512M to reduce log rotations
innodb_log_buffer_size=256M # from 8M for ~15 minutes in RAM
max_connections=200 # from 4000 - max used in 56 days was 72 concurrent
thread_cache_size=100 # from 48 to support volume
read_rnd_buffer_size=192K # from 256K to lower handler_read_rnd_next RPS
key_cache_age_threshold=64800 # from 300 seconds to lower key_reads RPS
key_cache_division_limit=50 # from 100 for Hot/Warm cache
key_cache_block_size=16384 # from 1024 to reduce CPU overhead
innodb_change_buffer_max_size=15 # from 25 percent to reduce CHG set aside
innodb_flushing_avg_loops=10 # from 30 to reduce delay in loop
innodb_lru_scan_depth=128 # from 1024 to reduce CPU every SEC see V8 refman
innodb_purge_threads=4 # from 1 to support higher activity rate
innodb_write_io_threads=64 # from 4 to expedite WD
max_write_lock_count=16 # to allow RD after nn write lock requests vs up to 4 Billion
sort_buffer_size=2M # from 256K to reduce sort_merge_passes of ~ 500,000
sTATUSカウントからの観測、 A)最大1億のcom_rollbackイベントがカウントされます。 B)リソースを解放するための一致するリリースがない368 com_savepointアクティビティ。 C)〜1100万のhandler_rollbackイベントがカウントされます。 D)リソースを解放するための一致するリリースがない476 handler_savepointアクティビティ。 E)〜3100万の接続から〜800万のaborted_clients
その他の観察については、連絡先情報のプロファイルを確認し、Skypeに連絡してください。
(コメントに対する質問が多すぎます)
どれどれ SHOW CREATE TABLE
とサンプル操作。いくつかの手掛かりがあるかもしれません。
大規模なバッチはどのように実行されますか? 1回の書き込みにつき1つのトランザクション?または、1回のトランザクションで100万回の挿入を行いますか?またはその間に何か?
行ベースのレプリケーション? InnoDB?
インサートは「バッチ処理」できますか?またはそれは LOAD DATA
?
すべての操作が単一のデータベースに入る? 5.6以降にアップグレードする可能性があります。マルチスレッド複製が役立つ場合があります。
調整する価値のある調整パラメータはほとんどありませんが、これらを各サーバーに提供できれば、より多くの手掛かりが得られる可能性があります(上記の質問のいくつかへの回答を含む)。 (post.itまたは他のサイトを使用してください。これらはここに収まりません。)
SHOW GLOBAL STATUS;
SHOW GLOBAL VARIABLES;