非同期レプリケーション MySQL レプリケーションは、デフォルトでは非同期です。マスター スレーブ レプリケーションには、少なくとも 2 つの MYSQL サービスが必要です。これらの MySQL サービスは、異なるサーバーまたは同じサーバーに分散できます。 MySQL マスター/スレーブ非同期レプリケーションは、最も一般的なレプリケーション シナリオです。データの整合性は、マスター データベースの BINLOG が失われないことに依存します。マスター データベースの BINLOG が失われない限り、マスター データベースがクラッシュした場合でも、失われたデータを BINLOG を介してスレーブ データベースに手動で同期できます。 注: マスター データベースがダウンした場合、DBA は mysqlbinlog ツールを使用してマスター データベースの binlog に手動でアクセスし、不足しているログを抽出してスレーブ データベースに同期できます。また、高可用性 MHA アーキテクチャを構成して不足しているデータを自動的に抽出してスレーブ データベースを補完したり、グローバル トランザクション ID (GTID) を有効にして不足している binlog をスレーブ データベースに自動的に抽出したりすることもできます。 MySQL はトランザクション (または SQL ステートメント) を BINLOG に記録します。つまり、トランザクションをサポートするエンジン (InnoDB など) の場合は、各トランザクションがコミットされるときに BINLOG を書き込む必要があり、トランザクションをサポートしないエンジン (MyISAM など) の場合は、各 SQL ステートメントが実行されるときに BINLOG が必要になります。 Binlog のセキュリティを確保するために、MySQL では、BINLOG をディスクにフラッシュする頻度を制御する sync_binlog パラメータが導入されています。 'sync_binlog' のような変数を表示します。
上記は従来の非同期レプリケーションです。MySQL 5.7 の並列レプリケーション技術 (マルチスレッド レプリケーションとも呼ばれます) が登場する前は、最も批判されていた問題は効率性でした。スレーブのレイテンシは慢性的な問題でした。スキーマ レベルの並列レプリケーションは以前から登場していましたが、実際の効果は良くありませんでした。 マルチスレッドレプリケーション MySQL 5.7 では、マスターと同じスキーマのデータが変更されたときにスレーブが同時にデータを適用できない問題を解決する新しいマルチスレッド レプリケーション テクノロジが導入されました。また、binlog グループ送信の利点を最大限に活用し、スレーブがリレー ログを同時に適用できることを保証します。 MySQL 8.0では、マルチスレッドレプリケーションの技術的なアップデートが行われ、writesetの概念が導入されました。以前のバージョンでは、マスターデータベースの同じセッションが複数の異なる関連オブジェクトのトランザクションを順番に実行する場合、たとえば、最初にUpdate Aテーブルデータが実行され、次にUpdate Bテーブルデータが実行されました。BINLOGがスレーブデータベースにコピーされた後、これら2つのトランザクションを並行して実行することはできませんでした。writesetの登場により、この制限が解消されました。 強化された準同期レプリケーション 上記のレプリケーションは非同期操作です。マスターデータベースとスレーブデータベースのデータの間には、必然的に一定の遅延が発生します。これは隠れた危険をもたらします。トランザクションがマスターデータベースに書き込まれ、正常に送信されたが、スレーブデータベースがマスターデータベースの BINLOG ログをまだ取得していない場合、ディスクの損傷、メモリ障害、停電などによりマスターデータベースが予期せずクラッシュし、マスターデータベース上のトランザクションの BINLOG が失われます。このとき、スレーブデータベースはこのトランザクションを失い、マスターとスレーブの間に不整合が発生します。 この問題を解決するために、MySQL 5.5 から準同期レプリケーションが導入されました。当時の技術は、一時的に従来の準同期レプリケーションと呼ばれていました。この技術は MySQL 5.7 に開発され、強化された準同期レプリケーション (ロスレス レプリケーションとも呼ばれます) に進化しました。非同期レプリケーションでは、図に示すように、マスター データベースは、コミット操作を実行して BINLOG ログを書き込んだ後、BINLOG ログがスレーブ データベースに送信されるのを待たずに、クライアントに正常に戻ることができます。 半同期レプリケーションでは、マスター データベース上のすべての BINLOG トランザクションがスレーブ データベースに確実にレプリケートされるようにするため、マスター データベースはトランザクションが正常にコミットされるたびにフロントエンド アプリケーション ユーザーにすぐにフィードバックしません。代わりに、少なくとも 1 つのスレーブ データベース (詳細については、パラメータ rpl_semi_sync_master_wait_for_slave_count を参照) も BINLOG トランザクションを受信し、リレー ログに正常に書き込むまで待機します。その後、マスター データベースはクライアントにコミット操作の成功を返します (従来の半同期レプリケーションでも拡張半同期レプリケーションでも目的は同じですが、2 つの方法には 1 か所違いがあります。これについては後で説明します)。 半同期レプリケーションでは、トランザクションが正常にコミットされた後、少なくとも 2 つのログ レコード (マスター ライブラリの BINLOG ログに 1 つ、少なくとも 1 つのスレーブ ライブラリのリレー ログに 1 つ) が存在することが保証されるため、データの整合性がさらに確保されます。 従来の半同期レプリケーションでは、マスターデータベースが BINLOG にデータを書き込んでコミット操作を実行した後、スレーブデータベースからの ACK を待機します。つまり、スレーブデータベースがリレーログを書き込んでデータをディスクに保存した後、マスターデータベースにメッセージを返し、フロントエンドアプリケーション操作を正常に返すことができることをマスターデータベースに通知します。これにより問題が発生します。つまり、マスターデータベースは実際にトランザクションをトランザクションエンジン層にコミットしており、アプリケーションはデータが変更したことをすでに確認できますが、戻りを待っているだけです。この時点でマスターデータベースがクラッシュすると、スレーブデータベースがまだリレーログを書き込むことができていない可能性があり、マスターデータベースとスレーブデータベースの間に不整合が発生します。拡張された半同期レプリケーションは、この問題を解決するために設計されています。マスター データベースが BINLOG にデータを書き込んだ後、少なくとも 1 つのスレーブ データベースがリレー ログに書き込み、データをディスクに保存するまで、スレーブ データベースの応答 ACK を待機します。次に、マスター データベースにメッセージを返します。これにより、コミット操作を実行できることが通知されます。その後、マスター データベースはトランザクション エンジン レイヤーへのコミットを開始し、アプリケーションはデータが変更されたことを確認できます。拡張された半同期レプリケーションの一般的なプロセスを次の図に示します。 半同期レプリケーション モードでは、スレーブ データベースに BINLOG ログを送信するときにスレーブ データベースがクラッシュしたり、ネットワークが遅延したりすると、BINLOG ログは時間内にスレーブ データベースに送信されません。このとき、マスター データベース上のトランザクションは一定時間待機します (時間の長さは、パラメータ rpl_semi_sync_master_timeout で設定されたミリ秒数によって決まります)。この時間内に BINLOG ログをスレーブ データベースに正常に送信できない場合、MySQL は自動的にレプリケーションを非同期モードに調整し、トランザクションは正常にクライアントに送信結果を返します。 半同期レプリケーションは、マスター データベースとスレーブ データベース間のネットワーク状態に大きく依存します。往復遅延 RTT が小さいほど、スレーブ データベースのリアルタイム パフォーマンスは向上します。簡単に言えば、マスター データベースとスレーブ データベース間のネットワークが高速であるほど、スレーブ データベースのリアルタイム性が高まります。 注: ラウンドトリップ時間 (RTT) は、コンピュータ ネットワークにおける重要なパフォーマンス指標です。これは、データ送信の開始から受信者からの確認の受信までの合計時間を示します (これは少しわかりにくいかもしれませんが、TCP 3 ウェイ ハンドシェイクの最初の 2 つのハンドシェイクとして理解できます)。 要約する これで、MySQL マスタースレーブ レプリケーションに関するこの記事は終了です。MySQL マスタースレーブ レプリケーションの詳細については、123WORDPRESS.COM の以前の記事を検索するか、以下の関連記事を引き続き参照してください。今後とも 123WORDPRESS.COM をよろしくお願いいたします。 以下もご興味があるかもしれません:
|
>>: フロントエンドの面接でよく聞かれる JavaScript の質問の完全なリスト
まずは適用方法を説明します。nginxモジュールにはjtxyとjtcmdの2つがあります。 http...
目次1.entires() メソッドの詳細な構文2.entires() メソッドの一般的な使用法と注...
場合によっては、ジャンプを完了するために href の代わりにハイパーリンク <a> を...
<br />オリジナル: http://www.alistapart.com/artic...
目次JavaScript で配列を作成する配列の使用配列を分割文字列に変換する配列に要素を追加する配...
序文最近、レポート機能に取り組んでいたのですが、ある月に各部署に入社した人と退職した人の数をカウント...
目次質問: ボタンをクリックすると、スパンの色が赤に変わりますか?上記の問題を分析します。 2番目の...
この記事では、カルーセルマップの効果を実現するためのjQueryの具体的なコードを参考までに共有しま...
CSS Sprite は、CSS スプライトとも呼ばれ、画像結合技術です。この方法は、複数の小さなア...
効果 HTML を実装するには、まずクリーンな HTML ページを準備し、ノードを記述します。 &l...
1. dockerでtomcat8をインストールする1. Docker HubでTomcatイメージ...
目次序文1. パンくずリストはなぜ必要なのでしょうか? 2. 一次包装1. 実装のアイデア2. コー...
今では多くの人がウェブサイト作成に参加していますが、ウェブサイトはどのように作成すればよいのでしょう...
目次1. フロントエンドルーティングの実装原則2. vue-Routerの基本的な使い方2.1. イ...
Vueボタンコンポーネントのカスタムカプセル化コードは参考用です。具体的な内容は次のとおりです。ボタ...