メニュー
Amazon Relational Database Service
ユーザーガイド (API Version 2014-10-31)

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

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

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

注意

Amazon Aurora と MySQL との間のレプリケーションを実行するときは、InnoDB テーブルのみを使用していることを確認してください。MyISAM テーブルをレプリケートする場合は、レプリケーションを設定する前に、以下のコマンドを使用してそれらのテーブルを InnoDB に変換できます。

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

Amazon Aurora と MySQL との間のレプリケーションの設定には、以下のステップが含まれます。これらのステップについては、このトピックの次に詳しく説明しています。

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

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

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

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

5. レプリケーションを有効にする

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

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

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

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

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

データベースエンジン Instructions

Aurora

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

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

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

RDS MySQL

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

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

MySQL (外部)

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

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

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

    Copy
    sudo vi /etc/my.cnf

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

    次の例は、my.cnf ファイルの更新された [mysqld] セクションを示しています。

    Copy
    [mysqld] log-bin=mysql-bin server-id=1

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

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

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

    Copy
    sudo service mysqld start

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

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

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

データベースエンジン Instructions

Aurora

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

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

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

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

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

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

RDS MySQL

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

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

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

MySQL (外部)

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

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

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

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

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

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

データベースエンジン Instructions

Aurora

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

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

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

  3. コンソールで [Instances] を選択し、復元する Aurora DB クラスターのプライマリインスタンス (ライター) を選択します。[Alarms and Recent Events] を表示します。binlog ファイル名と場所を含むイベントメッセージが表示されます。イベントメッセージの形式は以下のとおりです。

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

    たとえば、次は binlog ファイル名 mysql-bin-changelog.000003 で binlog の場所が 4278 のイベントメッセージです。

     Amazon Aurora binlog ファイルの名前と場所

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

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

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

    Copy
    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 インスタンスのリードレプリカを作成します。リードレプリカの作成の詳細については、「リードレプリカの作成」を参照してください。

  2. リードレプリカに接続し、mysql.rds_stop_replication コマンドを実行することでレプリケーションを停止します。

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

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

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

MySQL (外部)

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

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

    Copy
    mysql> FLUSH TABLES WITH READ LOCK;
  2. 以下の mysqldump コマンドを使用して、MySQL データベースのダンプを作成します。

    Copy
    PROMPT> sudo mysqldump --databases <database_name> --master-data=2 --single-transaction --order-by-primary -r backup.sql -u <local_user> -p
  3. スナップショットを作成した後、以下のコマンドを実行して、MySQL データベースのテーブルのロックを解除します。

    Copy
    mysql> UNLOCK TABLES;

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

レプリカにレプリケーションマスターのスナップショットをロードする前に、以下のことを必ず検討してください。

  • AWS リージョン間のレプリケーションを実行する場合は、Amazon Aurora DB クラスターのスナップショットを使用してレプリカをロードすることはできません。DB クラスターのスナップショットはリージョン間でコピーすることはできません。リージョン間のレプリケーションを実行するために、別のリージョンで RDS MySQL DB インスタンスの DB スナップショットから Amazon Aurora DB インスタンスを作成できます。レプリケーションスレーブがホストされるリージョンに DB スナップショットをコピーし、そのスナップショットから Amazon Aurora DB クラスターまたは MySQL DB インスタンスを作成します。他のリージョンへのスナップショットのコピーの詳細については、「DB スナップショットのコピーまたは DB クラスタースナップショット」を参照してください。

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

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

データベースエンジン Instructions

Aurora

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

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

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

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

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

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

      Copy
      PROMPT> mysql -h <host_name> -port=3306 -u <db_master_user> -p
    3. mysql プロンプトで、データベースダンプファイルの名前を渡して source コマンドを実行することで、Amazon Aurora DB クラスターにデータをロードします。たとえば、以下のようになります。

      Copy
      mysql> source backup.sql;

RDS MySQL

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

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

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

    Copy
    PROMPT> mysql -h <host_name> -port=3306 -u <db_master_user> -p
  3. mysql プロンプトで、データベースダンプファイルの名前を渡して source コマンドを実行することで、MySQL DB インスタンスにデータをロードします。たとえば、以下のようになります。

    Copy
    mysql> source backup.sql;

MySQL (外部)

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

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

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

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

    Copy
    PROMPT> mysql -h <host_name> -port=3306 -u <db_master_user> -p
  3. mysql プロンプトで、データベースダンプファイルの名前を渡して source コマンドを実行することで、MySQL データベースにデータをロードします。たとえば、以下のようになります。

    Copy
    mysql> source backup.sql;

