MySQL マスタースレーブレプリケーションのいくつかのレプリケーション方法の概要

MySQL マスタースレーブレプリケーションのいくつかのレプリケーション方法の概要

非同期レプリケーション

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' のような変数を表示します。 

  • デフォルトでは、sync_binlog=1 は、トランザクションがコミットされる前に、MySQL が BINLOG をディスクにフラッシュする必要があることを意味します。このようにすると、データベース ホストのオペレーティング システムがクラッシュしたり、ホストの電源が突然切れたりしても、システムは準備状態にあるトランザクションをほとんど失うことはありません。sync_binlog=1 を設定して、データのセキュリティを最大限に確保します。
  • sync_binlog=0 は、MySQL が binlog の更新を制御せず、ファイル システム自体がファイル キャッシュの更新を制御することを意味します。
  • sync_binlog=N、N が 0 または 1 でない場合、更新方法は sync_binlog=1 と同様ですが、更新頻度が N 個の 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 をよろしくお願いいたします。

以下もご興味があるかもしれません:
  • MySQL マスタースレーブレプリケーションにおける重複キーの問題を修正する方法
  • MySql マスタースレーブレプリケーションメカニズムの包括的な分析
  • MySQL マスタースレーブレプリケーションと読み取り書き込み分離の詳細な説明
  • MYSQL データベース GTID はマスタースレーブレプリケーションを実現します (超便利)
  • MySql マスタースレーブレプリケーションの実装原理と構成
  • MySQL マスタースレーブレプリケーションの原理と注意点
  • MySQL マスタースレーブレプリケーションでエラーをスキップする方法
  • MySQL マスタースレーブレプリケーション構成プロセス
  • MySQL マスタースレーブレプリケーションの原理からインストールと設定までを包括的に解説します。
  • MySQL マスタースレーブレプリケーション切断の一般的な修復方法

<<:  DeepinでPyenvをインストールする手順

>>:  フロントエンドの面接でよく聞かれる JavaScript の質問の完全なリスト

推薦する

CSS3を使用してテキストの垂直配置を実現する方法

最近のプロジェクトでは、テキストを垂直に揃えたいと考え、CSS の writing-mode プロパ...

Docker+Nginx を使ってシングルページアプリケーションをデプロイする

開発から導入まで自分で行うシングルページアプリケーションを開発する場合、ビルドを実行した後 npm ...

CocosCreatorメッセージ配信メカニズムの詳細な説明

概要この記事は、ゲームビジネスアーキテクチャに関連するコンテンツの紹介から始まります。ゲームビジネス...

MySQL接続クエリの原理と応用

概要MySQL の最も強力な機能の 1 つは、データ取得を実行しながらテーブルを結合できることです。...

Tomcat および Web アプリケーションの Docker デプロイメントの実装

1.dockerをオンラインでダウンロードする yum インストール -y epel-release...

条件によるMysqlカウントの複数の実装方法を詳細に解説

最近、あるウェブサイトのバックエンドに一連の統計機能を追加していたのですが、条件によるカウントが必要...

文字列の GBK および GB2312 エンコードとデコードのフロントエンド実装 (概要)

序文プロジェクトを開発しているときに、かなり厄介な問題に遭遇しました。この製品では、判断のためにブラ...

Vue要素はテーブルの追加、削除、データの変更を実装します

この記事では、テーブル内のデータを追加、削除、変更するためのvue要素の具体的なコードを参考までに共...

JSX を使用してカルーセル コンポーネントを実装する方法 (フロントエンドのコンポーネント化)

JSX を使用してコンポーネント システムを構築する前に、例を使用してコンポーネントの実装原理とロ...

NextCloud プライベート クラウド ストレージ ネットワーク ディスクの構築に関する詳細なチュートリアル

Nextcloud は、オープンソースで無料のプライベート クラウド ストレージ ネットワーク ディ...

nginxはdockerコンテナ内に設定ファイルを自動的に生成します

企業が Docker 自動デプロイメントを構築する場合、Docker の実行時にコンテナ内の設定ファ...

ウェブサイト製品設計の参考となるいくつかの原則

以下の分析は製品設計原則に関するものですが、そのほとんどはウェブサイト製品に基づいているため、ユーザ...

Vue+Element+Springboot画像アップロードの実装例

最近、たまたま vue+springboot のフロントエンドとバックエンドの分離プロジェクトに触れ...

MySql はコミットする必要がありますか?

MySQL が挿入などの操作を実行するときにコミットする必要があるかどうかは、ストレージ エンジン...

JavaScript PromiseとAsync/Awaitの詳細な説明

目次概要4つの例例1: 誕生日で説明する約束の基本例2: 数字当てゲーム例3: Web APIから国...