リードレプリカを作成する

このページでは、Cloud SQL インスタンスのリードレプリカを作成する方法について説明します。

リードレプリカとは、プライマリ インスタンスのコピーのことで、プライマリへの変更が通常の状況下で、ほぼリアルタイムで反映されます。リードレプリカは、プライマリ インスタンスからの読み取りリクエストやアナリティクス トラフィックをオフロードするために使用します。

また、障害復旧では、リージョンを移行することもできます。レプリカがクロスリージョン レプリカの場合は、別のリージョンにフェイルオーバーできます。たとえば、レプリカをスタンドアロン インスタンスに昇格できます(この場合、このインスタンスは既存のレプリカのプライマリとは見なされません)。

レプリケーションの仕組みについて詳しくは、Cloud SQL のレプリケーションをご覧ください。

始める前に

このインスタンスのレプリカを初めて作成する場合は、インスタンスがプライマリ インスタンスの要件を満たしていることを確認してください。詳細

リードレプリカを作成する

リードレプリカを作成する手順は次のとおりです。

コンソール

  1. Google Cloud コンソールで Cloud SQL の [インスタンス] ページに移動します。

    Cloud SQL の [インスタンス] に移動

  2. レプリカを作成するインスタンスを探して、リストの右端にある [more actions] メニューを開きます。
  3. [リードレプリカを作成] を選択します。

    この選択肢が表示されていない場合、そのインスタンスはレプリカです。レプリカのレプリカは作成できません。

  4. インスタンスでバックアップとバイナリ ロギングが有効になっている場合は、次の手順に進みます。そうでない場合は、[バックアップを自動化する] と [バイナリ ロギングを有効にする] を選択してから [続行] をクリックします。さらに、[保存して再起動] をクリックして、インスタンスを再起動します。

    バイナリログを有効にすると、インスタンスが再起動されます。

  5. ページの [インスタンスのカスタマイズ] セクションで、レプリカの設定を更新します。最初に [構成オプションを表示] をクリックして、設定のグループを表示します。次に、目的のグループを展開して設定を確認し、カスタマイズします。選択したすべてのオプションの [サマリー] が右側に表示されます。これらの設定のカスタマイズはオプションです。カスタマイズを行わない場合、デフォルト値が割り当てられます。

    各設定の詳細については、インスタンスの設定ページをご覧ください。

    たとえば、BigQuery などの他の Google Cloud サービスが、Cloud SQL 内のデータにアクセスし、プライベート接続でこのデータをクエリできるようにするには、[接続] グループを展開します。次に、[パブリック IP] チェックボックスをオフにします。

  6. [レプリカを作成する] をクリックします。

    Cloud SQL により、必要に応じてバックアップが作成され、レプリカが作成されます。プライマリのインスタンス ページに戻ります。

gcloud

  1. プライマリ インスタンスのステータスを確認します。
    gcloud sql instances describe PRIMARY_INSTANCE_NAME
          

    databaseReplicationEnabled プロパティが true の場合、そのインスタンスはレプリカであることを示します。レプリカのレプリカを作成することはできません。

  2. backupConfigurationenabled プロパティが false の場合、このステップでプライマリ インスタンスのバックアップを有効にします。
    gcloud sql instances patch PRIMARY_INSTANCE_NAME \
    --backup-start-time=>HH:MM
          
    backup-start-time パラメータは、UTC±00 タイムゾーンの 24 時間で指定され、4 時間のバックアップ期間の開始を指定します。バックアップはバックアップ時間枠の任意の時刻に開始できます。
  3. binaryLogEnabled プロパティが false の場合、プライマリ インスタンスでバイナリログを有効にします。
    gcloud sql instances patch PRIMARY_INSTANCE_NAME \
    --enable-bin-log
    
    バイナリ ロギングを有効にすると、インスタンスが再起動されます。
  4. レプリカを作成します。
    gcloud sql instances create REPLICA_NAME \
    --master-instance-name=PRIMARY_INSTANCE_NAME
    

    必要な場合は、--tier パラメータを使用して異なる階層サイズを指定できます。

    --region パラメータを使用して別のリージョンを指定できます。

    他のインスタンス設定のパラメータを追加することもできます。詳細については、gcloud sql インスタンスの作成をご覧ください。

    プライマリ インスタンスにプライベート IP アドレスしかなく、BigQuery などの他の Google Cloud サービスが Cloud SQL のデータにアクセスし、プライベート接続でこのデータに対してクエリを実行できるようにする場合、その後に --enable-google-private-path パラメータをコマンドに追加します。

    レプリカは、プライマリ インスタンスと同じ VPC ネットワーク内に作成する必要があります。同じ VPC ネットワークで allocated-ip-range-name を指定することもできます。範囲が指定されていない場合、レプリカはランダムな範囲で作成されます。

  • バイナリ ロギングはリードレプリカ インスタンスでサポートされています(MySQL 5.7 および 8.0 のみ。レガシー HA フェイルオーバー レプリカではサポートされていません)。プライマリのインスタンス名ではなくレプリカのインスタンス名を指定して、同じ gcloud コマンドを実行し、バイナリのロギングを有効にします。
    gcloud sql instances patch REPLICA_INSTANCE_NAME \
    --enable-bin-log
        

    sync_binlog フラグを使用して、レプリカ(プライマリではなく)のインスタンスのバイナリ ロギングの耐久性を設定できます。これにより、MySQL サーバーがバイナリログをディスクに同期する頻度を制御できます。

    レプリカ インスタンスではバックアップを有効にできませんが、プライマリと異なり、バックアップが無効になっている場合でもバイナリ ロギングを有効にできます。

    レプリカ インスタンスのバイナリログの保持期間は、プライマリ インスタンスでの 7 日間とは異なり、自動的に 1 日に設定されます。

