17.1 レプリケーション構成

17.1.1 レプリケーションのセットアップ方法

17.1.2 レプリケーション形式

17.1.3 グローバルトランザクション識別子を使用したレプリケーション

17.1.4 レプリケーションおよびバイナリロギングのオプションと変数

17.1.5 一般的なレプリケーション管理タスク

MySQL 内のサーバー間のレプリケーションはバイナリロギングのメカニズムに基づいています。マスター (データベースの変更元) として動作する MySQL インスタンスは、更新および変更を「イベント」としてバイナリログに書き込みます。バイナリログ内の情報は、記録されているデータベース変更に応じて異なるロギング形式で格納されます。スレーブは、マスターからバイナリログを読み取って、スレーブのローカルデータベースにあるバイナリログのイベントを実行するように構成されます。

重要

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

マスターはこのシナリオでは「「ダム」」です。いったんバイナリロギングが有効になると、すべてのステートメントはバイナリログに記録されます。各スレーブはバイナリログの内容全体のコピーを受け取ります。バイナリログのどのステートメントを実行するべきかを決めるのはスレーブの役割で、特定のイベントのログのみを記録するようにマスターを構成することはできません。特に指定しない場合は、マスターバイナリログのすべてのイベントがスレーブで実行されます。必要な場合、特定のデータベースまたはテーブルに適用するイベントだけを処理するようにスレーブを構成できます。

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

マスターと各スレーブは一意 ID を使用して構成する必要があります (server-id オプションを使用)。また、各スレーブは、マスターホスト名、ログファイル名、およびそのファイル内の位置に関する情報を使用して構成する必要があります。これらの詳細は、スレーブで CHANGE MASTER TO ステートメントを使用して MySQL セッション内から制御できます。詳細はスレーブのマスター情報リポジトリ (ファイルまたはテーブル) に格納されます (セクション17.2.2「レプリケーションリレーおよびステータスログ」を参照してください)。

このセクションでは、レプリケーション環境に必要なセットアップと構成について説明します。新しいレプリケーション環境を作成するための手順を追った説明を含みます。このセクションの主な内容は次のとおりです。

• レプリケーション用に 2 つ以上のサーバーをセットアップするためのガイドについては、セクション17.1.1「レプリケーションのセットアップ方法」で、システムの構成について扱い、マスターとスレーブ間でデータをコピーする方法について説明します。

• バイナリログ内のイベントはいくつかの形式で記録されます。これらは、ステートメントベースレプリケーション (SBR) または行ベースレプリケーション (RBR) と呼ばれます。3 つ目のタイプ、混合形式レプリケーション (MIXED) は、SBR または RBR レプリケーションを自動的に使用し、必要に応じて SBR と RBR の両方の形式の利点を活用します。さまざまな形式については、セクション17.1.2「レプリケーション形式」を参照してください。

• レプリケーションに適用するさまざまな構成のオプションと変数に関する詳細は、セクション17.1.4「レプリケーションおよびバイナリロギングのオプションと変数」を参照してください。

• レプリケーションプロセスが開始されると、管理または監視はほとんど必要ありません。ただし、実行することが望ましい一般的なタスクに関するアドバイスについては、セクション17.1.5「一般的なレプリケーション管理タスク」を参照してください。