このページは機械翻訳したものです。

17.1.1 バイナリログファイルの位置ベースのレプリケーション構成の概要

このセクションでは、バイナリログファイルの位置方式に基づく MySQL サーバー間のレプリケーションについて説明します。この方法では、(データベースの変更が行われる) ソースとして動作する MySQL インスタンスが、更新および変更を 「events」 としてバイナリログに書き込みます。 バイナリログ内の情報は、記録されているデータベース変更に応じて異なるロギング形式で格納されます。 レプリカは、ソースからバイナリログを読み取り、レプリカローカルデータベース上のバイナリログ内のイベントを実行するように構成されます。

各レプリカは、バイナリログの内容全体のコピーを受け取ります。 バイナリログ内のどのステートメントを実行すべきかを決定するのは、レプリカの役割です。 特に指定しないかぎり、ソースバイナリログ内のすべてのイベントがレプリカで実行されます。 必要に応じて、特定のデータベースまたはテーブルに適用されるイベントのみを処理するようにレプリカを構成できます。

重要

特定のイベントのみを記録するようにソースを構成することはできません。

各レプリカはバイナリログ座標のレコードを保持: ソースから読み取って処理したファイル内のファイル名と位置。 つまり、複数のレプリカをソースに接続し、同じバイナリログの異なる部分を実行できます。 レプリカはこのプロセスを制御するため、ソース操作に影響を与えることなく、個々のレプリカを接続してサーバーから切断できます。 また、各レプリカはバイナリログ内の現在の位置を記録するため、レプリカを切断し、再接続してから処理を再開できます。

ソースと各レプリカは、(server_id システム変数を使用して) 一意の ID で構成する必要があります。 また、各レプリカは、ソースホスト名、ログファイル名およびそのファイル内の位置に関する情報で構成する必要があります。 これらの詳細は、レプリカに対する CHANGE REPLICATION SOURCE TO ステートメント (MySQL 8.0.23) または CHANGE MASTER TO ステートメント (MySQL 8.0.23 より前) を使用して、MySQL セッション内から制御できます。 詳細は、レプリカ接続メタデータリポジトリ内に格納されます (セクション17.2.4「リレーログおよびレプリケーションメタデータリポジトリ」 を参照)。