Terraform

リードレプリカを作成するには、Terraform リソースを使用します。

resource "google_sql_database_instance" "read_replica" {
  name                 = "mysql-replica-instance-name"
  master_instance_name = google_sql_database_instance.primary.name
  region               = "europe-west4"
  database_version     = "MYSQL_8_0"

  replica_configuration {
    failover_target = false
  }

  settings {
    tier              = "db-n1-standard-2"
    availability_type = "ZONAL"
    disk_size         = "100"
  }
  # set `deletion_protection` to true, will ensure that one cannot accidentally delete this instance by
  # use of Terraform whereas `deletion_protection_enabled` flag protects this instance at the GCP level.
  deletion_protection = false
}

変更を適用する

Google Cloud プロジェクトで Terraform 構成を適用するには、次のセクションの手順を完了します。

Cloud Shell を準備する

  1. Cloud Shell を起動します。
  2. Terraform 構成を適用するデフォルトの Google Cloud プロジェクトを設定します。

    このコマンドは、プロジェクトごとに 1 回だけ実行する必要があります。これは任意のディレクトリで実行できます。

    export GOOGLE_CLOUD_PROJECT=PROJECT_ID

    Terraform 構成ファイルに明示的な値を設定すると、環境変数がオーバーライドされます。

ディレクトリを準備する

各 Terraform 構成ファイルには独自のディレクトリ(ルート モジュールとも呼ばれます)が必要です。

  1. Cloud Shell で、ディレクトリを作成し、そのディレクトリ内に新しいファイルを作成します。ファイルの拡張子は .tf にする必要があります(例: main.tf)。このチュートリアルでは、このファイルを main.tf とします。
    mkdir DIRECTORY && cd DIRECTORY && touch main.tf
  2. チュートリアルを使用している場合は、各セクションまたはステップのサンプルコードをコピーできます。

    新しく作成した main.tf にサンプルコードをコピーします。

    必要に応じて、GitHub からコードをコピーします。Terraform スニペットがエンドツーエンドのソリューションの一部である場合は、この方法をおすすめします。

  3. 環境に適用するサンプル パラメータを確認し、変更します。
  4. 変更を保存します。
  5. Terraform を初期化します。 これは、ディレクトリごとに 1 回だけ行う必要があります。
    terraform init

    必要に応じて、最新バージョンの Google プロバイダを使用する場合は、-upgrade オプションを使用します。

    terraform init -upgrade

変更を適用する

  1. 構成を確認して、Terraform が作成または更新するリソースが想定どおりであることを確認します。
    terraform plan

    必要に応じて構成を修正します。

  2. 次のコマンドを実行します。プロンプトで「yes」と入力して、Terraform 構成を適用します。
    terraform apply

    Terraform に「Apply complete!」のメッセージが表示されるまで待ちます。

  3. Google Cloud プロジェクトを開いて結果を表示します。Google Cloud コンソールの UI でリソースに移動して、Terraform によって作成または更新されたことを確認します。

変更を削除する

