データベース

MySQLクラスタにおけるデータベース・レプリケーションの一貫性とスプリットブレインの理解

私がどのようにしているか レプリケーションの一貫性 MySQLのセットアップにおいて、些細なネットワーク障害でさえもスプリットブレインを引き起こす可能性がある理由を説明します。レプリケーション、一貫性モデル、クォーラムメカニズムがどのように連動し、エラーシナリオを素早く封じ込めることができるかを実践的な方法で説明します。.

中心点

まず、優先順位を正しく設定できるように、最も重要なガイドラインを要約する。 リスク を評価する。すべてのトポロジーの決定は一貫性、レイテンシー、回復性に影響するため、意識的に評価し、文書化する。クォーラム、書き込みガイダンス、フェイルオーバー・ルールは、アクティブ・ノードをめぐる争いを防ぎ 筆記負荷 クリーンなチャンネル。.

一貫性の目標 明確に定義する（RPO/RTO、リード・アフター・ライト）
トポロジー 適切なものを選択する（プライマリレプリカ、マルチマスター、クラスタ）
定足数 セキュア
フェイルオーバー 厳格な制御（読み取り専用、VIP/DNS、オーケストレーション）
モニタリング 拡張（ラグ、レイテンシー、ヘルス、アラーム）

これらの礎石は、私に決断のための安定した羅針盤を与え、失敗した場合の行動主義を防ぐ。このようにして、私は一貫性を保ち 空室状況 コントロール下にある。

MySQLレプリケーションの仕組み

書き込み操作は プライマリー 失敗を緩和し、読み取りアクセスを分散させるために、1つ以上のレプリカに書き込みを集中させる。プライマリ-レプリカトポロジは、書き込みを一元的にバンドルし、レプリカは読み込み、バックアップ、分析を担当する。マルチマスターは書き込みを複数のノードに分散するが、厳格な競合ルールが必要である。調整レベルを持つクラスタは、データレベルとクォーラムをリンクさせる。バリアントについて詳しく知りたい方は、以下を参照してください。 MySQLレプリケーションタイプを参考にしている。最終的に重要なのは、書き込みが明確に管理され、一貫性が置き去りにされないように、読み出しパスを意識的にコントロールすることだ。 スケーリング 苦しんでいる。.

分離レベルとトランザクション設計

私はいつも、レプリケーションを ドラフト取引. .MySQLはデフォルトでREPEATABLE READを使用します。これはOLTPには堅牢ですが、長いトランザクションではより高速な読み取りレートを生成します。ラグ, なぜなら、多くの古いバージョンが保持されているからである。選択的な更新が多いワークロードでは、ロックや副作用を減らすためにREAD COMMITTEDを使うこともある。私は、バッチの変更が小さくなるようにしている、, 時限的 トランザクションの代わりに、分単位の „メガ・コミット “を実行する。これにより、バイナリログがコンパクトに保たれ、レプリカSQLスレッドがスタックすることがなくなり レプリケーションラグ の方がゆっくりと蓄積される。を使いたくない場合は、ステートメント形式の非決定性関数（例えば、フィックスなしのNOW()）も避ける。 行ベース そうでなければ、乖離のリスクがある。.

一貫性モデルを分かりやすく説明

私は次のように区別している。強い一貫性、最終的な一貫性、リード・アフター・ライト。強い一貫性は、クライアントが成功メッセージを受け取る前に、複数のノードが確認するコミットを必要とする。偶発的一貫性は、レプリカが追いつくまでの短期的な差異を受け入れる。Read-after-Writeは、他のユーザーが古いデータを見たままであっても、書き込みを行ったユーザーが自分の変更をすぐに読めるようにする。ビジネス・クリティカルなプロセスでは、私は強力な一貫性またはRead-after-Write一貫性に依存し、レポーティングには偶発的一貫性を使用する。このトレードオフにより、レイテンシを抑制し、同時に データの完全性.

レプリケーションの種類とレイテンシー