5. レプリケーションを有効にする

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

レプリケーション専用のユーザー ID を作成することもできます。そのユーザー ID には REPLICATION CLIENT および REPLICATION SLAVE 特権が必要になります。次に例を示します。

Copy
REPLICATION CLIENT and REPLICATION SLAVE privileges. For example: CREATE USER 'repl_user'@'mydomain.com' IDENTIFIED BY '<password>'; GRANT REPLICATION CLIENT, REPLICATION SLAVE ON *.* TO 'repl_user'@'mydomain.com' IDENTIFIED BY '<password>';

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

データベースエンジン Instructions

Aurora

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

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

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

    DB クラスターへのデータのロードに、--master-data=2 オプションを指定して実行した mysqldump コマンドの出力を使用した場合は、その出力にバイナリログファイルの名前と場所が含まれています。次に例を示します。

    Copy
    -- -- Position to start replication or point-in-time recovery from -- -- CHANGE MASTER TO MASTER_LOG_FILE='mysql-bin-changelog.000001', MASTER_LOG_POS=107;
  2. DB クラスターに接続し、前の手順からのバイナリログファイルの名前と場所を使用して mysql.rds_set_external_master および mysql.rds_start_replication コマンドを発行することで、レプリケーションマスターとのレプリケーションを開始します。次に例を示します。

    Copy
    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 コマンドからこれらの値を取得しました。

    DB インスタンスへのデータのロードに、--master-data=2 オプションを指定して実行した mysqldump コマンドの出力を使用した場合は、その出力にバイナリログファイルの名前と場所が含まれています。次に例を示します。

    Copy
    -- -- Position to start replication or point-in-time recovery from -- -- CHANGE MASTER TO MASTER_LOG_FILE='mysql-bin-changelog.000001', MASTER_LOG_POS=107;
  2. DB インスタンスに接続し、前の手順からのバイナリログファイルの名前と場所を使用して mysql.rds_set_external_master および mysql.rds_start_replication コマンドを発行することで、レプリケーションマスターとのレプリケーションを開始します。次に例を示します。

    Copy
    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 コマンドからこれらの値を取得しました。データベースへのデータのロードに、--master-data=2 オプションを指定して実行した mysqldump コマンドの出力を使用した場合は、その出力にバイナリログファイルの名前と場所が含まれています。次に例を示します。

    Copy
    -- -- Position to start replication or point-in-time recovery from -- -- CHANGE MASTER TO MASTER_LOG_FILE='mysql-bin-changelog.000001', MASTER_LOG_POS=107;
  2. データベースに接続し、前の手順からのバイナリログファイルの名前と場所を使用して CHANGE MASTER TO および START SLAVE コマンドを発行することで、レプリケーションマスターとのレプリケーションを開始します。たとえば、以下のようになります。

    Copy
    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. レプリカをモニタリングする

Amazon Aurora DB クラスターと MySQL との間のレプリケーションを設定する場合、Amazon Aurora 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

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

  1. レプリカの Aurora DB クラスターに接続し、「mysql.rds_stop_replication」の手順 (mysql.rds_stop_replication 手順は MySQL バージョン 5.5.33 以降、5.6.13 以降、および 5.7.10 以降でのみ使用できます) を呼び出します。

  2. バイナリログの保持期間を 0 に設定します。バイナリログの保持期間を設定するには、「mysql.rds_set_configuration」の手順を使用して、DB クラスターのバイナリログファイルの保持期間に合わせて、'binlog retention hours' の設定パラメーターを指定します。この場合は、次の例にあるように、0 です。

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

RDS MySQL

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

レプリカの RDS DB インスタンスに接続し、「mysql.rds_stop_replication」の手順 (mysql.rds_stop_replication 手順は MySQL バージョン 5.5.33 以降、5.6.13 以降、および 5.7.10 以降でのみ使用できます) を呼び出します。

MySQL (外部)

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

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

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

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

データベースエンジン Instructions

Aurora

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

binlog_format パラメータを OFF に設定します。binlog_format パラメータはクラスターレベルのパラメータであり、デフォルトでは default.aurora5.6 クラスターパラメータグループにあります。

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

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

RDS MySQL

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

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

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

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

MySQL (外部)

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

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

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

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

    Copy
    sudo vi /etc/my.cnf

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

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

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

    Copy
    sudo service mysqld start

関連トピック