トラブルシューティング

次のいずれかのページで、質問や問題がすでに解決されていないかを確認してください。

このページには次のトピックが含まれています。

バックアップとリカバリ

問題 トラブルシューティング
現在のオペレーションのステータスを確認できない。 Google Cloud コンソールでは、オペレーションの完了時に成功または失敗のみが表示されます。警告やその他の情報を表示するように設計されていません。

特定の Cloud SQL インスタンスのすべてのオペレーションを確認するには、gcloud sql operations list コマンドを実行します。
オンデマンド バックアップ オペレーションを開始したユーザーを確認したい。 オペレーションを開始したユーザーはユーザー インターフェースに表示されません。

ユーザーを特定するには、ログを表示してテキストでフィルタします。個人情報の監査ログが必要になる場合があります。関連するログファイルは次のとおりです。

  • cloudsql.googleapis.com/sqlagent.out
  • cloudsql.googleapis.com/sqlserver.err
  • Cloud Audit Logs が有効で、表示に必要な権限がある場合は、cloudaudit.googleapis.com/activity を使用できる場合があります。
インスタンスを削除すると、その後インスタンスのバックアップは作成できません。

インスタンスの完全削除後にデータを復元することはできません。ただし、インスタンスが復元されると、バックアップも復元されます。削除したインスタンスの復元について詳しくは、復元バックアップをご覧ください。

エクスポートを行っていれば、新しいインスタンスを作成してインポートを行い、データベースを再作成できます。エクスポートでは Cloud Storage への書き込みが行われ、インポートでは Cloud Storage からの読み取りが行われます。
自動バックアップが長時間停止していて、キャンセルできない。 データベースのサイズによっては、バックアップに時間がかかる可能性があります。

オペレーションをキャンセルする必要がある場合は、カスタマー サポートにインスタンスの force restart を依頼できます。
SQL ダンプファイルで参照されているユーザーが存在しない場合、復元オペレーションが失敗する可能性があります。 SQL ダンプを復元する前に、オブジェクトを所有しているデータベース ユーザーか、ダンプされたデータベース内のオブジェクトに対する権限が付与されているデータベース ユーザーが、ターゲット データベース内に存在している必要があります。そうでない場合、復元オペレーションを実行すると、元の所有権または権限でのオブジェクトの再作成に失敗します。

SQL ダンプを復元する前に、データベース ユーザーを作成します。
自動バックアップの保持日数を 7 日から 30 日以上に増やしたい。 保持する自動バックアップ数を構成できますが、デフォルト値（7 件）未満の数は保持できません。自動バックアップは、構成された保持値に基づいて定期的に削除されます。復元可能な自動バックアップは、現在表示されているバックアップだけです。

バックアップを無期限に保持する場合は、オンデマンド バックアップを作成します。オンデマンド バックアップは、自動バックアップと同じ方法では削除されません。オンデマンド バックアップは無期限に維持されます。つまり、削除されるか、所属するインスタンスが削除されるまで保持されます。このタイプのバックアップは自動的に削除されないため、課金に影響する可能性があります。
自動バックアップが失敗したときにメール通知を受信できない。 Cloud SQL からバックアップのステータスの通知を受信するには、ログベースのアラートを構成します。
Transact-SQL RESTORE コマンドや SQL Server Management Studio（SSMS）を使用してインスタンスを復元することはできません。 Cloud SQL は、SSMS を介したインスタンスの復元をサポートしていません。インスタンスを復元するには、gcloud sql import コマンドを実行します。

クローンを作成

問題 トラブルシューティング
constraints/sql.restrictAuthorizedNetworks エラーでクローンの作成に失敗する。 クローン作成のオペレーションが、Authorized Networks 構成によってブロックされている。Authorized Networks は、Google Cloud コンソールの [接続] セクションでパブリック IP アドレスに構成されており、セキュリティに関する考慮事項により、クローン作成が許可されていません。

可能であれば、Cloud SQL インスタンスからすべての Authorized Networks エントリを削除します。それができない場合は、Authorized Networks エントリなしでレプリカを作成します。
エラー メッセージ: Failed to create subnetwork. Couldn't find free blocks in allocated IP ranges. Please allocate new ranges for this service provider. Help Token: [help-token-id].

Google Cloud コンソールを使用して、プライベート IP アドレスを持つインスタンスのクローンを作成しようとしていますが、割り振られた IP 範囲を指定しなかったため、ソース インスタンスが指定した範囲で作成されていません。その結果、クローニングされたインスタンスはランダムな範囲に作成されます。

gcloud を使用してインスタンスのクローンを作成し、
--allocated-ip-range-name パラメータの値を指定します。詳細については、プライベート IP を使用したインスタンスのクローン作成をご覧ください。