非同期レプリケーションを使うのは、最大限の書き込みレイテンシーが必要なときと、ある一定の RPO 受け入れる。準同期方式はデータ損失のリスクを軽減するが、コミットごとに時間がかかる。同期方式は一貫性を強く保証するが、ネットワークの遅延やパケットロスの影響を受けやすい。ノード間の距離が長くなると、ラウンドトリップタイムも長くなり、同期コミットが著しく遅くなる。遅延が発生した場合、私は積極的に MySQLにおけるレプリケーションの遅延, 書込みパターンを最適化し、読込みリクエストを的を絞った方法で分配する。こうして、スピードと読書リクエストのバランスを保っている。 セキュリティ.

モード	コミット行動	レイテンシー	RPO	代表的な使用例	スプリットブレインのリスク
非同期	すぐにプライマリーを確認	低い	より高い	高スループット、レポートリード	ミディアム（ガイダンスなしのフェイルオーバー用）
半同期	少なくとも1台のレプリカを確認	ミディアム	より低い	レイテンシ・バッファを備えたクリティカル・トランザクション	より低い（より良い指導が可能）
同期/クラスタ	過半数が永久保存	より高い	非常に低い	定足数が必要なクラスタ	最低（定足数に問題なし）

ビンログフォーマット、GTID、衝突安全性

