コンテンツにスキップ 
データベースのレプリケーション ホスティングでは、負荷が増大したときにアプリケーションがどの程度利用可能であり続けられるか、また、中断後にどの程度迅速に書き込みと読み込みを再開できるかを決定する。チューニング、フェイルオーバー戦略、適切な導入シナリオを含め、マスター・スレーブとマルチマスターの違いを明確に示します。.
中心点
適切なレプリケーション戦略を選択するために、次のような重要なポイントがある。.
- 主従関係シンプルな書き込み、スケーラブルな読み込み、明確な責任。.
- マルチマスター分散書き込み、より高い可用性、しかし競合管理。.
- GTIDsについて &フェイルオーバー：切り替えの高速化とレプリケーションパスのクリーン化。.
- 現実を受け入れるレイテンシー、ストレージ、ネットワークは一貫性に影響を与える。.
- モニタリング &チューニング: メトリクス、キャッチアップ時間、ビンログ設定が一目でわかります。.
ホスティングにおけるレプリケーション
私はレプリケーションを使って 空室状況 を使用することで、読み込みパフォーマンスを向上させ、読み込み負荷を分散し、故障のないメンテナンスウィンドウを実現します。マスター・スレーブ・トポロジーは書き込みを集中管理し、複数のレプリカは大量の読み出しに対応するため、応答時間が短縮される。マルチマスター型は分散書き込みを可能にし、グローバルセットアップでのレイテンシーを低減し、ノード損失への対処を容易にします。WordPress、ショップエンジン、APIなどのウェブスタックにとって、これはトラフィックのピークに対するバッファリングの増加と、インシデント発生後の迅速な復旧を意味する。純粋なレプリケーションを超えた水平的な成長を計画している場合は、次のように段階的にリンクしてください。 シャーディングとレプリケーション, データと負荷をより広範囲に分散し スケーリング 計画性を持たせるためだ。.
マスター・スレーブ：機能性と強み
マスターとスレーブのセットアップでは、私は一貫して マスター, 一方、スレーブはリードアクセスを引き継ぎ、ビンログに従う。役割を明確に割り当てることで、書き込みの競合を回避し、モデルを明確に保つことができます。これは、製品カタログ、コンテンツポータル、レポートダッシュボードなど、読み込みの割合が高い多くのホスティングシナリオに最適です。書き込みパスを変更することなく、必要に応じてスレーブを追加しています。短い遅延にもかかわらずレポートやキャッシュを同期できるように、レプリケーション遅延用のバッファを計画しています。 結果 を届ける。
MySQLマスター・スレーブ
私はマスターでバイナリ・ロギングとユニークな サーバーID, スレーブもそれに倣うことができる：my.cnfで server-id=1, log_bin=mysql-bin。, 、オプション binlog_do_db レプリケーションをフィルターするためです。その後、専用のレプリケーション・ユーザーを作成し、その権限を最低限に制限しています。最初の同期のために、ダンプを --マスター・データ, これをスレーブにインポートし、ログファイルと位置を記憶させる。スレーブ側で server-id=2, リレー・ログをアクティブにして、それを マスターを ...続いて スタート・スレーブ.と一緒に show slave statusg 私は思う。 マスターの背後 遅延が増加した場合に対応する。.
ホスティング環境の最適化
クリーンなフェイルオーバーのために GTIDsについて これにより、面倒なログ位置の再調整をすることなく、切り替えを簡素化することができる。ホットスポットを避け、キャッシュのヒット率を上げるために、ProxySQLやアプリケーション・ロジックなどのプロキシ層を経由して読み込みを行います。と sync_binlog=1 には適度な値を設定する。 同期_リレー_ログ 遅延が手に負えなくなることなく、書き込みのオーバーヘッドを減らす。遅いSSDや共有ストレージプールはバックログを増加させるので、私はI/O容量に注意を払っている。監査とコンプライアンスのために、私はレプリケーション・チャネルを暗号化している。 ティーエルエス そして、キーをデータパスから切り離す。.
マルチマスター：意味があるとき
私は、書き込みを地理的に分散させる必要がある場合、または単一の ノード はもはや書き込み負荷を運ぶことができない。すべてのノードは変更を受け入れ、相互に伝播するため、障害をより簡単に補うことができる。その代償は競合管理である。同じ行の同時更新には、ラストライターの勝利、アプリケーション側のマージ、トランザクションシーケンスなどのルールが必要である。ペイメントゲートウェイやグローバルSaaSバックエンドのようなレイテンシに敏感なワークロードでは、このセットアップによってレスポンスタイムを大幅に短縮することができる。私は、自分のアプリケーションが競合を許容するかどうか、また、明確なルールがあるかどうかを事前に評価する。 戦略 解決のために。.
MySQLマルチマスターの実際
私はGTIDベースのレプリケーションに依存している。 エラー それらをより迅速に表示させることができる。マルチソースレプリケーションにより、中央分析や集約のために、複数のマスターを1つのノードに送り込むことができる。実際のピア・トポロジでは、競合の少ないキー戦略を定義し、自動インクリメント・オフセットをチェックし、タイムスタンプのドリフトを減らす。リージョンをまたいだ並列書き込みは調整の手間を増やし、スループットを犠牲にする可能性があるため、私は待ち時間のピークを監視している。適切なモニタリングと明確なオペレーター・ルールがなければ、マルチマスターを生産的に使うことはできないだろう。 スイッチ.
比較表：マスター・スレーブ対マルチマスター
次の表は、最も重要な相違点をまとめたものである。 決定 普段の司会で.
| 基準 | 主従関係 | マルチマスター |
|---|---|---|
| 書き込み | マスターはすべての 書き込み操作 | すべてのノードは書き込みを受け付ける |
| 一貫性 | 厳格、コンフリクトの可能性は低い | よりソフトに、コンフリクトの可能性 |
| スケーリング | 拡張性が高い | 拡張可能な読み書き |
| セットアップの労力 | 管理しやすく、コントロールしやすい | より多くの努力とより多くのルール |
| 代表的な使用例 | ブログ、ショップ、レポート | グローバルアプリ、レイテンシが重要なAPI |
高可用性、RTO/RPO、セキュリティ
明確な定義 RTO/RPO-ターゲットとレプリケーションを調整する：リカバリにはどれくらいの時間がかかり、どれくらいのデータを失う可能性があるのか。同期または準同期のレプリケーションは損失を減らすことができるが、レイテンシーとスループットが犠牲になる。バックアップはレプリケーションに取って代わるものではなく、ポイント・イン・タイムのリカバリーと履歴ステータスのためにレプリケーションを補完するものです。私はリストアテストを定期的にチェックしている。適切なプランニングのために、私のガイドを参照してください。 ホスティングにおけるRTO/RPO, そのため、主要な数字が業務上の現実に対応し リスク フィットしている。
スケーリングパス：シングルノードからクラスタへ
私はよくシングルで始める。 マスター, 読み込みとバックアップ用にレプリカを追加し、段階的にスケールアップしていく。リードシェアが拡大するにつれて、スレーブを追加し、キャッシュでセットアップを完成させます。書き込み容量が足りなくなったら、マルチマスターパスを計画し、競合リスクをチェックし、アプリケーションにidempotenceを追加する。大規模なコンバージョンの場合は、ローリング戦略、ブルー／グリーンまたはデュアルライトフェーズでマイグレーションを行い、ロールバックに備えてリザーブを確保しておく。ダウンタイムのないコンバージョンの場合、私は以下のガイドを使用します。 ダウンタイムなしのマイグレーション, ユーザーが 中断 を感じる。.
パフォーマンス・チューニング：レイテンシー、I/O、キャッシュ
私はネットワークのレイテンシー、ストレージのIOPS、CPUのピークを監視している。 ノード, なぜなら、3つの要素すべてがレプリケーションの遅延をコントロールするからだ。ローカルのRedisまたはMemcachedレイヤーがスタックから読み込みを行い、スレーブをアンロード状態に保つ。私は大きなトランザクションを分割してbinlogの洪水を避け、コミットジャムを減らす。書き込みの多いワークロードに対しては、innodbのログバッファを適度に増やし、耐久性を損なわない範囲でフラッシュの間隔を調整する。悪いインデックスはマスターとスレーブの両方でコストのかかるエラーを引き起こすので、クエリプランはクリーンにしておく。 スキャン.
マルチマスターにおけるコンフリクトの回避と解決
例えば、次のように論理的に書く領域を分けることで、衝突を避けている。 クライアント, リージョンまたはキースペース。自動インクリメントオフセット（例えば3ノードの場合は1/2/3）は、主キーとの衝突を防ぐ。同時更新が避けられない場合は、明確なルールを文書化する。例えば、最後に書いた人が勝つとか、アプリケーション側でマージするとか。べき等書き込みと重複排除コンシューマーは、重複処理を防ぐ。また、監査情報を記録し、紛争が起きたときに迅速に判断できるようにしている。 理解する ができるようになる。
トラブルシューティング最初に確認すること
遅れている場合は、次のことを確認する。 マスターの背後, I/OとSQLスレッド、そしてリレーログのサイズです。STATEMENTとROWでボリュームが大きく変わることがあるので、私はビンログのサイズとフォーマットを見ます。フラッシュ時間やキューのようなストレージメトリクスは、SSDが最大かスロットリングしているかを示します。GTIDがアクティブであれば、チャネルごとに適用されているトランザクションと欠落しているトランザクションを比較する。緊急時には、特にレプリケーターを停止したり起動したりして詰まりを解消し、その後にのみ、トランザクションを修正する。 構成.
一貫性モデルとリード・アフター・ライト
非同期レプリケーションでは、意識的に計画を立てる。 最終的な一貫性 にある。直接的なフィードバックを伴うユーザーのアクションについては、私は次のことを保証する。 書き込み後読み取り, 書き込みセッションをマスターに短時間バインドしたり、ラグを意識した方法で読み込みをルーティングしたりする。私は、アプリケーションフラグ（例えば、2～5秒間の „スティッキネス“）を使用し、次のようにチェックしている。 マスターの背後, レプリカにクリティカルリードを許可する前に。レプリカに頼る read_only=オン そして super_read_only=オン, 偶発的な書き込みがすり抜けないように。適切に選択されたアイソレーション・レベル(REPEATABLE READ 対 READ COMMITTED長いトランザクションでApplyスレッドが遅くなるのを防ぐためです。.
トポロジー：スター型、カスケード型、ファンアウト型
古典的なスター（すべてのスレーブがマスターから直接プルする）に加えて、私は次のものを頼りにしている。 カスケード・レプリケーション, 多くのレプリカが必要な場合やWANリンクが制限されている場合。そのために、私は中間ノードで以下を有効にしている。 log_slave_updates=ON, これにより、ダウンストリームレプリカのソースとなる。これにより、マスターI/Oの負荷が軽減され、帯域幅がより分散される。私は追加のレイテンシー・レベルに注意を払っている：各カスケードは遅延を増加させる可能性があり、綿密な監視が必要です。グローバルなセットアップの場合、私は距離の短いリージョナルハブを組み合わせ、メンテナンスのためにリージョンごとに少なくとも2つのレプリカを維持します。 フェイルオーバー 準備はできている。
計画的フェイルオーバーと計画外フェイルオーバー
私は明確に記録している。 昇格プロセス1) マスターへの書き込みを停止するか、トラフィックフローを読み取り専用に切り替える。 読み取り専用 休止し、4）残りのノードを再配置する。に対して スプリット・ブレイン 私は、明確なルーティング（短いTTLを持つVIP/DNSスイッチングなど）と自動ブロックによって自分自身を守っている。オーケストレーションツールも役に立ちますが、私は定期的に手動パスを実践しています。私は、ランブック、アラーム ドリル 緊急時に即席で対応する必要がないようにするためだ。.
GTIDの実践：つまずきと癒し
GTIDについては、私は次のようにしている。 enforce_gtid_consistency=ON そして gtid_mode=ON ステップ・バイ・ステップ私は オートポジション, を使用してソースの変更を簡素化し、GTID ルートのレプリケーション・フィルターはデバッグを困難にするので避けてください。ステップ 誤取引 (レプリカには存在するが、ソースには存在しないトランザクション)については、以下の違いを使って識別する。 gtid_executed とソースを管理し、やみくもにパージするのではなく、コントロールされた方法でクリーンアップします。リビルドが隙間なく行えるように、ビンログの保持を計画し、その整合性をチェックする。 gtid_purged.
レプリカの並列化とスループット
タイムラグを減らすために、私は レプリカ並列ワーカー CPUの数に応じて replica_parallel_type=LOGICAL_CLOCK, 関連取引が整理されたままであるように。と binlog_transaction_dependency_tracking=WRITESET 独立した書き込みを同時に適用できるため、並列性を高める。私はレプリカのデッドロックとロック待ち時間を監視している：過度の並列性は同時更新を発生させる可能性がある。さらに、次のような利点もあります。 グループ・コミット P95のレイテンシ範囲を超えることなく、より効率的に関連トランザクションをバンドルするために、マスターで（アタッチされたフラッシュ遅延）。.
ダウンタイムなしのスキーマ変更
私の好み オンラインDDL InnoDB (アルゴリズム=インプレース/インスタント, LOCK=NONE)を使用して、クエリをブロックすることなく、レプリケーションを通じてテーブルの変更を行います。非常に大きなテーブルの場合は、チャンクベースの方法を選択し、インデックスを分割し、ビンログの負荷に注意します。マルチマスターの場合、スキーマの同時変更は回復が難しいので、DDLウィンドウのスケジュールを厳密に決めます。レプリカ上でDDLをテストし、ラグへの影響を測定し、レプリケーション経路が安定した場合にのみ推進します。.
セーフティネットとしての複製遅延
論理エラー(DROP/DELETE)に対しては、次のように考えます。 ディレイドレプリカ 例えば replica_sql_delay=3600. .これにより、バックアップからすぐにPITRを実行することなく、1時間以内にクリーンな状態に戻すことができます。このレプリカをリードやフェイルオーバーに使うことはありません。私はこのノードからのコピーを自動化し、緊急時に新鮮で最新のリードノードをすぐに引き出せるようにしています。.
アップグレード、互換性、操作性
ソースとターゲットのバージョンを近づけ、アップグレードする。 ローリング最初にレプリカ、次にマスター。MySQLとMariaDBが混在する環境では、ビンログのフォーマットや機能が異なることがあるので、私は批判的な見方をしています。私は binlog_row_image=ミニマル ビンログ量を減らし、トリガーやストアドプロシージャのアプリケーション依存性をチェックするのが理にかなっているところ。プロトコルとビンログ圧縮のためにWAN負荷を減らしますが、CPU予算を使いすぎないように注意しています。.
観測可能性とキャパシティ・プランニング
私は以下のSLOを定義している。 ラグ, キャッチアップ時間、エラー率、スループット。核となる変数には、1秒あたりの適用トランザクション、リレーログフィルレベル、I/Oキュー、ロック待ち時間、ネットワークレイテンシーなどがある。ビンログの成長を記録し binlog_expire_logs_seconds を設定し、リビルドが保持期間内に収まっているかどうかをチェックします。私はレプリカに次のような制限を設けている。 最大接続数 そして、読み込み負荷がゼロにならないようにキャンセルを監視する。コストとサイズについては、私はファンアウトのレベル、必要なストレージ、そして ピーク負荷 RPO/RTO目標に対して。.
レプリケーション運用におけるセキュリティとコンプライアンス
シール接続 エンドツーエンド また、オペレータ、アプリケーション、レプリケーションのアカウントを厳密に分離します。定期的な権限監査により、レプリケーション・ユーザーが不必要なDDL/DML権限を保持しないようにしています。オフサイト・バックアップを個別のキー管理で保護し、横の動きに対してアクセス・パスをチェックします。データ保護のため、削除ルールを遵守し、目的が許せば仮名化または最小化されたデータレコードをレプリケートします。遠隔測定が不用意に使用されないよう、最小特権に従ってロギングと測定基準を共有しています。 リーク 生成される。.
簡単にまとめると
ホスティング・シナリオでは、マスター・スレーブは信頼性の高い 基礎, なぜなら、リードは簡単にスケールし、コンフリクトはほとんど起こらないからだ。グローバルな書き込み、低レイテンシ、障害耐性が優先される場合は、マルチマスターを検討し、競合解決のためのルールを計画する。リカバリーの目標を安全に達成するために、GTID、クリーンなモニタリング、よく考えられたバックアップを組み合わせています。ビンログ、ストレージ、クエリーパラメーターをチューニングすることで、遅延を減らし、スループットを高く保ちます。これにより、適切なトポロジーを選択し、制御された方法で拡張し、ユーザーのダウンタイムを最小限に抑えることができます。 インビジブル.