変更を削除するには、次の手順を行います。

  1. 削除の保護を無効にするには、Terraform 構成ファイルで deletion_protection 引数を false に設定します。
    deletion_protection =  "false"
  2. 次のコマンドを実行します。プロンプトで「yes」と入力して、更新された Terraform 構成を適用します。
    terraform apply
  1. 次のコマンドを実行しています。プロンプトで「yes」と入力して、以前に Terraform 構成で適用されたリソースを削除します。

    terraform destroy

REST v1

  1. 現在のバックアップ構成を取得する

    インスタンス リソースの get メソッドを使用して、プライマリのデータベース バージョンと現在のバックアップ構成を取得します。

    リクエストのデータを使用する前に、次のように置き換えます。

    • project-id: プロジェクト ID
    • primary-instance-name: プライマリ インスタンスの名前

    HTTP メソッドと URL:

    GET https://sqladmin.googleapis.com/v1/projects/project-id/instances/primary-instance-name

    リクエストを送信するには、次のいずれかのオプションを展開します。

    次のような JSON レスポンスが返されます。

  2. レプリケーション フィールドが設定されていることを確認する

    enabled または pointInTimeEnabled のいずれかが false の場合、インスタンス リソースの patch メソッドを使用して、両方を有効にします。リクエストで、変更するバックアップ構成のプロパティを指定します。

    バックアップを有効にするには、enabledtrue に設定し、startTimeHH:MM 形式の時間帯に設定します。startTime パラメータは、UTC±00 タイムゾーンの 24 時間で指定され、4 時間のバックアップ期間の開始を指定します。バックアップはバックアップ時間枠の任意の時刻に開始できます。

    ポイントインタイム リカバリを有効にするには、pointInTimeEnabledtrue に設定します。

    リクエストのデータを使用する前に、次のように置き換えます。

    • project-id: プロジェクト ID
    • instance-id: インスタンス ID(プライマリまたはレプリカ)
    • start-time「HH:MM」形式の時刻

    HTTP メソッドと URL:

    PATCH https://sqladmin.googleapis.com/v1/projects/project-id/instances/instance-id

    JSON 本文のリクエスト:

    {
      "settings":
      {
        "backupConfiguration":
        {
          "startTime": "start-time",
          "enabled": true,
          "binaryLogEnabled": true
        }
      }
    }
    

    リクエストを送信するには、次のいずれかのオプションを展開します。

    次のような JSON レスポンスが返されます。

  3. リードレプリカを作成する

    インスタンス リソースの insert メソッドを使用してリードレプリカを作成します。databaseVersion プロパティはプライマリと同じにする必要があります。プライマリ インスタンスでプライベート IP アドレスが使用されている場合、プライマリ インスタンスを作成する場合と同じ方法で allocatedIpRange を指定できます。範囲が指定されていない場合、レプリカはランダムな範囲で作成されます。クロスリージョン リードレプリカの場合は、プライマリ インスタンスと異なるリージョンを指定します。

    リクエストのデータを使用する前に、次のように置き換えます。

    • project-id: プロジェクト ID
    • database-version: Emum バージョンの文字列(MYSQL_8_0 など)
    • primary-instance-name: プライマリ インスタンスの名前
    • primary-instance-region: プライマリ インスタンスのリージョン
    • replica-region: レプリカ インスタンスのリージョン
    • replica-name: レプリカ インスタンスの名前
    • machine-type: マシンタイプの列挙型文字列。例: 「db-custom-1-3840」
    • private-network: プライベート接続を作成するために追加または選択している承認済みネットワーク。

    HTTP メソッドと URL:

    POST https://sqladmin.googleapis.com/v1/projects/project-id/instances

    JSON 本文のリクエスト:

    {
      "masterInstanceName": "primary-instance-name",
      "project": "project-id",
      "databaseVersion": "database-version",
      "name": "replica-name",
      "region": "replica-region",
      "settings":
      {
        "tier": "machine-type",
        "settingsVersion": 0,
        "ipConfiguration": {
        object (IpConfiguration)
      },
      {
      "ipv4Enabled": false,
      "privateNetwork": private-network,
      "requireSsl": boolean,
      "authorizedNetworks": [
        {
          object (AclEntry)
        }
      ],
      "allocatedIpRange": string
        }
      }
    }
    

    リクエストを送信するには、次のいずれかのオプションを展開します。

    次のような JSON レスポンスが返されます。

