カスタム インポートを使用して大規模な外部データベースからのレプリケーションを設定する

このページでは、カスタム インポートを使用して外部サーバー レプリケーションを設定するプロセスについて説明します。以下では、大規模な外部データベースからのレプリケーションが必要な場合に最適なオプションについて説明します。

このページで説明する手順はすべて完了する必要があります。完成したレプリカは、他の Cloud SQL インスタンスと同じ方法で管理し、監視できます。

このプロセスは、グローバル トランザクション識別子（GTID）ベースのレプリケーションを使用するように構成された外部サーバーでのみサポートされます。レプリケーションを開始する前に、外部サーバーから Cloud SQL レプリカにデータを読み込む必要があります。GTID ベースのレプリケーションを使用しない場合、Cloud SQL はレプリケーションを開始する正確なバイナリログの位置を特定できません。GITD ベースのレプリケーションを使用できない場合は、ダンププロセス中にグローバル読み取り専用ロックを設定するようにダンプツールを構成する必要があります。

始める前に

始める前に、外部サーバーの構成、ソース表現インスタンスの作成、Cloud SQL レプリカの設定を完了している必要があります。

レプリケーション ユーザーの権限の更新

外部サーバー上のレプリケーション ユーザーは、任意のホスト（%）からの接続を受け入れるように構成されています。Cloud SQL レプリカでのみ使用されるように、このユーザー アカウントを更新する必要があります。ソース データベース サーバーでターミナルを開き、次のコマンドを入力します。

mysql クライアント

    UPDATE mysql.user
    SET Host='NEW_HOST' WHERE Host='OLD_HOST' AND User='USERNAME';
    GRANT REPLICATION SLAVE, EXECUTE ON *.*
    TO 'GCP_USERNAME'@'HOST';
    FLUSH PRIVILEGES;

例

UPDATE mysql.user
SET Host='192.0.2.0' WHERE Host='%' AND User='replicationUser';
GRANT REPLICATION SLAVE, EXECUTE ON *.*
TO 'gcp_user'@'gmail.com';
FLUSH PRIVILEGES;
プロパティ 説明
NEW_HOST Cloud SQL レプリカの送信 IP を指定します。
OLD_HOST 変更する Host に割り当てる現在の値。
USERNAME 外部サーバー上のレプリケーション ユーザー アカウント。
GCP_USERNAME GCP ユーザー アカウントのユーザー名。
HOST GCP ユーザー アカウントのホスト名。

Cloud SQL レプリカをプライマリ インスタンスとして設定する

Cloud SQL レプリカ インスタンスは読み取り専用です。カスタム インポートを実行するには、スタンドアロン インスタンスに Cloud SQL レプリカを昇格する必要があります。初期データのインポートが完了したら、インスタンスをレプリカに降格します。

カスタムダンプとインポートを実行する

このセクションでは、ダンプファイルを作成し、mydumper または mysqldump クライアント ユーティリティを使用して、最終的な Cloud SQL レプリカにインポートする方法について説明します。

ソース インスタンスに MySQL 汎用データベース（mysql や sys など）が存在する場合、データをダンプする前に、これらのデータベースを除外する必要があります。そうしないと、データのインポートに失敗します。データベースを除外（または追加）する方法に関する記事をご覧ください。

mydumper と myloader を使用する

ダンプファイルを作成して Cloud SQL にインポートするには:

  1. mydumper を使用して、外部サーバー データベースのダンプファイルを作成します。

       $ mydumper -u USERNAME -p PASSWORD \
              --threads=16 -o ./backup \
              -h HOST \
              --no-locks \
              --regex '^(?!(mysql\.|sys\.))'
    プロパティ 説明
    USERNAME データベース読み取り権限を持つ外部サーバー上のレプリケーション ユーザー アカウントまたはユーザー アカウントの名前。
    PASSWORD レプリケーション ユーザーのパスワード。
    HOST 外部サーバーの IPv4 または DNS アドレス。

  2. myloader を使用して、Cloud SQL インスタンスにデータをインポートします。

     $ myloader -u REPLICA_USERNAME -p REPLICA_PASSWORD \
            --threads=16 \
            -d ./backup -h HOST -o
    プロパティ 説明
    REPLICA_USERNAME Cloud SQL インスタンスのユーザー アカウント。
    REPLICA_PASSWORD Cloud SQL インスタンス ユーザーのパスワード。
    HOST Cloud SQL インスタンスの IPv4。

  3. データダンプの GTID またはバイナリログ情報をメモします。この情報は、ストアド プロシージャを使用してレプリケーションを構成する際に必要になります。

    データダンプの GTID またはバイナリログ情報を取得するには、次のコマンドを実行します。

      sudo cat ./backup/metadata

