リードレプリカの作成

このページでは、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 --enable-bin-log PRIMARY_INSTANCE_NAME
    バイナリ ロギングを有効にすると、インスタンスが再起動されます。
  4. レプリカを作成します。
    gcloud sql instances create REPLICA_NAME --master-instance-name=PRIMARY_INSTANCE_NAME
    

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

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

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

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

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

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

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

REST v1beta4

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

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

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

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

    HTTP メソッドと URL:

    GET https://www.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://www.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-n1-standard-4

    HTTP メソッドと URL:

    POST https://www.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. 左側のナビゲーションから [レプリカ] を選択します。
  5. 編集するレプリカの名前をクリックします。
  6. [編集] をクリックします。
  7. [構成オプション] で [フラグ] を展開します。
  8. [+ 追加] を選択します。
  9. フラグ名として「cloudsql.iam_authentication」と入力します。このフラグに対して [オン] が選択されていることを確認します。
  10. [保存] をクリックします。

トラブルシューティング

表内のリンクをクリックすると、詳細が表示されます。

この問題については... 次のような問題が考えられます... 次のことを試します...
リードレプリカの作成時にレプリケーションが開始されなかった。 多くの根本原因が考えられます。 ログで詳細を確認します
リードレプリカを作成できない - invalidFlagValue エラー 明示的に指定されたフラグかデフォルトのフラグのいずれかが無効です。 フラグの値とログを調べて詳細を確認します
リードレプリカを作成できない - 不明なエラー。 多くの根本原因が考えられます。 ログで詳細を確認します
ディスクに空きがない。 レプリカの作成中にプライマリ インスタンスのディスクの空きがなくなる可能性があります。 プライマリ インスタンスをより大きなディスクサイズにアップグレードします
レプリカ インスタンスのメモリ使用量が多すぎる。 レプリカは、頻繁にリクエストされる読み取りオペレーションをキャッシュに保存できます。 レプリカ インスタンスを再起動して、一時メモリ領域を再利用します。
レプリケーションが停止しました。 保存容量の上限に達しましたが、保存容量の自動増加が有効になっていません。 ストレージの自動増量を有効にします
レプリケーション ラグが常に大きい。 多くの根本原因が考えられます。 こちらをご確認ください。

リードレプリカの作成時にレプリケーションが開始されなかった

リードレプリカの作成時にレプリケーションが開始されませんでした。

次のような問題が考えられます

ログファイルに、より具体的なエラーが表示される可能性があります。

次の方法をお試しください

Cloud Logging のログを調べて、実際のエラーを確認します。


リードレプリカを作成できない - invalidFlagValue エラー

リードレプリカを作成できません - invalidFlagValue

次のような問題が考えられます

リクエスト内のフラグのいずれかが無効です。これは、明示的に指定されたフラグか、デフォルト値に設定されたフラグである可能性があります。

次の方法をお試しください

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

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


リードレプリカを作成できない - 不明なエラー

リードレプリカを作成できません - unknown error

次のような問題が考えられます

ログファイルに、より具体的なエラーが表示される可能性があります。

次の方法をお試しください

Cloud Logging のログを調べて、実際のエラーを確認します。

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


ディスクに空きがない

UPDATE_DISK_SIZE エラーまたは mysqld: disk is full エラー。

次のような問題が考えられます

レプリカの作成中にプライマリ インスタンスのディスクの空きがなくなる可能性があります。

次の方法をお試しください

プライマリ インスタンスを編集して、より大きなディスクサイズにアップグレードします。


レプリカ インスタンスのメモリ使用量が多すぎる

レプリカ インスタンスのメモリ使用量が多すぎます。

次のような問題が考えられます

レプリカは一時メモリを使用して頻繁にリクエストされる読み取りオペレーションをキャッシュするため、プライマリ インスタンスより多くのメモリを使用する可能性があります。

次の方法をお試しください

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


レプリケーションが停止した

レプリケーションが停止しました。

次のような問題が考えられます

保存容量の上限(>automatic storage increase is disabled)に達しました。

次の方法をお試しください

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


レプリケーション ラグが常に大きい

レプリケーション ラグが常に大きい。

次のような問題が考えられます

書き込みの負荷が大きすぎてレプリカで処理できません。レプリケーション ラグは、レプリカの SQL スレッドで IO スレッドに対応できない場合に発生します。クエリやワークロードによっては、特定のスキーマで一時的または永続的に高いレプリケーション ラグが発生することがあります。レプリケーション ラグの一般的な原因は次のとおりです。

  • レプリカのクエリが遅い。遅いクエリを見つけて修正します。
  • すべてのテーブルに一意キーまたは主キーが必要です。一意のキーまたは主キーのないテーブルを更新するたびに、レプリカでテーブル全体がスキャンされます。
  • DELETE ... WHERE field < 50000000 などのクエリでは、レプリカに膨大な数の更新が蓄積されるため、行ベースのレプリケーションでレプリケーション ラグが発生します。

次の方法をお試しください

考えられるソリューションは次のとおりです。

次のステップ