接続

問題 トラブルシューティング
Aborted connection. 次のような問題が考えられます。
  • ネットワークが不安定。
  • TCP keep-alive コマンドに応答しない（クライアントまたはサーバーのいずれかが応答しないか、過負荷の可能性があります）。
  • データベース エンジン接続の存続期間を超えたため、サーバーが接続を終了している。

アプリケーションは、接続プールや再試行などのベスト プラクティスに従ってネットワーク障害に対応する必要があります。通常、可能であれば、これらのエラーが接続プーラーによって検出されます。エラーが検出されない場合、アプリケーションは、再試行するか安全に失敗する必要があります。

接続の再試行には、次の方法をおすすめします。

  1. 指数バックオフ。再試行の間隔を指数関数的に増やします。
  2. ランダム化されたバックオフも追加します。

これらの方法を組み合わせると、スロットリングが減ります。

インスタンスの作成

問題 トラブルシューティング
エラー メッセージ: Failed to create subnetwork. Router status is temporarily unavailable. Please try again later. Help Token: [token-ID] Cloud SQL インスタンスをもう一度作成してみてください。
エラー メッセージ: Failed to create subnetwork. Required 'compute.projects.get' permission for PROJECT_ID プライベート IP アドレスを使用してインスタンスを作成すると、Service Networking API を使用してサービス アカウントがジャスト イン タイムで作成されます。Service Networking API を最近有効にしたばかりの場合は、サービス アカウントが作成されず、インスタンスの作成が失敗する可能性があります。この場合、サービス アカウントがシステム全体に伝播するのを待つか、必要な権限を使用して手動で追加する必要があります。

エクスポート

問題 トラブルシューティング
HTTP Error 409: Operation failed because another operation was already in progress. 保留中のオペレーションがインスタンスにすでに存在しています。一度に実行できるオペレーションは 1 つだけです。現在のオペレーションが完了してからリクエストを試してください。
HTTP Error 403: The service account does not have the required permissions for the bucket. バケットが存在し、バケットへのエクスポートを許可する Storage Object Creator ロール（roles/storage.objectCreator）が Cloud SQL インスタンス用のサービス アカウント（エクスポートを行っているアカウント）に付与されていることを確認します。Cloud Storage に適用される IAM ロールをご覧ください。
エクスポートを自動化したい。 Cloud SQL には、エクスポートを自動化する方法がありません。

自動バックアップの自動化に関する記事のように、Google Cloud プロダクト（Cloud Scheduler、Pub/Sub、Cloud Run functions）を使用して、独自の自動エクスポート システムを構築できます。

フラグ

問題 トラブルシューティング
Cloud SQL for SQL Server は、既存のインスタンスのタイムゾーンの変更をサポートしていません。

Cloud SQL では、SQL Server は新しいインスタンスのタイムゾーンの設定をサポートしていますが、既存のインスタンスのタイムゾーンは設定できません。

Cloud SQL for SQL Server では、時間変換などに AT TIME ZONE 関数を使用できます。この関数の詳細については、AT TIME ZONE（Transact-SQL）をご覧ください。

高可用性

問題 トラブルシューティング
手動フェイルオーバーの指標が表示されない。 自動フェイルオーバーの指標のみが表示されます。
Cloud SQL インスタンス リソース（CPU と RAM）の使用率が 100% に近いため、高可用性インスタンスが停止する。 インスタンスのマシンサイズが負荷に対して小さすぎます。

インスタンスを編集してより大きなマシンサイズにアップグレードし、CPU とメモリのサイズを大きくします。

インポート

問題 トラブルシューティング
HTTP Error 409: Operation failed because another operation was already in progress. 保留中のオペレーションがインスタンスにすでに存在しています。一度に実行できるオペレーションは 1 つだけです。現在のオペレーションが完了してからリクエストを試してください。
インポート オペレーションに時間がかかりすぎる。 アクティブな接続が多すぎると、インポート オペレーションが妨げられる可能性があります。

未使用のオペレーションを終了します。Cloud SQL インスタンスの CPU とメモリ使用量をチェックして、十分なリソースがあることを確認します。インポートに最大限のリソースを確保するため、オペレーションを開始する前にインスタンスを再起動することをおすすめします。

再起動により、次の処理が行われます。

  • すべての接続を終了します。
  • リソースを消費している可能性のあるタスクをすべて終了します。
