コンソールにサインインする
Amazon Aurora
Aurora のユーザーガイド (API バージョン 2014-10-31)

AWS ドキュメント » Amazon Relational Database Service (RDS) » Aurora のユーザーガイド » Amazon Aurora MySQL の操作 » Amazon Aurora MySQL とのレプリケーション » Aurora と MySQL との間、または Aurora と別の Aurora DB クラスターとの間のレプリケーション

Aurora と MySQL との間、または Aurora と別の Aurora DB クラスターとの間のレプリケーション

Amazon Aurora MySQL は MySQL と互換性があるため、MySQL データベースと Amazon Aurora MySQL DB クラスターとの間のレプリケーションを設定できます。MySQL データベースでは MySQL のバージョン 5.5 以降を実行することをお勧めします。Aurora MySQL DB クラスターをレプリケーションマスターまたはレプリカとしてレプリケーションを設定して、Amazon RDS MySQL DB インスタンス（Amazon RDS の外部 MySQL データベース）または別の Aurora MySQL DB クラスターにレプリケートできます。

また、別の AWS リージョンで Amazon RDS MySQL DB インスタンス、または Aurora MySQL DB クラスターにレプリケートすることもできます。AWS リージョン間のレプリケーションを実行するときは、DB クラスターと DB インスタンスがパブリックにアクセス可能であることを確認してください。Aurora MySQL DB クラスターは、VPC のパブリックサブネットの一部である必要があります。

Aurora MySQL DB クラスターと Aurora MySQL DB クラスター間のレプリケーションを別のリージョンに設定する場合、Aurora MySQL DB クラスターをソース DB クラスターとは異なる AWS リージョン内のリードレプリカとして作成できます。詳細については、「AWS リージョン間での Amazon Aurora MySQL DB クラスターのレプリケート」を参照してください。

Aurora MySQL 2.04 以上では、レプリケーションにグローバルトランザクション識別子 (GTID) を使用するソースまたはターゲットと Aurora MySQL との間でレプリケートできます。Aurora MySQL DB クラスターの GTID 関連のパラメータ内に、外部データベースの GTID ステータスと互換性がある設定が含まれていることを確認してください。これを行う方法については、「 Aurora MySQL の GTID ベースレプリケーションを使用する」を参照してください。

警告

Aurora MySQL と MySQL との間でレプリケートする場合は、必ず InnoDB テーブルのみを使用します。MyISAM テーブルをレプリケートする場合は、これらのテーブルを以下のコマンドを使用して InnoDB に変換してから、レプリケーションを設定できます。 


alter table <schema>.<table_name> engine=innodb, algorithm=copy;

Aurora MySQL と MySQL との間でレプリケーションを設定するには、次のステップを使用します。各ステップについて以下に詳しく説明します。

1.レプリケーションマスターのバイナリログ記録を有効にする

2.不要になるまでレプリケーションマスターのバイナリログを保持する

3.レプリケーションマスターのスナップショットを作成する

4.レプリカターゲットにスナップショットをロードする

5.レプリカターゲットでレプリケーションを有効にする

6.レプリカをモニタリングする

MySQL または別の Aurora DB クラスターとのレプリケーションの設定

MySQL を使用して Aurora レプリケーションをセットアップするには、次のステップに従います。

1.レプリケーションマスターのバイナリログ記録を有効にする

以下のデータベースエンジンのバイナリログ記録をレプリケーションマスターで有効にする手順を確認します。

データベースエンジン Instructions

Aurora

Aurora MySQL DB クラスターのバイナリログ記録を有効にするには

binlog_format パラメータを ROW、STATEMENT、または MIXED に設定します。特定のバイナリログ形式の必要性がない限り MIXED をお勧めします。binlog_format パラメータはクラスターレベルのパラメータであり、デフォルトクラスターパラメータグループにあります。 binlog_format パラメータを OFF から別の値に変更した場合、変更を有効にするために Aurora DB クラスターを再起動する必要があります。

詳細については、「Amazon Aurora DB クラスターパラメータと DB インスタンスパラメータ」および「DB パラメータグループおよび DB クラスターパラメータグループを使用する」を参照してください。

RDS MySQL

Amazon RDS DB インスタンスのバイナリログ記録を有効にするには

Amazon RDS DB インスタンスのバイナリログ記録を直接有効にすることはできませんが、以下のいずれかの操作により有効にすることができます。