mysqldump を使用する

  1. mysqldump を使用してダンプを作成します。

    mysqldump 

    mysqldump \
    --host=EXTERNAL_HOST \
    --port=EXTERNAL_PORT \
    --user=USERNAME\
    --password=PASSWORD \
    --databases=DATABASE_LIST  \
    --hex-blob \
    --master-data=EXTERNAL_DATA  \
    --no-autocommit \
    --default-character-set=utf8mb4 \
    --single-transaction \
    GTID_PURGED \
    ADD_DROP_TABLE \
    ROUTINES \
    COMPRESS \
    GZIP
    プロパティ 説明
    EXTERNAL_HOST 外部サーバーの IPv4 または DNS アドレス。
    EXTERNAL_PORT 外部サーバーのポート。外部サーバーが Cloud SQL でホストされている場合は 3306 になります。
    USERNAME データベース読み取り権限を持つ外部サーバー上のレプリケーション ユーザー アカウントまたはユーザー アカウントの名前。
    USER_PASSWORD レプリケーション ユーザーのパスワード。
    DATABASE_LIST システム データベース（sys、mysql、performance_schema、information_schema）を除く、外部サーバー上のすべてのデータベースのリスト（スペース区切りのリスト）。データベースを一覧表示するには、SHOW DATABASES MySQL コマンドを使用します。
    EXTERNAL_DATA 外部サーバーで GTID がサポートされておらず、グローバル読み取りロックにアクセスする権限がある場合は、--master-data=1 を使用します。それ以外の場合は、このプロパティを使用しないでください。
    GTID_PURGED 外部サーバーが GTID をサポートしている場合は、--set-gtid-purged=on を使用します。それ以外の場合は、このプロパティを使用しないでください。
    ADD_DROP_TABLE 各 CREATE TABLE ステートメントの前に DROP TABLE ステートメントを追加する場合は、--add-drop-table を含めます。
    ROUTINES ダンプされたデータベースの出力に保存されているルーティン（プロシージャや関数など）を表示するには、--routines を含めます。
    COMPRESS Cloud SQL レプリカと外部サーバーの間で送信されたすべての情報を圧縮する場合は、--compress を使用します。
    GZIP ダンプファイルをさらに圧縮するには、| gzip を使用します。圧縮に適さないデータ（圧縮されないバイナリデータや JPG 画像など）がデータベースに含まれている場合は、これを使用しないでください。

    例

    
mysqldump \
    --host=192.0.2.1 \
    --port=3306 \
    --user=replicationUser \
    --password \
    --databases guestbook journal \
    --hex-blob \
    --master-data=1 \
    --no-autocommit \
    --default-character-set=utf8mb4 \
    --single-transaction \
    --compress \
    | gzip

  2. データダンプの GTID またはバイナリログ情報をメモします。この情報は、Cloud SQL ストアド プロシージャを使用してレプリケーションを構成する際に必要になります。

    GTID の情報は、次のような行に含まれています。

       SET @@GLOBAL.GTID_PURGED='32eb1e6a-17b6-11ea-a39e-06d94ac3ec98:1-33496';

    バイナリログの情報は、次のような行に含まれています。

       CHANGE MASTER TO MASTER_LOG_FILE='mysql-bin-changelog.033877', MASTER_LOG_POS=360;

  3. スーパー権限を必要とするダンプファイルで次の行を削除します。Cloud SQL ユーザーにはスーパー権限がないため、このような行が存在すると、インポートが失敗します。

    GTID ベースのレプリケーションの場合: ダンプ内のセッション変数設定ステートメントと一緒に SET GTID_PURGED ステートメントを削除します。次に例を示します。

       ...
   SET @MYSQLDUMP_TEMP_LOG_BIN = @@SESSION.SQL_LOG_BIN;
   SET @@SESSION.SQL_LOG_BIN= 0;
   ...
   SET @@GLOBAL.GTID_PURGED='32eb1e6a-17b6-11ea-a39e-06d94ac3ec98:1-33496';
   ...
   SET @@SESSION.SQL_LOG_BIN=@MYSQLDUMP_TEMP_LOG_BIN;

    バイナリログ ベースのレプリケーションの場合は、CHANGE MASTER ステートメントを削除します。次に例を示します。

       ...
   CHANGE MASTER TO MASTER_LOG_FILE='mysql-bin-changelog.033877', MASTER_LOG_POS=360;
    ...

  4. mysql CLI を使用して、Cloud SQL レプリカにデータをインポートします。

    mysql 

    mysql -h REPLICA_HOST -u REPLICA_USER \
