PolarDB:FAQ

アップグレード評価のチェック項目が失敗した場合はどうすればよいですか？

SELECT t1.table_schema, t1.table_name 
FROM information_schema.TABLES t1 LEFT OUTER 
	JOIN information_schema.TABLE_CONSTRAINTS t2 
  ON t1.table_schema = t2.TABLE_SCHEMA AND t1.table_name = t2.TABLE_NAME AND t2.CONSTRAINT_NAME 
  IN ("PRIMARY") 
WHERE t2.table_name IS NULL AND t1.table_type = "BASE TABLE" AND t1.TABLE_SCHEMA NOT IN ("information_schema", "performance_schema", "mysql", "sys") 

ソースとデスティネーションの PolarDB for MySQL クラスタは同じ仕様を使用する必要がありますか？

いいえ。必要に応じて、デスティネーション PolarDB for MySQL クラスタの仕様を選択できます。ソースクラスタの仕様以上の値を指定することをお勧めします。

アップグレード前にクラスタを購入する必要がありますか？

いいえ。アップグレード中に、ソース PolarDB for MySQL クラスタと同じデータを持つクラスタが作成および購入されます。

アップグレードは、ソースクラスタの通常の動作に影響しますか？

いいえ。

データ同期は、ソースクラスタのパフォーマンスに影響しますか？

データ同期にはデータクエリが伴うため、ソースクラスタのクエリパフォーマンスが低下します。

データ同期はビジネスに影響しますか？

同期中にデータが失われることはありません。ビジネスのダウンタイムは 10 分未満です。ダウンタイム中は、ビジネスは中断され、増分データは生成されませんが、データベースは停止しません。必要に応じて、移行をロールバックできます。

アップグレードをキャンセルするとどうなりますか？

アップグレードをキャンセルすると、次の状況が発生します。

• ソースクラスタからデスティネーションクラスタへの同期リンクが切断されます。ソースクラスタは、デスティネーションクラスタに関連付けられなくなります。

• デスティネーションクラスタは読み取り可能かつ書き込み可能になり、自動的に解放されません。クラスタを使用しない場合は、追加コストが発生しないように、できるだけ早く解放してください。

• 手動でアップグレードをキャンセルした場合、クラスタのバイナリロギング機能を無効にするかどうかを指定できます。移行が自動的にキャンセルされた場合、バイナリロギング機能は無効になりません。

  説明

  クラスタのバイナリロギング機能が無効になっている場合、クラスタの書き込みパフォーマンスがわずかに向上します。バイナリロギング機能が無効になった後も、既存のバイナリログは保持されます。バイナリログを削除するには、最初にバイナリログの保存期間を短縮します。バイナリログが自動的に削除された後、バイナリロギング機能を無効にすることができます。バイナリロギング機能を無効にすると、クラスタは自動的に再起動します。再起動タスクは 5 分以内に完了します。再起動中は、サービスが約 40 秒間中断されます。再起動時間は、データ量とテーブル数によって異なります。オフピーク時にバイナリロギング機能を無効にし、アプリケーションがデータベースサービスに自動的に再接続できることを確認することをお勧めします。

ビジネスがデスティネーションクラスタに切り替えられた後、アプリケーションのエンドポイントを変更する必要がありますか？

アップグレードで エンドポイントで切り替え を選択できます。システムは、ソースクラスタとデスティネーションクラスタのエンドポイントを自動的に切り替えます。アプリケーションの構成を変更することなく、デスティネーションクラスタに接続できます。

アップグレードで エンドポイントで切り替え を選択しました。アップグレード完了後、デスティネーションクラスタが新しいエンドポイントを使用するのはなぜですか？

ソースクラスタとデスティネーションクラスタの両方にエンドポイントがある場合にのみ、エンドポイントを切り替えることができます。デフォルトでは、内部ネットワークのプライマリエンドポイントのみを切り替えることができます。他のタイプのエンドポイントを切り替えるには、事前にエンドポイントを作成する必要があります。クラスタのエンドポイントまたはプライマリエンドポイントを作成する方法の詳細については、「クラスタエンドポイントまたはプライマリエンドポイントを申請する」をご参照ください。

ビジネスが切り替えられた後、PolarDB クラスタに接続できないのはなぜですか？または、接続後にクラスタにデータを書き込めないのはなぜですか？

エンドポイントが切り替えられた後、DNS キャッシュデータの有効期限が切れているために問題が発生する可能性があります。 PolarDB クラスタ内のデータベースに接続できないか、読み取り操作のみがサポートされる可能性があります。問題を解決するには、DNS キャッシュをリフレッシュすることをお勧めします。

アップグレードが完了し、ビジネスが切り替えられた後、PolarDB コンソールに アップグレードの完了 が表示されないのはなぜですか？

アップグレードの完了 を押した場合、操作の繰り返しを防ぐために、このボタンは非表示になります。

アップグレード後、デスティネーションクラスタにソースクラスタと同じアカウントとパスワードを作成する必要がありますか？

いいえ。アップグレード後、デスティネーションクラスタは、ソースクラスタのアカウント設定、データベース、IP ホワイトリスト、および必須パラメーターを保持します。

ソースクラスタで SSL が有効になっている場合、アップグレードできますか？

はい。SSL が有効になっているソースクラスタをアップグレードできます。

ソースクラスタで TDE が有効になっている場合、アップグレードできますか？

はい。TDE が有効になっているソースクラスタをアップグレードできます。

ソースクラスタで SSL が有効になっている場合、マルチマスタークラスタ（データベース/テーブル）エディションのクラスタにアップグレードできますか？

はい。ただし、マルチマスタークラスタ（データベース/テーブル）エディションのデスティネーションクラスタでは SSL を有効にできません。

ソース PolarDB for MySQL クラスタで TDE が有効になっている場合、マルチマスタークラスタ（データベース/テーブル）エディションのクラスタにアップグレードできますか？

はい。ただし、マルチマスタークラスタ（データベース/テーブル）エディションのデスティネーションクラスタでは TDE を有効にできません。

メジャーエンジンバージョンアップグレードの前に、ソース PolarDB for MySQL クラスタに対して DTS データ同期タスクが開始された場合、アップグレード中にタスクは影響を受けますか？

いいえ。メジャーエンジンバージョンアップグレード中に、システムはソースクラスタから新しい PolarDB for MySQL クラスタに完全データを複製します。次に、ソースクラスタから新しいクラスタに増分データが同期されます。 DTS データ同期タスクのデータソースは、ソースクラスタのままです。新しい PolarDB for MySQL クラスタへのデータ移行は、ソースクラスタの操作には影響しません。

メジャーバージョンアップグレード中に、DTS タスクスイッチオーバー機能を使用して、DTS 同期または移行タスクのソースクラスタまたはデスティネーションクラスタを変更または置換して、スムーズなビジネストランジションを実現できます。

アップグレードするクラスタが現在のゾーンで利用できなくなった場合でも、クラスタをアップグレードできますか？

はい。同じリージョン内の別のゾーンでアップグレード用のクラスタを購入できます。データは影響を受けません。