MySQL (外部)

暗号化レプリケーションを設定するには

Aurora MySQL バージョン 5.6 を使用してデータを安全に複製するには、暗号化されたレプリケーションを使用できます。

現在、外部の MySQL データベースからの暗号化されたレプリケーションは Aurora MySQL バージョン 5.6 でのみサポートされています。

注記

暗号化レプリケーションを使う必要がない場合、このステップをスキップできます。

暗号化レプリケーションを使用するための前提条件は次のとおりです。

  • Secure Sockets Layer (SSL) は、外部の MySQL マスターデータベースで有効化されている必要があります。

  • クライアントのキーとクライアントの証明書が Aurora MySQL DB クラスター用に準備されている必要があります。

暗号化のレプリケーション中、Aurora MySQL DB クラスターはクライアントとして MySQL データベースサーバーに動作します。Aurora MySQL 用の証明書およびキーは、.pem 形式のファイルにあります。

  1. 暗号化レプリケーションのための準備があることを確認してください。

    • 外部の MySQL マスターデータベースで有効化された SSL がなく、またクライアントキーおよびクライアント証明書が準備されていない場合、MySQL データベースサーバーで SSL を有効にし、必要なクライアントキーおよびクライアントの証明書を生成します。

    • SSL が外部マスターで有効化されている場合には、Aurora MySQL DB クラスターにクライアントキーおよび証明書を提供します。これらがない場合は、Aurora MySQL DB クラスター用に新しいキーと証明書を生成します。クライアント証明書に署名するには、外部の MySQL マスターデータベースで SSL を設定した際に使用した認証機関キーがあることが必要です。

    詳細については、MySQL のドキュメントの「Creating SSL Certificates and Keys Using openssl (openssl を使用した SSL 証明書およびキーの作成)」を参照してください。

    認証機関証明書、クライアントキーおよびクライアント証明書が必要となります。

  2. SSL を使用して、マスターユーザーとして Aurora MySQL DB クラスターに接続します。

    SSL で Aurora MySQL DB クラスターに接続する詳細については、「Aurora MySQL DB クラスターでの SSL の使用」を参照してください。

  3. mysql.rds_import_binlog_ssl_material ストアドプロシージャを実行して、Aurora MySQL DB クラスターに SSL 情報をインポートします。

    ssl_material_value パラメータには、正しい JSON ペイロードで Aurora MySQL DB クラスター用の .pem 形式から情報を挿入します。

    次の例では、SSL 情報を Aurora MySQL DB クラスターにインポートします。.pem 形式ファイルでは、通常の場合、コード本文に例に示されるコード本文より長くなっています。

    call mysql.rds_import_binlog_ssl_material(
'{"ssl_ca":"-----BEGIN CERTIFICATE-----
AAAAB3NzaC1yc2EAAAADAQABAAABAQClKsfkNkuSevGj3eYhCe53pcjqP3maAhDFcvBS7O6V
hz2ItxCih+PnDSUaw+WNQn/mZphTk/a/gU8jEzoOWbkM4yxyb/wB96xbiFveSFJuOp/d6RJhJOI0iBXr
lsLnBItntckiJ7FbtxJMXLvvwJryDUilBMTjYtwB+QhYXUMOzce5Pjz5/i8SeJtjnV3iAoG/cQk+0FzZ
qaeJAAHco+CY/5WrUBkrHmFJr6HcXkvJdWPkYQS3xqC0+FmUZofz221CBt5IMucxXPkX4rWi+z7wB3Rb
BQoQzd8v7yeb7OzlPnWOyN0qFU0XA246RA8QFYiCNYwI3f05p6KLxEXAMPLE
-----END CERTIFICATE-----\n","ssl_cert":"-----BEGIN CERTIFICATE-----
AAAAB3NzaC1yc2EAAAADAQABAAABAQClKsfkNkuSevGj3eYhCe53pcjqP3maAhDFcvBS7O6V
hz2ItxCih+PnDSUaw+WNQn/mZphTk/a/gU8jEzoOWbkM4yxyb/wB96xbiFveSFJuOp/d6RJhJOI0iBXr
lsLnBItntckiJ7FbtxJMXLvvwJryDUilBMTjYtwB+QhYXUMOzce5Pjz5/i8SeJtjnV3iAoG/cQk+0FzZ
qaeJAAHco+CY/5WrUBkrHmFJr6HcXkvJdWPkYQS3xqC0+FmUZofz221CBt5IMucxXPkX4rWi+z7wB3Rb
BQoQzd8v7yeb7OzlPnWOyN0qFU0XA246RA8QFYiCNYwI3f05p6KLxEXAMPLE
-----END CERTIFICATE-----\n","ssl_key":"-----BEGIN RSA PRIVATE KEY-----
AAAAB3NzaC1yc2EAAAADAQABAAABAQClKsfkNkuSevGj3eYhCe53pcjqP3maAhDFcvBS7O6V
hz2ItxCih+PnDSUaw+WNQn/mZphTk/a/gU8jEzoOWbkM4yxyb/wB96xbiFveSFJuOp/d6RJhJOI0iBXr
lsLnBItntckiJ7FbtxJMXLvvwJryDUilBMTjYtwB+QhYXUMOzce5Pjz5/i8SeJtjnV3iAoG/cQk+0FzZ
qaeJAAHco+CY/5WrUBkrHmFJr6HcXkvJdWPkYQS3xqC0+FmUZofz221CBt5IMucxXPkX4rWi+z7wB3Rb
BQoQzd8v7yeb7OzlPnWOyN0qFU0XA246RA8QFYiCNYwI3f05p6KLxEXAMPLE
-----END RSA PRIVATE KEY-----\n"}');

    インポートされたキーマテリアルの詳細については、「 mysql_rds_import_binlog_ssl_material」および「Aurora MySQL DB クラスターでの SSL の使用」を参照してください。

    注記

    手順を実行したあと、シークレットはファイルに保存されます。ファイルを削除するには、mysql_rds_remove_binlog_ssl_material ストアドプロシージャを実行できます。

外部 MySQL データベースのバイナリログ記録を有効にするには

  1. コマンドラインシェルから、mysql サービスを停止します。

    sudo service mysqld stop

  2. my.cnf ファイルを編集します (このファイルは通常 /etc にあります)。

    sudo vi /etc/my.cnf

    log_bin オプションと server_id オプションを [mysqld] に追加します。log_bin オプションは、バイナリログファイルのファイル名識別子を提供します。server_id オプションは、マスターとレプリカの関係のサーバーに一意の識別子を提供します。

    暗号化レプリケーションが求められない場合、外部 MySQL データベースでバイナリログが有効化され、SSL が無効化された状態で開始することを確認します。

    以下に示すのは、非暗号化データ用の /etc/my.cnf ファイルの関連するエントリです。

    
log-bin=mysql-bin
server-id=2133421
innodb_flush_log_at_trx_commit=1
sync_binlog=1

    暗号化レプリケーションが求められる場合、外部 MySQL データベースが SSL およびバイナリログ有効化された状態で開始することを確認します。

    /etc/my.cnf ファイルのエントリには、MySQL データベースサーバーのための .pem ファイルの場所が含まれます。

    
log-bin=mysql-bin
server-id=2133421
innodb_flush_log_at_trx_commit=1
sync_binlog=1
                            
# Setup SSL.
ssl-ca=/home/sslcerts/ca.pem
ssl-cert=/home/sslcerts/server-cert.pem
ssl-key=/home/sslcerts/server-key.pem

    また、MySQL DB インスタンスの sql_mode オプションを 0 に設定するか、my.cnf ファイルから除外する必要があります。

    外部の MySQL データベースに接続するときに、外部の MySQL データベースのバイナリログの場所を記録します。

    
mysql> SHOW MASTER STATUS;

    出力は次のようになります。

    
+------------------+----------+--------------+------------------+-------------------+
| File             | Position | Binlog_Do_DB | Binlog_Ignore_DB | Executed_Gtid_Set |
+------------------+----------+--------------+------------------+-------------------+
| mysql-bin.000031 |      107 |              |                  |                   |
+------------------+----------+--------------+------------------+-------------------+
1 row in set (0.00 sec)

    詳細については、MySQL のドキュメントの「レプリケーションマスター構成の設定」を参照してください。

  3. mysql サービスを開始します。

    sudo service mysqld start

2.不要になるまでレプリケーションマスターのバイナリログを保持する

MySQL バイナリログのレプリケーションを使用しているとき、Amazon RDS によってレプリケーションプロセスは管理されません。したがって、レプリケーションマスターのバイナリログファイルは、変更がレプリカに適用されるまで保持する必要があります。バイナリログが保持されていれば、障害発生時にマスターデータベースを復元できます。

以下のデータベースエンジンのバイナリログを維持する手順を確認します。

データベースエンジン Instructions

Aurora

Aurora MySQL DB クラスターのバイナリログを保持するには

Aurora MySQL DB クラスターのバイナリログファイルにはアクセスできません。そのため、確実に変更がレプリカに適用されてから、レプリケーションマスターのバイナリログファイルが Amazon RDS によって削除されるように、バイナリログファイルの保持期間は十分に長く設定する必要があります。Aurora MySQL DB クラスターのバイナリログファイルは最大 90 日間、保持できます。

MySQL データベースまたは RDS MySQL DB インスタンスをレプリカとしてレプリケーションを設定する場合、レプリカを作成するデータベースが巨大であれば、レプリカへのデータベースの最初のコピーが完了し、レプリカラグが 0 に達するまで、バイナリログファイルが保持されるように、その保持期間は長く設定してください。

バイナリログの保持タイムフレームを設定するには、「mysql_rds_set_configuration」の手順を使用して、DB クラスターのバイナリログファイルの保持期間に合わせて、'binlog retention hours' の設定パラメータを指定します。最大値は 2160 (90 日) です。以下の例では、バイナリログファイルの保持期間を 6 日に設定しています。 

CALL mysql.rds_set_configuration('binlog retention hours', 144);

レプリケーションが開始された後、レプリカに対して SHOW SLAVE STATUS コマンドを実行し、[Seconds behind master] フィールドを調べることで、変更がレプリカに適用されていることを確認できます。[Seconds behind master] フィールドが 0 の場合、レプリカラグはありません。レプリカラグがないときは、binlog retention hours 設定パラメータをより短い期間に設定することで、バイナリログファイルの保持期間を短くします。

'binlog retention hours' に 2160 より大きい値を指定した場合は、2160 が使用されます。

RDS MySQL

Amazon RDS DB インスタンスのバイナリログを保持するには

前のセクションで説明しているように、Amazon RDS DB インスタンスのバイナリログファイルを保持するには、その保持期間を Aurora MySQL DB クラスターのものと同様に設定します。

DB インスタンスのリードレプリカを作成しても、Amazon RDS DB インスタンスのバイナリログファイルを保持できます。このリードレプリカはバイナリログファイルの保持専用に一時的に作成されます。作成されたリードレプリカに対して mysql_rds_stop_replication プロシージャを呼び出します (mysql.rds_stop_replication プロシージャは MySQL バージョン 5.5、5.6 以降、および 5.7 以降でのみ使用可能)。レプリケーションの停止中に Amazon RDS がレプリケーションマスターのバイナリログファイルを削除することはありません。永続レプリカとのレプリケーションを設定した後、レプリケーションマスターと永続レプリカとの間のレプリカラグ（[Seconds behind master] フィールド）が 0 に達したときに、リードレプリカを削除できます。

MySQL (外部)

外部 MySQL データベースのバイナリログを有効にするには

外部 MySQL データベースのバイナリログファイルは Amazon RDS によって管理されていないため、手動で削除されるまでは保持されます。

レプリケーションが開始された後、レプリカに対して SHOW SLAVE STATUS コマンドを実行し、[Seconds behind master] フィールドを調べることで、変更がレプリカに適用されていることを確認できます。[Seconds behind master] フィールドが 0 の場合、レプリカラグはありません。レプリカラグがないときは、古いバイナリログファイルを削除できます。

3.レプリケーションマスターのスナップショットを作成する

レプリケーションマスターのスナップショットは、レプリカにデータのベースラインコピーをロードし、その時点からレプリケーションを開始するために使用します。

以下のデータベースエンジンのレプリケーションマスターのスナップショットを作成する手順を確認します。

データベースエンジン Instructions

Aurora

Aurora MySQL DB クラスターのスナップショットを作成するには

  1. Amazon Aurora DB クラスターのスナップショットを作成します。詳細については、「DB クラスタースナップショットの作成」を参照してください。

  2. 先ほど作成した DB クラスターのスナップショットから復元することで、新しい Aurora DB クラスターを作成します。復元された DB クラスターの DB パラメータグループは、元の DB クラスターと同一のものを維持してください。これを実行することで、DB クラスターのコピーでも確実にバイナリログ作成が有効になります。詳細については、「DB クラスタースナップショットの復元」を参照してください。

  3. コンソールで、[データベース] を選択し、復元された Aurora DB クラスターのプライマリインスタンス (書き込み) を選択してその詳細を表示します。[最近のイベント] までスクロールします。binlog ファイル名と場所を含むイベントメッセージが表示されます。イベントメッセージの形式は以下のとおりです。 

    Binlog position from crash recovery is binlog-file-name binlog-position

    レプリケーションを開始したときの binlog ファイルの名前と場所の値を保存します。

    AWS CLI から describe-events コマンドを呼び出して、binlog ファイルの名前と場所を取得することもできます。次に describe-events コマンドの例とサンプル出力を示します。 

    PROMPT> aws rds describe-events
    {
    "Events": [
        {
            "EventCategories": [],
            "SourceType": "db-instance",
            "SourceArn": "arn:aws:rds:us-west-2:123456789012:db:sample-restored-instance",
            "Date": "2016-10-28T19:43:46.862Z",
            "Message": "Binlog position from crash recovery is mysql-bin-changelog.000003 4278",
            "SourceIdentifier": "sample-restored-instance"
        }
    ]
}

    binlog ファイルの名前と位置は、MySQL バイナリログファイルの最後の場所、または DB_CRASH_RECOVERY_BINLOG_POSITION エントリの MySQL エラーログを調べることでも確認できます。

  4. レプリカターゲットが別の AWS アカウントが所有する Aurora DB クラスター、外部 MySQL データベース、または RDS MySQL DB インスタンスである場合、Amazon Aurora DB クラスターのスナップショットからデータをロードすることはできません。代わりに、MySQL クライアントを使用して DB クラスターに接続し、mysqldump コマンドを発行することで、Amazon Aurora DB クラスターのダンプを作成します。作成した Amazon Aurora DB クラスターのコピーに対して必ず mysqldump コマンドを実行してください。次に例を示します。 

    PROMPT> mysqldump --databases <database_name> --single-transaction 
--order-by-primary -r backup.sql -u <local_user> -p

  5. 新しく作成した Aurora DB クラスターからデータのダンプを作成し終わったら、その DB クラスターはもう不要なため削除します。

RDS MySQL

Amazon RDS DB インスタンスのスナップショットを作成するには

  1. Amazon RDS DB インスタンスのリードレプリカを作成します。リードレプリカの作成の詳細については、Amazon Relational Database Service ユーザーガイドの「リードレプリカの作成」を参照してください。

  2. リードレプリカに接続し、 mysql_rds_stop_replication の手順を実行することでレプリケーションを停止します。

  3. リードレプリカが [Stopped] の状態で、リードレプリカに接続し、SHOW SLAVE STATUS コマンドを実行します。Relay_Master_Log_File フィールドから現在のバイナリログファイルの名前を、Exec_Master_Log_Pos フィールドからそのログファイルの場所を取得します。レプリケーションを開始するときのために、これらの値を保存します。

  4. リードレプリカが [Stopped] の状態のままで、リードレプリカの DB スナップショットを作成します。DB スナップショットの作成の詳細については、「DB クラスタースナップショットの作成」を参照してください。

  5. リードレプリカを削除します。

MySQL (外部)

外部 MySQL データベースのスナップショットを作成するには

  1. スナップショットを作成する前に、スナップショットのバイナリログの場所がマスターインスタンスのデータで更新されている必要があります。そのためには、まず以下のコマンドを使用して、インスタンスへの書き込みオペレーションを停止する必要があります。

    
mysql> FLUSH TABLES WITH READ LOCK;

  2. 以下の mysqldump コマンドを使用して、MySQL データベースのダンプを作成します。 

    
PROMPT> sudo mysqldump --databases <database_name> --master-data=2  --single-transaction \
--order-by-primary -r backup.sql -u <local_user> -p

  3. スナップショットを作成した後、以下のコマンドを実行して、MySQL データベースのテーブルのロックを解除します。

    
mysql> UNLOCK TABLES;

4.レプリカターゲットにスナップショットをロードする

Amazon RDS の外部 MySQL データベースのダンプからデータをロードする場合、ダンプファイルのコピー先となる EC2 インスタンスを作成してから、その EC2 インスタンスから DB クラスターまたは DB インスタンスにデータをロードします。この方法では、ダンプファイルを EC2 インスタンスにコピーする前に圧縮して、Amazon RDS へのデータのコピーに関連するネットワークコストを削減できます。また、ダンプファイルを暗号化して、ネットワーク経由で転送されるデータを保護することもできます。

以下のデータベースエンジンのレプリカターゲットにレプリケーションマスターのスナップショットをロードする手順について説明します。

データベースエンジン Instructions

Aurora

Aurora MySQL DB クラスターにスナップショットをロードするには

  • レプリケーションマスターのスナップショットが DB クラスターのスナップショットである場合は、DB クラスターのスナップショットから復元することで、レプリカターゲットとして新しい Aurora MySQL DB クラスターを作成できます。詳細については、「DB クラスタースナップショットの復元」を参照してください。

  • レプリケーションマスターのスナップショットが DB スナップショットである場合は、DB スナップショットから新しい Aurora MySQL DB クラスターにデータを移行できます。詳細については、「Amazon Aurora DB クラスターへのデータの移行」を参照してください。

  • レプリケーションマスターのスナップショットが mysqldump コマンドの出力である場合は、以下の手順を実行します。

    1. mysqldump コマンドの出力をレプリケーションマスターから、Aurora MySQL DB クラスターにも接続できる場所にコピーします。

    2. mysql コマンドを使用して Aurora MySQL DB クラスターに接続します。次に例を示します。 

      PROMPT> mysql -h <host_name> -port=3306 -u <db_master_user> -p

    3. mysql プロンプトで、データベースダンプファイルの名前を渡して source コマンドを実行することで、Aurora MySQL DB クラスターにデータをロードします。たとえば、以下のようになります。 

      
mysql> source backup.sql;

RDS MySQL

Amazon RDS DB インスタンスにスナップショットをロードするには

  1. mysqldump コマンドの出力をレプリケーションマスターから、MySQL DB インスタンスにも接続できる場所にコピーします。

  2. mysql コマンドを使用して MySQL DB インスタンスに接続します。次に例を示します。 

    PROMPT> mysql -h <host_name> -port=3306 -u <db_master_user> -p

  3. mysql プロンプトで、データベースダンプファイルの名前を渡して source コマンドを実行することで、MySQL DB インスタンスにデータをロードします。たとえば、以下のようになります。 

    
mysql> source backup.sql;

MySQL (外部)

外部 MySQL データベースにスナップショットをロードするには

外部 MySQL データベースに DB スナップショットまたは DB クラスターのスナップショットをロードすることはできません。代わりに、mysqldump コマンドの出力を使用する必要があります。

  1. mysqldump コマンドの出力をレプリケーションマスターから、MySQL データベースにも接続できる場所にコピーします。

  2. mysql コマンドを使用して MySQL データベースに接続します。次に例を示します。 

    PROMPT> mysql -h <host_name> -port=3306 -u <db_master_user> -p

  3. mysql プロンプトで、データベースダンプファイルの名前を渡して source コマンドを実行することで、MySQL データベースにデータをロードします。次に例を示します。 

    
mysql> source backup.sql;

5.レプリカターゲットでレプリケーションを有効にする

レプリケーションを有効化する前に、Aurora MySQL DB クラスターまたは RDS MySQL DB インスタンスレプリカターゲットのスナップショットを手動で作成することをお勧めします。問題が発生し、DB クラスターまたは DB インスタンスレプリカターゲットとのレプリケーションを再開する必要がある場合は、このスナップショットから DB クラスターまたは DB インスタンスを復元できます。そのために、再びレプリカターゲットにデータをインポートする必要はありません。

また、レプリケーション専用のユーザー ID を作成します。次に例を示します。


mysql> CREATE USER 'repl_user'@'<domain_name>' IDENTIFIED BY '<password>';

ユーザーには REPLICATION CLIENT および REPLICATION SLAVE 権限が必要です。ユーザーのこれらの権限を付与します。 


GRANT REPLICATION CLIENT, REPLICATION SLAVE ON *.* TO 'repl_user'@'<domain_name>';

暗号化レプリケーションを使用する必要がある場合は、レプリケーションのユーザーに対して SSL 接続を要求します。たとえば、以下のいずれかのステートメントを使用して、ユーザーアカウント repl_user に SSL 接続を要求できます。 


GRANT USAGE ON *.* TO 'repl_user'@'<domain_name>' REQUIRE SSL;

注記

REQUIRE SSL が含まれていない場合には、レプリケーション接続がメッセージの表示なしで非暗号化接続に戻る場合があります。

以下のデータベースエンジンの以下のレプリケーションを有効にする手順を確認します。

データベースエンジン Instructions

Aurora

Aurora MySQL DB クラスターからのレプリケーションを有効にするには

  1. DB クラスターレプリカターゲットが DB クラスターのスナップショットから作成された場合は、その DB クラスターレプリカターゲットに接続し、SHOW MASTER STATUS コマンドを発行します。File フィールドから現在のバイナリログファイルの名前を、Position フィールドからそのログファイルの場所を取得します。

    DB クラスターレプリカターゲットが DB スナップショットから作成された場合は、レプリケーションにはまずバイナリログファイルの名前と場所が必要になります。レプリケーションマスターのスナップショットを作成したとき、SHOW SLAVE STATUS コマンドからこれらの値を取得しました。

  2. DB クラスターに接続し、前の手順からのバイナリログファイルの名前と場所を使用して mysql_rds_set_external_master および mysql_rds_start_replication 手順を発行することで、レプリケーションマスターとのレプリケーションを開始します。次に例を示します。 

    CALL mysql.rds_set_external_master ('mydbinstance.123456789012.us-east-1.rds.amazonaws.com', 3306,                                                
    'repl_user', '<password>', 'mysql-bin-changelog.000031', 107, 0);
    CALL mysql.rds_start_replication;

RDS MySQL

Amazon RDS DB インスタンスからのレプリケーションを有効にするには

  1. DB インスタンスレプリカターゲットが DB スナップショットから作成された場合は、レプリケーションにはまずバイナリログファイルの名前と場所が必要になります。レプリケーションマスターのスナップショットを作成したとき、SHOW SLAVE STATUS コマンドからこれらの値を取得しました。

  2. DB インスタンスに接続し、前の手順からのバイナリログファイルの名前と場所を使用して mysql_rds_set_external_master および mysql_rds_start_replication 手順を発行することで、レプリケーションマスターとのレプリケーションを開始します。次に例を示します。 

    CALL mysql.rds_set_external_master ('mydbcluster.cluster-123456789012.us-east-1.rds.amazonaws.com', 3306,
    'repl_user', '<password>', 'mysql-bin-changelog.000031', 107, 0);
CALL mysql.rds_start_replication;

MySQL (外部)

外部 MySQL データベースからのレプリケーションを有効にするには

  1. レプリケーションにまず必要になるバイナリログファイルの名前と場所を取得します。レプリケーションマスターのスナップショットを作成したとき、SHOW SLAVE STATUS コマンドからこれらの値を取得しました。外部の MySQL レプリカターゲットへのデータロードに mysqldump オプションを指定して実行した --master-data=2 コマンドの出力を使用した場合は、その出力にバイナリログファイルの名前と場所が含まれています。次に例を示します。 

    --
-- Position to start replication or point-in-time recovery from
--

-- CHANGE MASTER TO MASTER_LOG_FILE='mysql-bin-changelog.000031', MASTER_LOG_POS=107;

  2. 外部の MySQL レプリカターゲットに接続し、前の手順からのバイナリログファイルの名前と場所を使用して CHANGE MASTER TO および START SLAVE を発行することで、レプリケーションマスターとのレプリケーションを開始します。次に例を示します。 

    
CHANGE MASTER TO 
  MASTER_HOST = 'mydbcluster.cluster-123456789012.us-east-1.rds.amazonaws.com',
  MASTER_PORT = 3306,
  MASTER_USER = 'repl_user',
  MASTER_PASSWORD = '<password>',
  MASTER_LOG_FILE = 'mysql-bin-changelog.000031',
  MASTER_LOG_POS = 107;
START SLAVE;

6.レプリカをモニタリングする

Aurora MySQL DB クラスターと MySQL との間のレプリケーションを設定する場合、Aurora MySQL DB クラスターがレプリカターゲットであれば、そのクラスターのフェイルオーバーイベントをモニタリングする必要があります。フェイルオーバーが発生すると、レプリカターゲットである DB クラスターが、新しいホスト上に別のネットワークアドレスで再作成されます。フェイルオーバーイベントをモニタリングする方法については、「Amazon RDS イベント通知の使用」を参照してください。

また、レプリカターゲットに接続し、SHOW SLAVE STATUS コマンドを実行することで、レプリケーションマスターからレプリカターゲットへのコピーの進行状況をモニタリングできます。このコマンドの出力の Seconds Behind Master フィールドに、マスターからレプリカターゲットへのコピーの進行状況が示されます。

Aurora と MySQL 間または Aurora と別の Aurora DB クラスター間でのレプリケーションの停止

MySQL DB インスタンス、外部 MySQL データベース、または別の Aurora DB クラスターでのバイナリログのレプリケーションを停止するには、このトピックの後で詳しく説明するステップに従ってください。

1.レプリカターゲットでバイナリログのレプリケーションを停止する

2.レプリケーションマスターのバイナリログ記録を無効にする

1.レプリカターゲットでバイナリログのレプリケーションを停止する

以下のデータベースエンジンのバイナリログレプリケーションを停止する手順を確認します。

データベースエンジン Instructions

Aurora

Aurora MySQL DB クラスターレプリカターゲットでのバイナリログのレプリケーションを停止するには

レプリカターゲットである Aurora DB クラスターに接続し、 mysql_rds_stop_replication 手順を呼び出します。mysql.rds_stop_replication 手順は、MySQL のバージョン 5.5 以降、5.6 以降、および 5.7 以降のみで利用できます。

RDS MySQL

Amazon RDS DB インスタンスのバイナリログのレプリケーションを停止するには

レプリカターゲットである RDS DB インスタンスに接続し、 mysql_rds_stop_replication 手順を呼び出します。mysql.rds_stop_replication 手順は、MySQL のバージョン 5.5 以降、5.6 以降、および 5.7 以降のみで利用できます。

MySQL (外部)

外部 MySQL データベースのバイナリログのレプリケーションを停止するには

MySQL データベースに接続して、STOP REPLICATION コマンドを呼び出します。

2.レプリケーションマスターのバイナリログ記録を無効にする

以下のデータベースエンジンのバイナリログ記録をレプリケーションマスターで無効にする手順を確認します。

データベースエンジン Instructions

Aurora

Amazon Aurora DB クラスターのバイナリログ記録を無効にするには

  1. レプリケーションマスターである Aurora DB クラスターに接続し、バイナリログの保持タイムフレームを 0 に設定します。バイナリログの保持期間を設定するには、mysql_rds_set_configuration の手順を使用して、DB クラスターのバイナリログファイルの保持期間に合わせて、'binlog retention hours' の設定パラメータを指定します。この場合は、以下の例にあるように、0 です。 

    CALL mysql.rds_set_configuration('binlog retention hours', 0);

  2. レプリケーションマスターで binlog_format パラメータを OFF に設定します。binlog_format パラメータはクラスターレベルのパラメータであり、デフォルトクラスターパラメータグループにあります。

    binlog_format パラメータ値を変更した後、変更を有効にするために DB クラスターを再起動します。

    詳細については、「Amazon Aurora DB クラスターパラメータと DB インスタンスパラメータ」および「DB パラメータグループのパラメータの変更」を参照してください。

RDS MySQL

Amazon RDS DB インスタンスのバイナリログ記録を無効にするには

Amazon RDS DB インスタンスのバイナリログ記録は、直接無効にすることはできませんが、以下のいずれかの操作により無効にできます。

  1. DB インスタンスの自動バックアップを無効にする。既存の DB インスタンスを変更して [Backup Retention Period] を 0 に設定することで、自動バックアップを無効にできます。詳細については、Amazon Relational Database Service ユーザーガイドの「MySQL データベースエンジンを実行する DB インスタンスの変更」および「バックアップの使用」を参照してください。

  2. DB インスタンスのすべてのリードレプリカを削除する。詳細については、Amazon Relational Database Service ユーザーガイドの「MariaDB、MySQL、および PostgreSQL DB インスタンスのリードレプリカの使用」を参照してください。

MySQL (外部)

外部 MySQL データベースのバイナリログ記録を無効にするには

MySQL データベースに接続して、STOP REPLICATION コマンドを呼び出します。

  1. コマンドラインシェルから、mysql サービスを停止します。

    sudo service mysqld stop

  2. my.cnf ファイルを編集します (このファイルは通常 /etc にあります)。

    sudo vi /etc/my.cnf

    log_bin セクションから server_id および [mysqld] オプションを削除します。

    詳細については、MySQL のドキュメントの「レプリケーションマスター構成の設定」を参照してください。

  3. mysql サービスを開始します。

    sudo service mysqld start