-p REPLICA_DATABASE_NAME RESULT_FILE
    プロパティ 説明
    REPLICA_HOST MySQL サーバーが配置されているホスト。
    REPLICA_USER サーバーとの接続時に使用する MySQL ユーザー名。
    REPLICA_DATABASE_NAME データが配置されているデータベースの名前。
    RESULT_FILE インポートするダンプファイルの名前。

    例

      mysql -h 255.255.255.255 -u replica_username -p replica_db < result.sql

Google Cloud バケットを使用してダンプファイルをインポートすることもできます。SQL ダンプファイルから Cloud SQL にデータをインポートするをご覧ください。

Cloud SQL インスタンスを降格する

Cloud SQL インスタンスを Cloud SQL レプリカに降格するには、インスタンスで demoteMaster メソッドを使用します。

  1. 降格するインスタンスの名前を含むリクエスト JSON ファイルを準備します。

    ソース JSON

     {
    "demoteMasterContext": {
      "masterInstanceName": SOURCE_REPRESENTATION_INSTANCE_NAME,
      "skipReplicationSetup": true
      }
 }
    プロパティ 説明
    SOURCE_REPRESENTATION_INSTANCE_NAME ソース表現インスタンスの名前。

    例

       {
     "demoteMasterContext": {
       "masterInstanceName": "cloudsql-source-instance",
       "skipReplicationSetup": true
     }
   }

  2. ターミナルを開いて、次のコマンドで demoteMaster を呼び出します。

    curl

      gcloud auth login
  ACCESS_TOKEN="$(gcloud auth print-access-token)"
  curl --header "Authorization: Bearer ${ACCESS_TOKEN}" \
    --header 'Content-Type: application/json' \
    --data @JSON_PATH \
    -X POST \
  https://sqladmin.googleapis.com/sql/v1beta4/projects/PROJECT-ID/instances/INSTANCE-NAME/demoteMaster
    プロパティ 説明
    JSON_PATH JSON ファイルのパス。
    PROJECT_ID Google Cloud のプロジェクトの ID。
    INSTANCE-NAME 降格するインスタンスの名前。

    例

       gcloud auth login
   ACCESS_TOKEN="$(gcloud auth print-access-token)"
   curl --header "Authorization: Bearer ${ACCESS_TOKEN}" \
     --header 'Content-Type: application/json' \
     --data @./source.json \
     -X POST \
   https://sqladmin.googleapis.com/sql/v1beta4/projects/MyProject/instances/cloudsql-replica-instance/demoteMaster

完了時に表示される内容

インスタンスが正しく設定されていることを確認するには、Cloud SQL インスタンス ページに移動します。

ソース表現インスタンスと Cloud SQL レプリカが表示されます。次のように表示されます。

インスタンス ID タイプ パブリック IP
(-) source-representation-instance MySQL 外部プライマリ 10.68.48.3:3306
replica-instance MySQL リードレプリカ 34.66.48.59

Cloud SQL インスタンスでレプリケーションを開始する

