Azure Database for MySQL - フレキシブル サーバーの送信データのレプリケーションを構成する方法
適用対象: Azure Database for MySQL - フレキシブル サーバー
この記事では、ソースとレプリカのサーバーを構成して、Azure Database for MySQL フレキシブル サーバーで送信データ レプリケーションを設定する方法について説明します。 この記事は、MySQL サーバーとデータベースに関して、ある程度の使用経験があることを前提としています。
送信データ レプリケーションでは、ソースは常に Azure Database for MySQL フレキシブル サーバーです。 レプリカには、他のクラウド プロバイダー、オンプレミス、または仮想マシン上の任意の外部 MySQL サーバーを使用できます。 この記事の手順を実行する前に、送信データのレプリケーションの制限事項と要件を確認してください。
注意
この記事には、Microsoft が使用しなくなった "スレーブ" という用語を参照しています。 ソフトウェアからこの用語が削除された時点で、この記事から削除します。
ソースとして使用する Azure Database for MySQL フレキシブル サーバー インスタンスを作成します。
Azure Database for MySQL フレキシブル サーバーの新しいインスタンスを作成します (例: sourceserver.mysql.database.Azure.com)。 サーバーの作成については、Azure portal を使用した Azure Database for MySQL フレキシブル サーバー インスタンスの作成に関する記事をご覧ください。 このサーバーは、送信データのレプリケーション用の "ソース" サーバーとなります。
重複するユーザー アカウントとそれに対応する権限を作成します。
- レプリカ サーバーにソース サーバーのユーザー アカウントはレプリケートされません。 ユーザーにレプリカ サーバーへのアクセスを提供するよう計画しているとします。 その場合は、この新しく作成された Azure Database for MySQL フレキシブル サーバー インスタンスで、すべてのアカウントとそれに対応する特権を手動で作成する必要があります。
ソース MySQL サーバーを構成する
以下の手順では、ソースとして動作する Azure Database for MySQL フレキシブル サーバー インスタンスを準備して構成します。
ネットワーク要件
ネットワーク設定が確立されており、ソース サーバーとレプリカ サーバーがシームレスに通信できることを確認します。
ソース サーバーがパブリック アクセス上にある場合は、ファイアウォール規則でレプリカ サーバーの IP アドレスが許可されていることを確認します。 レプリカ サーバーが Azure でホストされている場合は、Azure portal のネットワーク ページから、任意の Azure サービスからのパブリック アクセスを許可するオプションを確実に選択してください。 ソース サーバーがプライベート アクセス上にある場合は、レプリカ サーバーが Vnet ピアリングまたは VNet 間 VPN ゲートウェイ接続を使用してソースに接続できることを確認します。Note
詳細については、「ネットワークの概要 - Azure Database for MySQL フレキシブル サーバー」を参照してください。
バイナリ ログを有効にする
ソースでバイナリ ログが有効になっているかどうかを、次のコマンドを実行してチェックします。
SHOW VARIABLES LIKE 'log_bin';
変数 log_bin の戻り値が "ON" であった場合、サーバーでバイナリ ログが有効になっています。
新しいレプリケーション ロールを作成し、権限を設定する
レプリケーションの権限をもつよう構成されたユーザー アカウントをソース サーバーに作成します。 この作業は、SQL コマンド、または MySQL Workbench などのツールを使用して行うことができます。 SSL を使用するレプリケートを計画するかどうかを検討してください。これはユーザーを作成するときに指定する必要があります。 ソース サーバーにユーザー アカウントを追加する方法については、MySQL のドキュメントを参照してください。
次のコマンドでは、新しいレプリケーション ロールは、ソース自体をホストするマシンだけでなく、任意のマシンからソースにアクセスできます。 そのため、create user コマンドには "syncuser@'%'" を指定しています。 アカウント名の設定の詳細については、MySQL のドキュメントを参照してください。
アカウント名の設定に使用できるツールがいくつかあります。 使用する環境に最適なものを以下から選択します。
SSL を使用したレプリケーション
すべてのユーザー接続に SSL を要求するには、次のコマンドを使用してユーザーを作成します。
CREATE USER 'syncuser'@'%' IDENTIFIED BY 'yourpassword';
GRANT REPLICATION SLAVE ON *.* TO ' syncuser'@'%' REQUIRE SSL;
SSL を使用しないレプリケーション
必ずしもすべての接続に SSL が必要でない場合は、次のコマンドを使用してユーザーを作成します。
CREATE USER 'syncuser'@'%' IDENTIFIED BY 'yourpassword';
GRANT REPLICATION SLAVE ON *.* TO ' syncuser'@'%';
ソース サーバーをダンプし復元します。
レプリカに移行する既存のデータがない新しく作成されたソース サーバーの場合は、このセクションをスキップします。 この時点で、テーブルのロックを解除できます。
SET GLOBAL read_only = OFF;
UNLOCK TABLES;
ソース サーバーにレプリカに移行する既存のデータがある場合は、次の手順に従います。
Azure Database for MySQL フレキシブル サーバーにレプリケートするデータベースとテーブルを決定し、ソース サーバーからダンプを実行します。 mysqldump を使用して、プライマリ サーバーからデータベースをダンプすることができます。 詳細については、「ダンプと復元」を参照してください。 MySQL ライブラリとテスト ライブラリをダンプする必要はありません。
ソース サーバーを読み取り書き込みモードに設定します。
データベースをダンプした後、ソースの Azure Database for MySQL フレキシブル サーバー インスタンスを読み取り/書き込みモードに変更します。
SET GLOBAL read_only = OFF;
UNLOCK TABLES;
- ダンプ ファイルを新しいサーバーに復元します。 Azure Database for MySQL フレキシブル サーバーに作成されたサーバーにダンプ ファイルを復元します。 Azure Database for MySQL フレキシブル サーバー インスタンスへのダンプ ファイルの復元については、ダンプと復元に関する記事をご覧ください。 大きいダンプ ファイルは、レプリカ サーバーと同じリージョンにある Azure 内の仮想マシンにアップロードしてください。 それを仮想マシンから Azure Database for MySQL フレキシブル サーバー インスタンスに復元します。
Note
ダンプと復元を行うときにデータベースを読み取り専用に設定したくない場合は、mydumper/mydumper を使用できます。
送信データのレプリケーションを開始するようにレプリカ サーバーを構成します。
フィルター処理
Azure Database for MySQL フレキシブル サーバーと他のクラウド プロバイダーまたはオンプレミスの外部 MySQL の間に、送信データ レプリケーションを設定しているとします。 その場合は、レプリケーション フィルターを使用して、レプリカ サーバー上の Azure カスタム テーブルを除外する必要があります。 これは、Replicate_Wild_Ignore_Table = "mysql.__%" を設定し、Azure Database for MySQL フレキシブル サーバーの mysql 内部テーブルをフィルター処理して実現できます。 このサーバー パラメーターの変更の詳細については、「MySQL :: MySQL 5.7 リファレンス マニュアル - 13.4.2.2 CHANGE REPLICATION FILTER ステートメント」を参照してください。
レプリカ サーバーに接続し、レプリカ サーバーで MySQL シェルを開いて、レプリカ サーバーを設定します。 プロンプトから次の操作を実行します。これにより、いくつかの MySQL レプリケーション設定が同時に構成されます。
CHANGE THE REPLICATION SOURCE TO SOURCE_HOST='<master_host>', SOURCE_USER='<master_user>', SOURCE_PASSWORD='<master_password>', SOURCE_LOG_FILE='<master_log_file>', SOURCE_LOG_POS=<master_log_pos>
- master_host: ソース サーバーのホスト名 (例 : 'source.mysql.database.Azure.com')
- master_user: ソース サーバーのユーザー名 (例 :'syncuser'@'%')
- master_password: ソース サーバーのパスワード
- master_log_file: show master status を実行することによって得たバイナリ ログ ファイルの名前
- master_log_pos: show master status を実行することによって得たバイナリ ログの位置
注意
接続に SSL を使用するには、属性 SOURCE_SSL=1 を コマンドに追加します。 レプリケーション コンテキストでの SSL の使用の詳細については、https://dev.mysql.com/doc/refman/8.0/en/change-replication-source-to.html を参照してください。
次のコマンドを使用してレプリカ サーバーをアクティブ化します。
START REPLICA;
この時点で、レプリカ インスタンスはソース サーバー データベースに加えられた変更のレプリケートを開始します。 これをテストするには、ソース データベースにサンプル テーブルを作成し、正常にレプリケートされるかどうかを確認します。
レプリケーションの状態を確認します。
レプリカ サーバーで show slave status\G コマンドを呼び出してレプリケーションの状態を表示します。
show slave status;
Slave_IO_Running と Slave_SQL_Running の状態が
yes
で、Seconds_Behind_Master の値が0
の場合、レプリケーションは正常に機能しています。 Seconds_Behind_Master は、レプリカの遅延を示します。 値が0
ではない場合、レプリカで更新が処理されています。レプリカ サーバーが Azure VM にホストされる場合は、[Azure サービスへのアクセスを許可] を [オン] に設定して、ソースとレプリカのサーバーが通信できるようにします。 この設定は、[接続のセキュリティ] オプションから変更できます。 詳細については、ポータルを使用したファイアウォール規則の管理を参照してください。
mydumper/mydumper を使用してデータベースをダンプした場合は、/backup/metadata ファイルから master_log_file と master_log_pos を取得できます。
次のステップ
- 送信データのレプリケーションの詳細を確認する
- データイン レプリケーションの詳細を確認する
- データイン レプリケーションの構成方法
- 読み取りレプリカを使用した Azure でのレプリケートの詳細