私は一貫して、次のことを頼りにしている。 GTIDsについて (gtid_mode=ON, enforce_gtid_consistency=ONフェイルオーバーがポジションパズルなしで機能するように）。私はレプリケーション・チャンネルを auto_position=1, 切り替え後にレプリカが自動的にソートするように。ビンログには 行ベース (binlog_format=ROW。なぜなら決定論的であり、関数や非決定論との衝突を避けることができるからだ。私は混合/ステートメントを選択的にしか使わない。.

衝突の安全性を確保するために sync_binlog=1 そして innodb_flush_log_at_trx_commit=1 RPOを実質的にゼロにする場合。より高いレイテンシ感度のために、私は妥協点を選びますが、それを明確に文書化します。クラッシュ時にレプリカがきれいにクリーンアップされるように、私は リレー_ログ_リカバリ そして去る ログ_レプリカ更新 (以前は ログ_slave_updatesカスケードが安定するように）。スループット パラレル・レプリケーション: レプリカ並列ワーカー (例：8-32）プラス binlog_transaction_dependency_tracking=WRITESET は、行違反のないように配置を最適化する。.

スプリットブレイン：原因と症状

スプリット・ブレインは、化合物が分裂し、いくつかの部分に分かれることで発生する。 同時に を書く。ネットワーク・パーティションやインターコネクトの欠陥が問題の引き金になることが多い。誤ったフェイルオーバー・スクリプトや不明確なクォーラムルールが状況を悪化させる。そして、互いに見えない2つの書き込みの真実がある。オートインクリメントの衝突、矛盾した更新、削除のロストが直接の原因となる。このような状況が長く続けば続くほど、その後に続く マージ.

MySQL固有のリスクシナリオ

私は、マスターとマスターの非同期セットアップに最大の危険性を感じている。 ガイダンス. .双方が書き込み可能で、ネットワークがちらつく場合、ツールは簡単に双方をプライマリに昇格させる。オフセットの自動インクリメントがなければ、プライマリ・キーはすぐに衝突する。VIPやDNSスイッチロジックがない場合、クライアントは2つのノードに並行して書き込む。クォーラムに欠陥のあるクラスタでも、双方が書き込みを続けることができる。このようなコンステレーションは、チームが方向性を定めるよりも早く一貫性を崩してしまう。 ランブックス 準備はできている。.

一貫性を確保するための戦略

私はスペルのルールを明確に定義している。 読み取り専用. .切り替えにはVIPを使うか、DNSのTTLを短くして、書き込みがアクティブなノードにしか行かないようにする。マルチマスターの設計では、クライアント、リージョン、キースペースによってデータルームを区切っている。また、自動インクリメントのオフセット、idempotence、バージョン・フィールドも使用している。アプリケーション側では、セッション・スティッキネスやターゲット・プライマリー・リードでリード・アフター・ライトを維持する。モニタリングはラグ、レイテンシー、健全性をチェックし、アラームは早期警告を提供する。このようにして、私はいくつかの レベル 同時に。.

リード・アフター・ライトの実際

書き込みセッションを プライマリー ピン。あるいは、レプリカが gtid_executed はユーザーの書き込みを含む。実際には、トークン（トランザクションのGTIDなど）を使って、リードパスが確認するようにしている。確認が取れない場合、読み込みは直接プライマリに行くか、レプリカが追いつくまでしばらく待つ。APIの場合は、レスポンスヘッダに„要リード・アフター・ライト“のヒントを与えることで、フロントエンドが意識的に判断できるようになる。 フレッシュ データを強要するか、一貫性のあるリードで生きるか。.

ラグ管理とクエリ設計

私は、主に次のような方法でラグを構築している。 クエリーの規律 from：長いSELECTには時間制限と適切なインデックスを与え、ホットスポットはシャーディングや代替キーを使って分解する。ビンログを溢れさせないように、大きな更新や削除は一時停止を挟んでバッチで実行する。再構築（ALTER TABLEなど）はウィンドウベースで、可能であればレプリケーションのスレッドをブロックしないようにオンラインでスケジュールする。アプリケーションレベルでは、レート制限を使って並列書き込みバーストを制限し、キューを使ってトラフィックのピークを平準化する。小さなハートビート・テーブルを使えば、秒単位の遅延を計測することができます。 アラート制限 現実的に。.

クォーラム、インターコネクト、フェイルオーバー

私は、クォーラムを設計している。 過半数 と書いてもよい。第3の場所またはクォーラムデバイスは、双方向の分割をきれいに解決する。冗長化された相互接続は、孤島のリスクを減らす。すべてのフェイルオーバーの前に、私は前のプライマリが本当になくなったのか、あるいは明らかに切り離されたのかをチェックする。オーケストレーション・ツールは、明確なロックとチェックによってのみ促進することができる。レプリカは、read_only=ONとsuper_read_only=ONで、偶発的な書き込みから保護されている。 リリース.

オーケストレーション、フェンシング、セキュアプロモーション

オーケストレーションは、あくまでも ゲートキーパー昇格は、旧プライマリーが積極的にフェンシングされている場合のみ許可される（例：VIPは脱退）、, super_read_only=オン, レプリカの状態は一貫している）。私のルールは以下の通り：

多数決による明確なリーダー選出と„ノー・デュアル・プライマリー“「ロック
以下の場合のみ昇格 サーバーID 曖昧さがない、, 読み取り専用 セットとレプリケーション・チャンネルはクリーン
DNS/VIPの切り替えは、健全性とラグをチェックした後にのみ行う。
ロールバックパス：疑問がある場合、システムは次のような方法を好みます。 短い読み取り専用, リスキーなことを書く代わりに

重要だ： 読み取り専用 はSUPERユーザーからの書き込みを保護しない。 スーパー・リード・オンリー. .また、管理者アカウントも隔離し、ストレスがかかったときにレプリカに „うっかり “書き込んでしまうことがないようにしている。.

緊急時のランブック

スプリットブレインが発生した場合、私は即座に行動し、新しい書き込みノードのためにアクティブな両方の書き込みノードをロックする。 トランザクション. .私は何かを接続する前に、両方のサイトの新しいバックアップまたはスナップショットを作成します。そして、データのステータスがこれ以上混ざらないように、すべてのレプリケーションを停止します。どのテーブルが影響を受けているのか、どの期間、どのユーザーのアクションが影響を受けているのか。監査ログ、タイムスタンプ、バージョンから履歴がわかります。真実のソース」を定義し、変更を選択的に適用し、レプリケーションを再度設定します。最後に、整合性チェックとクローズメッシュで検証する。 モニタリング.

データテーブルの比較とヒール

比較には、チェックサム、タイムスタンプ、そして バージョンフィールド, を使用して、分岐した行を確実に認識することができる。可能であれば、先読みログやバイナリログからシーケンスを再構築する。競合が発生した場合は、最後の書き込み者の勝利や属性ごとのドメインロジックなど、明確なルールに従って決定する。副作用を避けるために、強く乖離した領域を一貫性のあるスナップショットからのリストアで置き換える。すべてのインポートを完全に文書化し、後の監査で経路をたどれるようにする。ヒーリング後、レプリカの完全な再初期化を強制し、すべてのノードが同一の 出発点 を持つ。

バックアップ、PITR、再播種

私は完全なものを組み合わせる 物理的 ポイント・イン・タイム・リカバリ（PITR）のためのビンログによるバックアップ。バックアップはプライマリを保護するためにレプリカ上で実行され、テストベースで定期的にリードバックされる。高速な再シーディングのために、利用可能な場合はクローン/物理シッピングを使用し、GTIDオートポジションでレプリケーションを開始する。保持ポリシーはコンプライアンスとRPO目標に基づいています。ビンログは最大PITRホライズンが要求する期間保持します。バックアップは 一貫性 (InnoDBフラッシュ、正しいbinlogスタートウィンドウ)、そうでなければリストアとレプリケーションは機能しません。.

テスト、ドリル、SLO

明確な定義 SLO (例えば、重要なサービスについてはRPO≦30秒、RTO≦5分）を設定し、訓練で定期的にチェックする。シナリオには、ネットワーク・パーティション、ディスク障害、相互接続の不具合、レプリカの遅延などがある。私は「フェンス-プロモート-トラフィックの切り替え-検証」のステップを実践し、アラートとランブックの効果の速さを測定している。また、特にラグ（トラフィックのピーク、人工的なレイテンシー）を注入し、ルーティング、バックプレッシャー、リード・アフター・ライトのメカニズムがどのように反応するかを確認する。リハーサルしたものだけが緊急時に機能する 信頼できる.

スケーリング：シャーディング、リージョン、オーナーシップ

私は、クライアント、地域、または地域ごとに執筆の責任を分けている。 ドメイン, 競合領域を小さく保つ。リージョナル・シャーディングはレイテンシーを削減し、明確なガイダンスを持つローカル・プライマリを可能にする。私はレプリカからグローバルな読み込みワークロードを提供し、書き込みパスは厳密にローカルのままにしている。シャーディングを組み合わせたい場合はシャーディングとレプリケーション良いスタートが切れた。重要であることに変わりはない：オーナーシップ・ルールは、人の頭の中だけでなく、コード、DDL、ランブックの中にあるべきだ。こうすることで、スケーリングは計画可能なままである。 スピード を交換する。.

クラウドとマルチリージョン機能

私は、地域間のレイテンシーとパーティション・リスクについて積極的に計画を立てている。. 書き込み ローカルにとどまり、クロスリージョンレプリケーションは明確に定義されたRPOで非同期に実行される。DNSやVIPスイッチのTTLは短いが、ヘルスチェックとクォーラムチェックに合格した場合のみである。私は、ハードガイダンスのない „透過的な “グローバル分散書き込みは避けている。DRシナリオでは、コールドリージョンかウォームリージョンを用意しておき、定期的に再シードを行い、リージョンのフェイルオーバーを完全なフェイルオーバーとしてテストする。 ビジネスエクササイズ, 単なる技術デモとしてではない。.

コンプライアンス、セキュリティ、監査可能性

レプリケーション・チャネルをTLSで保護し、次のように設定します。 最低特権 レプリカユーザのためのものです。ビンログの保持とチェックサムは監査機能の一部であり、DDLパイプラインにおける追跡可能な変更ログも同様である。静止時の暗号化（表領域、バックアップ）は標準であり、鍵のローテーションとアクセス制御は文書化され、テストされている。サーバーID (サーバーID, サーバーID)は、オーケストレーションとGTIDが確実に機能するように、安定した曖昧さのないままでなければならない。これらはいずれもそれ自体が目的ではない。 根本原因分析 そして緊急時のダウンタイムを短縮する。.

要約：スピードより一貫性

私はレプリケーションを単独で計画することはない。 一貫性の目標 とビジネスケースに対応します。リーダーシップ、クォーラム、フェイルオーバーに関する強力なルールにより、最初の障害でクラスタが崩壊するのを防ぎます。モニタリング、テスト、ドリルにより、チームは重要なときに行動できる。スプリットブレインが発生した場合、私は書き込みを停止し、ステートを保存し、真実を選択し、一貫して再起動します。こうすることで、MySQLのレプリケーションは、データの一貫性を求めることなく、確実に使用可能な状態を保つことができる。 パフォーマンス の犠牲になる。.