リードレプリカの作成

このページでは、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 パラメータをコマンドに追加します。

REST

  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 に設定します。

    後述のリクエスト データは、次のように置き換えてから使用します。

    • project-id: プロジェクト ID
    • instance-id: インスタンス ID
    • start-time「HH:MM」形式の時刻

    HTTP メソッドと URL:

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

    JSON 本文のリクエスト:

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

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

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

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

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

    後述のリクエスト データは、次のように置き換えてから使用します。

    • project-id: プロジェクト ID
    • 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",
      "name": "replica-name",
      "region": "replica-region",
      "settings":
      {
        "tier": "machine-type",
        "settingsVersion": 0,
      }
    }
    

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

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

トラブルシューティング

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

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

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

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

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

プライマリ インスタンスには少なくとも 1 週間分の binlog が必要です。存在しない場合、レプリカは複製を開始できません。

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

binlog が十分な数になるまで待ちます。


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

リードレプリカを作成できません - 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 スレッドに対応できない場合に発生します。クエリやワークロードによっては、特定のスキーマで一時的または永続的に高いレプリケーション ラグが発生することがあります。レプリケーション ラグの一般的な原因は次のとおりです。

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

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

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

  • インスタンスを編集して、レプリカのサイズを増やします。
  • データベースの負荷を軽減します。
  • テーブルをインデックスに登録します。
  • 遅いクエリを特定して修正します。
  • レプリカを再作成します。

次のステップ