ダンプファイルで参照しているユーザーが存在しない場合、インポート オペレーションが失敗することがある。 ダンプファイルをインポートする前に、オブジェクトを所有しているデータベース ユーザーか、ダンプされたデータベース内のオブジェクトに対する権限が付与されているデータベース ユーザーがターゲット データベース内に存在している必要があります。そうでない場合、インポート オペレーションを実行すると、元の所有権または権限でのオブジェクトの再作成に失敗します。

インポートする前に、データベース ユーザーを作成します。
LSN の不一致 トランザクション ログのバックアップのインポート順序が正しくないか、トランザクション ログのチェーンが壊れています。
バックアップ セットテーブルと同じ順序でトランザクション ログのバックアップをインポートします。
StopAt が早すぎる このエラーは、トランザクション ログファイルの最初のログが StopAt タイムスタンプより後であることを示します。たとえば、トランザクション ログファイルの最初のログが 2023-09-01T12:00:00 で、StopAt フィールドの値が 2023-09-01T11:00:00 の場合、Cloud SQL がこのエラーを返します。
正しい StopAt タイムスタンプと正しいトランザクション ログファイルを使用していることを確認してください。

リンクされているサーバー

エラー メッセージ トラブルシューティング
Msg 7411, Level 16, State 1, Line 25

Server 'LINKED_SERVER_NAME' is not configured for DATA ACCESS. 		DataAccess オプションが無効になっている。次のコマンドを実行して、データアクセスを有効にします。
EXEC sp_serveroption
    @server='LINKED_SERVER_NAME',
    @optname='data access',
    @optvalue='TRUE'

LINKED_SERVER_NAME は、リンクされたサーバーの名前に置き換えます。
Access to the remote server is denied because no login-mapping exists. (Microsoft SQL Server, Error: 7416) 暗号化された接続を確立する際にこの問題が発生した場合は、リンクされたサーバーにアクセスするときに別の方法でユーザー ID を指定する必要があります。これを行うには、次のコマンドを実行します。
EXEC master.dbo.sp_addlinkedserver
   @server = N'LINKED_SERVER_NAME',
   @srvproduct= N'',
   @provider= N'SQLNCLI',
   @datasrc= N'TARGET_SERVER_ID',
   @provstr= N'Encrypt=yes;TrustServerCertificate=yes;User ID=USER_ID'

次のように置き換えます。

  • LINKED_SERVER_NAME は、リンクサーバーの名前に置き換えます。
  • TARGET_SERVER_ID は、ターゲット サーバーの名前、またはターゲット サーバーの IP アドレスとポート番号に置き換えます。
  • USER_ID は、ログインするユーザーに置き換えます。

Logging

問題 トラブルシューティング
監査ログが見つからない。 オペレーションが、ユーザー作成データを作成、変更、または読み取る認証済みのユーザー ドリブン API 呼び出しの場合、またはリソースの構成ファイルまたはメタデータにアクセスした場合にのみ、データアクセス ログに書き込まれます。
ログにオペレーション情報が見つからない。 オペレーションの詳細を確認したい場合があります。

たとえば、ユーザーが削除され、誰がその操作を行ったのかを確認できない場合があります。ログでは、オペレーションが開始したことは確認できますが、それ以上の情報は記録されません。このような詳細な個人情報（PII）を記録するには、監査ログを有効にする必要があります。
一部のログは、Cloud SQL for SQL Server インスタンスの error.log ログからフィルタリングされます。 フィルタリングされたログには、タイムスタンプのない AD ログが含まれます。また、Login failed for user 'x'. Reason: Token-based server access validation failed with an infrastructure error. Login lacks connect endpoint permission. [CLIENT: 127.0.0.1] も含まれます。これらのログは、混乱を招く可能性があるため、フィルタリングされています。
ログファイルが読みにくい。 ログを json またはテキストで表示することもできます。gcloud logging read コマンドを Linux の後処理コマンドと一緒に使用して、ログをダウンロードできます。

ログを JSON 形式でダウンロードするには:

gcloud logging read \
"resource.type=cloudsql_database \
AND logName=projects/PROJECT_ID \
/logs/cloudsql.googleapis.com%2FLOG_NAME" \
--format json \
--project=PROJECT_ID \
--freshness="1d" \
> downloaded-log.json

ログをテキスト形式でダウンロードするには:

gcloud logging read \
"resource.type=cloudsql_database \
AND logName=projects/PROJECT_ID \
/logs/cloudsql.googleapis.com%2FLOG_NAME" \
--format json \
--project=PROJECT_ID \
--freshness="1d"| jq -rnc --stream 'fromstream(1|truncate_stream(inputs)) \
| .textPayload' \
--order=asc
> downloaded-log.txt

インスタンスの管理

問題 トラブルシューティング
一時ストレージにより、自動ストレージが増加した。 自動ストレージが有効になっています。