REST v1beta4

  1. 現在のバックアップ構成を取得する

    インスタンス リソースの get メソッドを使用して、マスターのデータベース バージョンと現在のバックアップ構成を取得します。

    リクエストのデータを使用する前に、次のように置き換えます。

    • project-id: プロジェクト ID
    • primary-instance-name: プライマリ インスタンスの名前

    HTTP メソッドと URL:

    GET https://sqladmin.googleapis.com/sql/v1beta4/projects/project-id/instances/primary-instance-name

    リクエストを送信するには、次のいずれかのオプションを展開します。

    次のような JSON レスポンスが返されます。

  2. レプリケーション フィールドが設定されていることを確認する

    プライマリ インスタンスで enabled または binaryLogEnabled のいずれかが false の場合、インスタンス リソースの patch メソッドを使用して両方を有効にします。リクエストで、変更するバックアップ構成のプロパティを指定します。

    バックアップを有効にするには、enabledtrue に設定し、startTimeHH:MM 形式の時間に設定します。startTime パラメータは、UTC±00 タイムゾーンの 24 時間で指定され、4 時間のバックアップ期間の開始を指定します。バックアップはバックアップ時間枠の任意の時刻に開始できます。

    ポイントインタイム リカバリを有効にするには、プライマリ インスタンスで binaryLogEnabledtrue に設定します。

    バイナリ ロギングはリードレプリカ インスタンスでサポートされています(MySQL 5.7 および 8.0 のみ)。プライマリのインスタンス ID ではなくレプリカのインスタンス ID を指定して同じ API を実行し、レプリカでバイナリ ロギングを有効にします。

    sync_binlog フラグを使用して、レプリカ(プライマリではなく)のインスタンスのバイナリ ロギングの耐久性を設定できます。これにより、MySQL サーバーがバイナリログをディスクに同期する頻度を制御できます。

    レプリカ インスタンスではバックアップを有効にできませんが、プライマリと異なり、バックアップが無効になっている場合でもバイナリ ロギングを有効にできます。

    リクエストのデータを使用する前に、次のように置き換えます。

    • project-id: プロジェクト ID
    • instance-id: インスタンス ID(プライマリまたはレプリカ)
    • start-time「HH:MM」形式の時刻

    HTTP メソッドと URL:

    PATCH https://sqladmin.googleapis.com/v1beta4/projects/project-id/instances/instance-id

    JSON 本文のリクエスト:

    {
      "settings":
      {
        "backupConfiguration":
        {
          "startTime": "start-time",
          "enabled": true,
          "binaryLogEnabled": true
        }
      }
    }
    

    リクエストを送信するには、次のいずれかのオプションを展開します。

    次のような JSON レスポンスが返されます。

  3. リードレプリカを作成する

    インスタンス リソースの insert メソッドを使用してリードレプリカを作成します。databaseVersion プロパティはプライマリと同じにする必要があります。プライマリ インスタンスでプライベート IP アドレスが使用されている場合、プライマリ インスタンスを作成する場合と同じ方法で allocatedIpRange を指定できます。クロスリージョン リードレプリカの場合は、プライマリ インスタンスと異なるリージョンを指定します。

    リクエストのデータを使用する前に、次のように置き換えます。

    • project-id: プロジェクト ID
    • database-version: Emum バージョンの文字列(MYSQL_8_0 など)
    • primary-instance-name: プライマリ インスタンスの名前
    • primary-instance-region: プライマリ インスタンスのリージョン
    • replica-region: レプリカ インスタンスのリージョン
    • replica-name: レプリカ インスタンスの名前
    • machine-type: マシンタイプの列挙型文字列。例: 「db-custom-1-3840」
    • private-network: プライベート接続を作成するために追加または選択している承認済みネットワーク。

    HTTP メソッドと URL:

    POST https://sqladmin.googleapis.com/sql/v1beta4/projects/project-id/instances

    JSON 本文のリクエスト:

    {
      "masterInstanceName": "primary-instance-name",
      "project": "project-id",
      "databaseVersion": "database-version",
      "name": "replica-name",
      "region": "replica-region",
      "settings":
      {
        "tier": "machine-type",
        "settingsVersion": 0,
    
        "ipConfiguration": {
        object (IpConfiguration)
      },
      {
      "ipv4Enabled": false,
      "privateNetwork": private-network,
      "requireSsl": boolean,
      "authorizedNetworks": [
        {
          object (AclEntry)
        }
      ],
      "allocatedIpRange": string
        }
    
      }
    }
    

    リクエストを送信するには、次のいずれかのオプションを展開します。

    次のような JSON レスポンスが返されます。

IAM データベース認証のリードレプリカを構成する

プライマリ インスタンスでレプリカを有効にしても、リードレプリカは cloudsql_iam_authentication フラグを自動的に有効にしません。

