Googleクラウドアカウントのチャージ: GCP Cloud SQL主従同期中断とRead Replica超高遅延トラブルシューティングガイド
先週の夜中の3時、PagerDutyのアラームベルが沈黙を破った: オンラインのあるコア業務のRead Replica遅延が3600秒(1時間) に直行し、読み取り専用ノードのクエリが頻繁にエラーになった主従が同期しているとすぐに完全に切断されます。
Google Cloud SQL (MySQLでもPostgreSQLでも) に依存して読み書き分離アーキテクチャを構築するチームにとってはリード・レプリカの遅延が急増したり、同期が中断されたりすることは、最も厄介な問題の一つである。
GCPで長年ピットを踏んできたSREとして、この文章を通して皆さんを現場に戻し、整理します。
リアルで着地可能なCloud SQLレプリケーション遅延のトラブルシューティングと最適化のプロセス
。
一、現象の復活: 故障はどのように発生したのか?
通常、レプリケーション遅延の急増には、次の2つの典型的な表現があります
温水煮カエル型: Google CloudコンソールのCloud SQL監視パネルで、replica_769指標は45度の角度で上昇し続けている。
断崖雪崩型: メインライブラリは非常に時間のかかる一括更新を実行し、ライブラリから突然同期を停止したり、読み取り専用ノードのWAL/Binlogがメインライブラリに追いつけなくなったりして、直接コピーチェーンが中断された。
この問題を調査するには、まずGCPの基礎的なコピーロジックを明らかにする必要がある。
二、核心原理の簡単な分析: Cloud SQLの同期メカニズム
Cloud SQL for MySQL: GTIDベースの行レベル・レプリケーション (Row-basedreplication)。メインライブラリはBinlogに書き込みを記録し、ライブラリのIO ThreadからBinlogを引き出し、SQL Thread (またはParallel Workers) はローカルでの再生を担当します。
Cloud SQL for PostgreSQL: ストリーム・レプリケーション (ストリーム・レプリケーション) に基づいています。メインライブラリはウォールライトアップし、ライブラリのウォールレシーバーから受信し、ウォールstartup/Replayプロセスによって適用されます。
メインライブラリの書き込みと同時性が非常に高い場合、またはライブラリからこれらの変更をタイムリーに適用できない場合、遅延が発生します。
三、四歩の調査法: 同期遅延を招く犯人を見つける
数千秒の遅れに直面して、盲目的にライブラリから再起動してはいけない。読み取り専用ノードを再起動すると、ローカルバッファが失われ、再Replayが遅延を悪化させる可能性があります。次の手順に従って、段階的にトラブルシューティングしてください
1.リソースのボトルネックをチェックする: マスタスレーブ仕様は対等ですか?
これは80% の初心者が最も踏みやすい穴です。お金を節約するために、多くの人はメインライブラリを作るのが好きです
16vCPU/64G、ライブラリからは2vCPU/8Gしか与えられていない。
問題点: メインライブラリは高同時CPUで大量の書き込みを簡単に処理できるが、ライブラリからリソースが限られている場合、シングルスレッド (または限られたマルチスレッド) でBinlog/WALを再生することはできないCPUは100% に直接当たることが多い。
トラブルシューティング方法: Cloud Monitoringで、ライブラリからのCPU使用率とDisk I/O Utilizationを確認します。
2.主ライブラリ上の大きなトランザクションと「主キーなしテーブル」を検索します
大トランザクション (Large Transactions): 誰かがメインライブラリでDELETE FROM orders WHERE status = 0を走って500万件のデータを削除した。MySQLでは、このトランザクションはメインライブラリがコミットされた後にスレーブライブラリに配布され、ライブラリからこの大きなトランザクションを再生している間、後続のすべての同期がブロックされます。
プライマリ・キー・テーブルがありません: Row-Basedレプリケーション・モードでは、大きなテーブルにプライマリ・キーがない場合、プライマリ・ライブラリが1つのレコードを更新するには、テーブル全体をスキャンするだけですしかし、ライブラリから再生するときは、ローの変更ごとに全表スキャンが必要です! 10000行の更新がある場合、倉庫から10000回の全表スキャンを実行する必要があり、遅延が直接空に飛ぶ。
3.ライブラリから長いクエリロックの競合はありますか?
読み取り専用ノードは、データを同期するだけでなく、サービスのRead要求にも応答しています。
PostgreSQLでは、ライブラリから10分の時間をかけてSQLを分析していて、メインライブラリから渡されたWALがSQLが読み取っているテーブルを修正した場合、競合が発生します。PostgreSQLのmax_standby_streamたまらないパラメータ構成によると、ライブラリからクエリが完了するのを待って、WALのアプリケーションを一時停止します。
MySQLでは、ライブラリ上の大きなクエリからテーブルロックまたは暗黙的なロックを保持し、SQL Threadの書き込みをブロックする可能性があります。
4.ネットワークと地域間の遅延をチェックする
リード・レプリカがオフサイトに導入されている場合 (たとえば、メイン・ライブラリは東京にあります)
Asia-northeast1
,ライブラリからシンガポール
Asia-southeast1
) 、地域間のネットワークのジッターと物理的な遅延が直接長くなる
Network_lag
。
四、極速止血と根治方案
上記の列で検出された原因に対して、我々は以下の手段で迅速に処理することができる
1.緊急止血: 動的昇配と検索殺プロセス
ワンクリックで一時的にライブラリからアップグレードする: メインライブラリを変更することなく、GCPコンソールでRead ReplicaのvCPU/
メモリはメインライブラリと一致して (メインライブラリよりも少し高い) 、十分なCPUとI/Oリソースを提供して進捗を急いでいます。
Killライブラリからの遅いクエリ: ライブラリからリソースを占有する複雑な分析SQLが見つかった場合は、思い切ってKillします。
生産口座の安定性を保証する: クラウドでこれらの緊急拡張と高規格インスタンスの調整を行うとき、必ずクラウド資源と料金の状態が正常であることを保障する。多くの企業は財務審査プロセスが煩雑で、突発的な流量に直面して資源を急速に拡大する必要がある場合、クレジットカードの限度額が不足したり、口座番号が不足したりして操作が失敗することが多い。このような気まずさを避けるために、多くの運送次元と財務チームは専門のクラウドサービス業者を通じてgoogleクラウドアカウントのチャージを行い、公的な支払い、前払い、国内の領収書を発行するなどの方法で柔軟に限度額を補充することを選択します故障応答の肝心な時にいつでも高く配置できるようにします。
2. MySQL特別最適化: 並列レプリケーションをオンにする
Cloud SQL MySQLは、デフォルトで並列再生パフォーマンスを最大限に発揮していない可能性があります。Flagを変更することで、並列レプリケーションを有効にすることができます
レプリカ・キャリパー (またはスラブ) をライブラリからのvCPUの数と一致する値に設定します。
レプリカ _ キャリパー _ ルタイプ = キュロット _ クロックの設定に合わせて、ライブラリからBinlogを適用する効率を大幅に向上させます。
3. PostgreSQL特別最適化: クエリと同期のトレードオフ
PG Read Replicaの遅延が非常に高いのは、クエリの競合が原因である場合は、ライブラリのdatabaseflag sから次のパラメータを調整してみてください
Max_standby_streamぐるぐるとすると、同期の競合が発生した場合、システムは読み取り専用のクエリを優先的にキャンセルして、同期のリアルタイム性を確保することを意味します。
4.業務層の変更: 大規模な単体事務を避ける
大規模なUPDATEまたはDELETE操作をバッチ・バッチ・コミットに分割します。
厳格な規範データベース作成表の規範: すべての表にプライマリ・キーが含まれている必要があります。
五、まとめ
GCP Cloud SQLのRead Replica遅延トラブルシューティングは本質的に
リソース、同時性、ロック
のゲーム。遅延アラームが発生した場合は、「
仕様のチェック-> 大きなトランザクション/主キーの確認-> 従属ライブラリロックの競合の排除-> データベースFlagの調整/一時的なアップグレード
「この組み合わせ拳は、ほとんどの同期問題が解決できる。
ホルダー
組織の科学性、運輸資源の充実性、データベース規範の厳格さは、業務を安心させるための不二法門である。