再起動すると一時ファイルは削除されますが、保存容量は減りません。インスタンスのサイズをリセットできるのはカスタマー サポートのみです。
データが自動的に削除される。 ほとんどの場合、環境内のどこかでスクリプトが実行されています。

削除時刻の前後のログで、ダッシュボードや別の自動プロセスから不正なスクリプトが実行されていないかどうかを確認します。
インスタンスを削除できない。 エラー メッセージ ERROR: (gcloud.sql.instances.delete) HTTP Error 409: The instance or operation is not in an appropriate state to handle the request が表示されるか、インスタンスのフラグ ステータスが INSTANCE_RISKY_FLAG_CONFIG である可能性があります。

たとえば、次のような原因が考えられます。

  • 別のオペレーションが進行中です。Cloud SQL オペレーションは同時には実行されません。他のオペレーションが完了するのをお待ちください。
  • INSTANCE_RISKY_FLAG_CONFIG 警告は、少なくとも 1 つの beta フラグが使用されるたびにトリガーされます。危険なフラグ設定を削除して、インスタンスを再起動します。
一時的なデータサイズが大きいためにインスタンスが停止する。 クエリと負荷に応じて、一度に多くの一時テーブルが作成される場合があります。

サービスを再起動する以外の方法で ibtmp1 ファイルのサイズを小さくすることはできません。

緩和策の 1 つは、ROW_FORMAT=COMPRESSED を使用して一時テーブルを作成し、一時ファイル ディレクトリ内の file-per-table テーブルスペースに保存することです。ただし、各一時テーブルの file-per-table テーブルスペースの作成と削除によって、パフォーマンスが低下します。
アップグレード中の致命的なエラー。 ログに詳細が表示される場合がありますが、インスタンスを強制的に再作成するにはカスタマー サポートが必要になる場合があります。
ディスク容量が不足した後、再起動時にインスタンスが停止する。 自動ストレージ増加機能が有効になっていません。

インスタンスのストレージが不足していてストレージの自動増加機能が有効になっていない場合、インスタンスはオフラインになります。この問題を回避するには、インスタンスを編集して、ストレージの自動増加を有効にします。
オンプレミスのプライマリ インスタンスが停止する。 Google Cloud では、Cloud SQL に含まれていないインスタンスはサポートされません。
再起動時のシャットダウンが遅い。 インスタンスをシャットダウンしたときに、60 秒以内に終了しない未処理の接続があると、不完全なシャットダウンが発生します。

接続が 60 秒未満の場合は、データベースのコマンド プロンプトからの接続を含め、ほとんどの不完全なシャットダウンを回避できます。これらの接続を数時間または数日間維持すると、不完全なシャットダウンが発生する場合があります。
ユーザーを削除できない。 データベースに依存しているオブジェクトが存在する可能性があります。これらのオブジェクトを削除するか、別のユーザーに再割り当てする必要があります。

ユーザーに依存しているオブジェクトを特定し、それらのオブジェクトをドロップするか、別のユーザーに再度割り当てます。

ユーザーが所有するオブジェクトを見つける方法については、Stack Exchange に関するスレッドをご覧ください。
特定のクエリの実行が遅い。 クエリが遅くなる理由はさまざまですが、その多くはデータベース側の問題です。Cloud SQL でネットワーク レイテンシが問題になるのは、ソース（ライターまたはリーダー）リソースと宛先（Cloud SQL）リソースが異なるリージョンに存在している場合です。

一般的なパフォーマンスのヒントをご覧ください。

データベースの挿入、更新、削除が遅い場合は、次のことを考慮します。

  • 書き込みとデータベースの場所を確認します。データの送信距離が長いと、レイテンシが発生します。
  • 読み取りとデータベースの場所を確認します。レイテンシは、書き込みパフォーマンスより読み取りパフォーマンスに大きく影響します。

レイテンシを低減するために、ソースリソースと宛先リソースの両方を同じリージョンに配置することをおすすめします。
メモリ不足が示されているが、モニタリング グラフに表示されない。 インスタンスが失敗し、Out of memory が報告されていても、Google Cloud コンソールまたは Cloud Monitoring のグラフにはメモリがまだ残っているように表示される場合があります。

ワークロード以外にも、アクティブな接続の数や内部オーバーヘッド プロセスなど、メモリ使用量に影響を与える可能性のある要因があります。こうしたことが常にモニタリング グラフに反映されるとは限りません。

インスタンスに、ワークロードと追加のオーバーヘッドを考慮するのに十分なオーバーヘッドがあることを確認してください。
削除したインスタンスを復元する。 インスタンスを削除すると、バックアップを含め、そのインスタンスのすべてのデータが完全に失われます。