この手順では、Cloud SQL ストアド プロシージャを使用します。Cloud SQL ストアド プロシージャは、demoteMaster リクエストの呼び出し後にインストールされます。promoteReplica の呼び出し後に削除されます。詳細については、レプリケーション管理のストアド プロシージャをご覧ください。

  1. レプリカ インスタンスにログインします。詳細については、ローカルマシンからデータベース クライアントを使用して接続するをご覧ください。

  2. mysql.resetMaster ストアド プロシージャを使用して、レプリケーションの設定をリセットします。

     mysql> call mysql.resetMaster();

  3. レプリケーションを構成します。この手順では、先ほどメモした GTID またはバイナリログ情報が必要です。

    GTID

    1. mysql.skipTransactionWithGtid(GTID_TO_SKIP) ストアド プロシージャで gtid_purged フィールドを構成します。
    プロパティ 説明
    GTID_TO_SKIP 構成する GTID の設定値。

    次に例を示します。

        mysql> call mysql.skipTransactionWithGtid('32eb1e6a-17b6-11ea-a39e-06d94ac3ec98:1-33496');

    1. mysql.setupExternalSourceAutoPosition(HOST, PORT, USER_NAME, USER_PASSWORD, MASTER_AUTO_POSITION, USE_SSL, USE_SSL_CLIENT_AUTH) ストアド プロシージャを実行します。
    プロパティ 説明
    HOST ソース エンドポイント。
    PORT ソースポート。
    USER_NAME ソースユーザー。
    USER_PASSWORD ソースユーザーのパスワード。
    MASTER_AUTO_POSITION master_auto_position パラメータの値。可能な値は、0、1 です。
    USE_SSL SSL ベースのレプリケーションを使用するかどうか。可能な値は、true、false です。true の場合は、DemoteMaster リクエストに caCertificate フィールドを設定する必要があります。
    USE_SSL_CLIENT_AUTH SSL クライアント認証を使用するかどうか。可能な値は、true、false です。true の場合は、demoteMaster リクエストで clientKey と clientCertificates フィールドを設定する必要があります。 
        mysql> call mysql.setupExternalSourceAutoPosition('1.1.1.1', 3306, \
    'USERNAME', 'PASSWORD', \
    /* master_auto_position= */ 1,false, false); \

    バイナリログ

    mysql.setupExternalSource(HOST, PORT, USER_NAME, USER_PASSWORD, SOURCE_LOG_NAME, SOURCE_LOG_POS, USE_SSL, USE_SSL_CLIENT_AUTH) ストアド プロシージャを実行します。

    プロパティ 説明
    HOST ソース エンドポイント。
    PORT ソースポート。
    USER_NAME ソースユーザー。
    USER_PASSWORD ソースユーザーのパスワード。
    SOURCE_LOG_NAME レプリケーション情報を含むソース データベース インスタンスのバイナリログの名前。
    SOURCE_LOG_POS レプリケーション情報の読み取りを開始する mysql_binary_log_file_name バイナリログ内の場所。
    USE_SSL SSL ベースのレプリケーションを使用するかどうか。可能な値は、true、false です。true の場合は、DemoteMaster リクエストに caCertificate フィールドを設定する必要があります。
    USE_SSL_CLIENT_AUTH SSL クライアント認証を使用するかどうか。可能な値は、true、false です。true の場合は、demoteMaster リクエストで clientKey と clientCertificates フィールドを設定する必要があります。 
        mysql> call mysql.setupExternalSource('1.1.1.1', 3306, \
    'user_name', 'password', 'mysql-bin-changelog.033877', 360, \
    false, false);

  4. mysql.startReplication() ストアド プロシージャを使用して、外部データベースからのレプリケーションを開始します。

       mysql> call mysql.startReplication();

  5. レプリケーションのステータスを確認します。Slave_IO_Running と Slave_SQL_Running の両方のフィールドが YES になっていることを確認します。

       mysql> show slave status\G

    このコマンドの出力は、次のようになります。

       *************************** 1. row ***************************
                   Slave_IO_State: Waiting for master to send event
                      Master_Host: 1.1.1.1
                      Master_User: user_name
                      Master_Port: 3306
                    Connect_Retry: 60
                  Master_Log_File: mysql-bin-changelog.000001
              Read_Master_Log_Pos: 1
                   Relay_Log_File: relay-log.000002
                    Relay_Log_Pos: 1
            Relay_Master_Log_File: mysql-bin-changelog.000001
                 Slave_IO_Running: Yes
                Slave_SQL_Running: Yes
                  Replicate_Do_DB:
              Replicate_Ignore_DB:
               Replicate_Do_Table:
           Replicate_Ignore_Table:
          Replicate_Wild_Do_Table:
      Replicate_Wild_Ignore_Table: mysql.%
                       Last_Errno: 0
                       Last_Error:
                     Skip_Counter: 0
              Exec_Master_Log_Pos: 412
                  Relay_Log_Space: 752
                  Until_Condition: None
                   Until_Log_File:
                    Until_Log_Pos: 0
               Master_SSL_Allowed: No
               Master_SSL_CA_File:
               Master_SSL_CA_Path:
                  Master_SSL_Cert:
                Master_SSL_Cipher:
                   Master_SSL_Key:
            Seconds_Behind_Master: 0
    Master_SSL_Verify_Server_Cert: No
                    Last_IO_Errno: 0
                    Last_IO_Error:
                   Last_SQL_Errno: 0
                   Last_SQL_Error:
      Replicate_Ignore_Server_Ids:
                 Master_Server_Id: 1509941531
                      Master_UUID: 1cb2c80e-90f0-11eb-9ea3-02389b1c2e6f
             Master_Info_File: mysql.slave_master_info
                    SQL_Delay: 0
          SQL_Remaining_Delay: NULL
      Slave_SQL_Running_State: Slave has read all r
           Master_Retry_Count: 86400
                  Master_Bind:
      Last_IO_Error_Timestamp:
     Last_SQL_Error_Timestamp:
               Master_SSL_Crl:
           Master_SSL_Crlpath:
           Retrieved_Gtid_Set:
            Executed_Gtid_Set: 478af53c-bd24-11eb-be72-42010a80002a:1-226
                Auto_Position: 0
   1 row in set (0.00 sec)