IAM データベース認証のリードレプリカを構成するには:

  1. Google Cloud Console で Cloud SQL の [インスタンス] ページに移動します。

    Cloud SQL の [インスタンス] に移動

  2. インスタンスの [概要] ページを開くには、インスタンス名をクリックします。
  3. [構成] タイルで、cloudsql_iam_authentication フラグを探します。フラグがリストにない場合は、リードレプリカでフラグを有効にする必要はありません。フラグがリストにある場合は、リードレプリカでフラグを有効にする必要があります。リードレプリカでフラグを有効にする必要がある場合は、次の手順に進みます。
  4. SQL ナビゲーション メニューから [レプリカ] を選択します。
  5. 編集するレプリカの名前をクリックします。
  6. [編集] をクリックします。
  7. [構成オプション] セクションで、[フラグ] を開きます。
  8. [+ 追加] を選択します。
  9. フラグ名として「cloudsql_iam_authentication」と入力します。このフラグに対して [オン] が選択されていることを確認します。
  10. [保存] をクリックします。

カスケード レプリカの作成

このセクションでは、カスケード レプリカの作成と管理の方法ついて説明します。カスケード レプリカの仕組みについては、レプリカのカスケードをご覧ください。

始める前に

プライマリ インスタンスにはリードレプリカが必要です。プライマリ インスタンスの作成の詳細については、リードレプリカを作成するをご覧ください。

カスケード レプリカの作成手順

Console

  1. Google Cloud コンソールで Cloud SQL の [インスタンス] ページに移動します。

    Cloud SQL の [インスタンス] に移動

  2. MySQL 5.7 以降の場合は、レプリケーションを有効にします
  3. 作成するレプリカの親として機能するレプリカの [レプリカ] タブをクリックします。
  4. [レプリカを作成する] をクリックします。
  5. [リードレプリカを作成する] ページで、インスタンス ID とその他の構成オプション(名前、リージョン、ゾーンなど)を更新します。
  6. [CREATE] をクリックします。

    Cloud SQL はレプリカを作成します。親レプリカのインスタンス ページに戻ります。

  7. 作成する新しいカスケード レプリカごとに手順 4 ~ 6 を行います。

gcloud

  1. MySQL バージョン 5.7 以降を使用している場合は、新しいレプリカのプライマリの binlog を有効にします。
    gcloud sql instances patch --enable-bin-log
          --project=cascade-replica PARENT_REPLICA_NAME
    
    PARENT_REPLICA_NAME は、親レプリカの名前に置き換えます。
  2. --master-instance-name フラグを使用してプライマリ レプリカをプライマリ インスタンスとして指定し、新しいレプリカを作成します。

    gcloud sql instances create REPLICA_NAME \
          --master-instance-name=PARENT_REPLICA_NAME \
    
    以下を置き換えます。
    • REPLICA_NAME: 作成するレプリカの一意の ID
    • PARENT_REPLICA_NAME: 親レプリカの名前
  3. レプリカが作成されると、プライマリ インスタンスに対して行われた変更がカスケード レプリカ チェーン内のすべてのレプリカで複製されることがわかります。

curl

  1. MySQL バージョン 5.7 以降を使用している場合は、バイナリ ロギングを有効にします。

    バイナリ ロギングを有効にするには、次の JSON を request.JSON という名前のファイルに保存してから、curl コマンドを呼び出します。を使用してバイナリログを有効にします。
    {
      "settings":
      {
        "backupConfiguration":
        {
          "enabled": false,
          "binaryLogEnabled": true
        }
      }
    }
    

  2. 親レプリカの下にレプリカを作成するには、次の JSON コードサンプルを編集し、request.json というファイルに保存します。

    {
      "masterInstanceName": "PARENT_REPLICA_NAME",
      "project": "PROJECT_ID",
      "name": "REPLICA_NAME",
      "region": "REPLICA_REGION",
      "settings":
        {
          "tier": "MACHINE_TYPE",
        }
    }
    
  3. 次のコマンドを実行します。
    curl -X POST
    -H "Authorization: Bearer "$(gcloud auth print-access-token)
    -H "Content-Type: application/json; charset=utf-8"
    -d @request.json
    "https://sqladmin.googleapis.com/v1/projects/PROJECT_ID/instances"
    

トラブルシューティング

問題 トラブルシューティング
作成時にリードレプリカがレプリケーションを開始しなかった。 ログファイルに、より具体的なエラーが記録されている可能性があります。Cloud Logging のログを調べて、実際のエラーを確認します。
リードレプリカを作成できない - invalidFlagValue エラー。 リクエスト内のフラグのいずれかが無効です。これは、明示的に指定されたフラグか、デフォルト値に設定されたフラグである可能性があります。