データを保持するには、インスタンスを削除する前に Cloud Storage にデータをエクスポートします。

Cloud SQL 管理者のロールには、インスタンスを削除する権限が含まれています。誤って削除されないように、このロールは必要な場合にのみ付与してください。
既存の Cloud SQL インスタンスの名前を変更したい。 既存のインスタンス名の変更はサポートされていません。

新しいインスタンスを作成することにより、既存のインスタンス名を変更できます。

  • 名前を変更するインスタンスのクローンを作成し、クローンを作成したインスタンスに新しい名前を設定できます。これにより、手動でデータをインポートしなくても、新しいインスタンスを作成できます。新しいインスタンスを作成する場合と同様に、クローンを作成したインスタンスにも新しい IP アドレスが割り当てられます。
  • インスタンスから Cloud Storage バケットにデータをエクスポートし、必要な名前で新しいインスタンスを作成してから、データを新しいインスタンスにインポートできます。

いずれの場合も、オペレーションの完了後に古いインスタンスを削除できます。パフォーマンスには影響がなく、インスタンスの構成設定（フラグ、マシンタイプ、ストレージ サイズ、メモリなど）をやり直す必要がないことから、クローンルートを使用することをおすすめします。
インスタンスの削除中にエラーが発生しました。 インスタンスに対して削除保護が有効になっている場合は、インスタンスを削除する計画を確認します。次に、インスタンスを削除する前に削除保護を無効にします。

Private Service Connect
問題 トラブルシューティング
インスタンスのサービス アタッチメントが、Private Service Connect エンドポイントを受け入れない。
  1. エンドポイントのステータスを確認します。

    gcloud

    ステータスを確認するには、gcloud compute forwarding-rules describe コマンドを使用します。

    gcloud compute forwarding-rules describe ENDPOINT_NAME \
--project=PROJECT_ID \
--region=REGION_NAME \
| grep pscConnectionStatus

    次の項目を置き換えます。

    • ENDPOINT_NAME: エンドポイントの名前
    • PROJECT_ID: エンドポイントを含む Google Cloud プロジェクトの ID またはプロジェクト番号
    • REGION_NAME: エンドポイントのリージョン名

    REST

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

    • PROJECT_ID: Private Service Connect エンドポイントを含む Google Cloud プロジェクトの ID またはプロジェクト番号
    • REGION_NAME: リージョンの名前
    • ENDPOINT_NAME: エンドポイントの名前

    HTTP メソッドと URL: 

    GET https://compute.googleapis.com/compute/v1/projects/PROJECT_ID/regions/REGION_NAME/forwardingRules/ENDPOINT_NAME

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

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

    {
  "kind": "compute#forwardingRule",
  "id": "ENDPOINT_ID",
  "creationTimestamp": "2024-05-09T12:03:21.383-07:00",
  "name": "ENDPOINT_NAME",
  "region": "https://www.googleapis.com/compute/v1/projects/PROJECT_ID/regions/REGION_NAME",
  "IPAddress": "IP_ADDRESS",
  "target": "https://www.googleapis.com/compute/v1/projects/PROJECT_ID/regions/REGION_NAME/serviceAttachments/SERVICE_ATTACHMENT_NAME",
  "selfLink": "https://www.googleapis.com/compute/v1/projects/PROJECT_ID/regions/REGION_NAME/forwardingRules/ENDPOINT_NAME",
  "network": "https://www.googleapis.com/compute/v1/projects/PROJECT_ID/global/networks/default",
  "serviceDirectoryRegistrations": [
    {
      "namespace": "goog-psc-default"
    }
  ],
  "networkTier": "PREMIUM",
  "labelFingerprint": "LABEL_FINGERPRINT_ID",
  "fingerprint": "FINGERPRINT_ID",
  "pscConnectionId": "CONNECTION_ID",
  "pscConnectionStatus": "ACCEPTED",
  "allowPscGlobalAccess": true
}
  2. エンドポイントのステータスが ACCEPTED であることを確認します。ステータスが PENDING の場合、インスタンスはエンドポイントを含む Google Cloud プロジェクトを許可していません。エンドポイントが作成されるネットワーク プロジェクトが許可されていることを確認します。詳細については、Private Service Connect が有効になっているインスタンスを編集するをご覧ください。

レプリケーション

問題 トラブルシューティング
作成時にリードレプリカがレプリケーションを開始しなかった。 ログファイルに、より具体的なエラーが記録されている可能性があります。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 されていないトランザクションが実行されると、リードレプリカの作成に失敗することがあります。

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