レプリケーションを続行する

外部サーバーからのレプリケーションを開始したら、レプリケーションをモニタリングし、移行を完了する必要があります。詳細については、レプリケーションのモニタリングをご覧ください。

トラブルシューティング

問題 トラブルシューティング
Lost connection to MySQL server during query when dumping table. ソースが使用不能か、ダンプに含まれているパケットが大きすぎる可能性があります。

外部プライマリが接続できることを確認します。また、ソース インスタンスの net_read_timeout フラグと net_write_timeout フラグの値を変更して、エラーを防ぐこともできます。これらのフラグに使用可能な値の詳細については、データベース フラグを構成するをご覧ください。

マネージド インポート移行の mysqldump フラグの使用方法については、使用可能な初期同期フラグとデフォルトの初期同期フラグをご覧ください。
最初のデータの移行は成功したが、データが複製されていない。 根本原因の一つとして、ソース データベースでレプリケーション フラグが定義されているため、データベースの一部またはすべての変更が複製されていない可能性があります。

binlog-do-db、binlog-ignore-db、replicate-do-db、replicate-ignore-db などのレプリケーション フラグが競合する方法で設定されていないことを確認します。

プライマリ インスタンスで show master status コマンドを実行して、現在の設定を確認します。
最初のデータ移行は成功したが、しばらくするとデータ レプリケーションが機能しなくなる。 次の方法をお試しください。

  • Google Cloud Console の [Cloud Monitoring] セクションで、レプリカ インスタンスのレプリケーション指標を確認します。
  • MySQL IO スレッドまたは SQL スレッドのエラーは、mysql.err log ファイルの Cloud Logging で確認できます。
  • このエラーは、レプリカ インスタンスに接続するときにも発生する場合があります。SHOW SLAVE STATUS コマンドを実行して、出力で次のフィールドを確認します。
    • Slave_IO_Running
    • Slave_SQL_Running
    • Last_IO_Error
    • Last_SQL_Error
mysqld check failed: data disk is full. レプリカ インスタンスのデータディスクに空き容量がありません。

レプリカ インスタンスのディスクサイズを増やします。ディスクサイズを手動で増やすか、自動ストレージ増加を有効にします。

レプリケーション ログの確認

レプリケーションの設定を確認したときに、ログが生成されています。

これらのログは次の手順で確認できます。

  1. Google Cloud コンソールでログビューアに移動します。

    ログビューアに移動

  2. [インスタンス] プルダウンから Cloud SQL レプリカを選択します。
  3. replication-setup.log ログファイルを選択します。

Cloud SQL レプリカが外部サーバーに接続できない場合は、次の点を確認してください。

  • 外部サーバー上のすべてのファイアウォールが、Cloud SQL レプリカの送信 IP アドレスからの接続を受け入れるように構成されている。
  • SSL / TLS 構成が正しく行われている。
  • 正しいレプリケーション ユーザー、ホスト、パスワードを使用している。

次のステップ