リードレプリカの作成

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

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

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

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

始める前に

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

リードレプリカの作成

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

Console

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

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

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

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

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

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

  5. [リードレプリカの作成] ページで、インスタンス ID を更新します。また、必要に応じて、名前、リージョン、ゾーンなどの必須の構成オプションを更新します。
  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 パラメータを使用して別のリージョンを指定できます。

    プライマリ インスタンスにプライベート IP アドレスしかない場合は、--no-assign-ip パラメータをコマンドに追加します。

    レプリカは、プライマリ インスタンスと同じ VPC ネットワーク内に作成する必要があります。

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

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

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

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

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」形式の時刻
    • enabled: プライマリ インスタンスの場合は true に設定します。レプリカ インスタンスの場合は false に設定します。

    HTTP メソッドと URL:

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

    JSON 本文のリクエスト:

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

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

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

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

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

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

    • 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」

    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,
      }
    }
    

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

    次のような 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」形式の時刻
    • enabled: プライマリ インスタンスの場合は true に設定します。レプリカ インスタンスの場合は false に設定します。

    HTTP メソッドと URL:

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

    JSON 本文のリクエスト:

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

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

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

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

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

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

    • 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」

    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,
      }
    }
    

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

    次のような 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. [保存] をクリックします。

トラブルシューティング

問題 トラブルシューティング
リードレプリカの作成時にレプリケーションが開始されなかった。 ログファイルに、より具体的なエラーが記録されている可能性があります。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 などのクエリでは、レプリカに膨大な数の更新が蓄積されるため、行ベースのレプリケーションでレプリケーション ラグが発生します。

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

並列レプリケーション フラグを変更するとエラーが発生する。 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 されていないトランザクションが実行されると、リードレプリカの作成に失敗することがあります。

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

次のステップ