非同期レプリケーション 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 の質問の完全なリスト
最近のプロジェクトでは、テキストを垂直に揃えたいと考え、CSS の writing-mode プロパ...
開発から導入まで自分で行うシングルページアプリケーションを開発する場合、ビルドを実行した後 npm ...
概要この記事は、ゲームビジネスアーキテクチャに関連するコンテンツの紹介から始まります。ゲームビジネス...
概要MySQL の最も強力な機能の 1 つは、データ取得を実行しながらテーブルを結合できることです。...
1.dockerをオンラインでダウンロードする yum インストール -y epel-release...
最近、あるウェブサイトのバックエンドに一連の統計機能を追加していたのですが、条件によるカウントが必要...
序文プロジェクトを開発しているときに、かなり厄介な問題に遭遇しました。この製品では、判断のためにブラ...
この記事では、テーブル内のデータを追加、削除、変更するためのvue要素の具体的なコードを参考までに共...
JSX を使用してコンポーネント システムを構築する前に、例を使用してコンポーネントの実装原理とロ...
Nextcloud は、オープンソースで無料のプライベート クラウド ストレージ ネットワーク ディ...
企業が Docker 自動デプロイメントを構築する場合、Docker の実行時にコンテナ内の設定ファ...
以下の分析は製品設計原則に関するものですが、そのほとんどはウェブサイト製品に基づいているため、ユーザ...
最近、たまたま vue+springboot のフロントエンドとバックエンドの分離プロジェクトに触れ...
MySQL が挿入などの操作を実行するときにコミットする必要があるかどうかは、ストレージ エンジン...
目次概要4つの例例1: 誕生日で説明する約束の基本例2: 数字当てゲーム例3: Web APIから国...