まず、max_connections フラグの値がプライマリの値以上であることを確認します。

max_connections フラグが適切に設定されている場合、Cloud Logging のログを調べて、実際のエラーを確認します。

リードレプリカを作成できない - 不明なエラー。 ログファイルに、より具体的なエラーが記録されている可能性があります。Cloud Logging のログを調べて、実際のエラーを確認します。

エラーが set Service Networking service account as servicenetworking.serviceAgent role on consumer project の場合は、Service Networking API を無効にしてから再度有効にします。この措置で、プロセスを続行するために必要なサービス アカウントが作成されます。

ディスクに空きがない。 レプリカの作成中にプライマリ インスタンスのディスクの空きがなくなる可能性があります。プライマリ インスタンスを編集して、より大きなディスクサイズにアップグレードします。
レプリカ インスタンスのメモリ使用量が多すぎる。 レプリカは一時メモリを使用して頻繁にリクエストされる読み取りオペレーションをキャッシュに保存するため、プライマリ インスタンスより多くのメモリを使用する可能性があります。

レプリカ インスタンスを再起動して、一時メモリ領域を再利用します。

レプリケーションが停止した。 ストレージの上限に達しており、ストレージの自動増量が有効になっていません。

インスタンスを編集して automatic storage increase を有効にします。

レプリケーション ラグが常に大きい。 書き込みの負荷が大きすぎてレプリカで処理できません。レプリケーション ラグは、レプリカの SQL スレッドで IO スレッドに対応できない場合に発生します。クエリやワークロードによっては、特定のスキーマで一時的または永続的に高いレプリケーション ラグが発生することがあります。レプリケーション ラグの一般的な原因は次のとおりです。
  • レプリカのクエリが遅い。遅いクエリを見つけて修正します。
  • すべてのテーブルに一意キーまたは主キーが必要です。一意のキーまたは主キーのないテーブルを更新するたびに、レプリカでテーブル全体がスキャンされます。
  • DELETE ... WHERE field < 50000000 などのクエリでは、レプリカに膨大な数の更新が蓄積されるため、行ベースのレプリケーションでレプリケーション ラグが発生します。

考えられる解決策は次のとおりです。

レプリケーション ラグが突然急増する。 これは、トランザクションが長時間実行されていることが原因です。ソース インスタンスでトランザクション(単一ステートメントまたは複数ステートメント)が commit されると、トランザクションの開始時間がバイナリログに記録されます。レプリカはこのバイナリログ イベントを受信すると、そのタイムスタンプを現在のタイムスタンプと比較してレプリケーション ラグを計算します。そのため、移行元で長時間実行されるトランザクションが発生すると、レプリカで直ちにレプリケーション ラグが発生します。トランザクション内の行変更の量が多いと、レプリカの実行に時間がかかることになります。その間、レプリケーション ラグは増加しています。レプリカがこのトランザクションを完了すると、ソース上の書き込みワークロードとレプリカの処理速度によって追いつく時間が変わります。

長時間のトランザクションを避けるために、次のような解決策が考えられます。

  • トランザクションを複数の小さなトランザクションに分割します。
  • 1 つの大きな書き込みクエリを小さなバッチに分割します。
  • DML を含むトランザクションから長い SELECT クエリを分離します。
並列レプリケーション フラグを変更するとエラーが発生する。 1 つ以上のフラグに間違った値が設定されています。

エラー メッセージが表示されているプライマリ インスタンスで、並列レプリケーション フラグを設定します。

  1. binlog_transaction_dependency_tracking フラグと transaction_write_set_extraction フラグを変更します。
    • binlog_transaction_dependency_tracking=COMMIT_ORDER
    • transaction_write_set_extraction=OFF
  2. slave_pending_jobs_size_max フラグを追加します。

    slave_pending_jobs_size_max=33554432

  3. transaction_write_set_extraction フラグを変更します。

    transaction_write_set_extraction=XXHASH64

  4. binlog_transaction_dependency_tracking フラグを変更します。

    binlog_transaction_dependency_tracking=WRITESET

レプリカの作成がタイムアウトで失敗します。 プライマリ インスタンスで長時間 commit されていないトランザクションが実行されると、リードレプリカの作成に失敗することがあります。

実行中のクエリをすべて停止してからレプリカを再作成します。

次のステップ