PolarDB:よくある質問

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

SELECT t1.table_schema, t1.table_name
information_schema.TABLES t1 LEFT OUTERから
参加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が有効になっている場合、マルチマスタークラスター (データベース /テーブル) エディションのクラスターにアップグレードできますか?

はい。 ただし、Multi-master cluster (Database/Table) EditionのターゲットクラスタではSSLを有効にすることはできません。

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

はい。 ただし、Multi-master cluster (Database/Table) EditionのターゲットクラスタではTDEを有効にすることはできません。

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

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

移行および切り替え後、ソースPolarDB for MySQLクラスターは読み取り専用になります。 データをクラスターに書き込むことはできないため、DTSデータ同期タスクの宛先として使用することはできません。 DTSデータ同期タスクの送信先を新しいPolarDBクラスターに変更する必要があります。 ソースPolarDB for MySQLクラスターがDTSデータ同期タスクのデータソースとして使用されている場合、移行後の早い機会にDTSデータ同期タスクのデータソースを新しいPolarDBクラスターに変更することを推奨します。

DTSタスクのソースまたはターゲットデータベースインスタンスは、ModifyDtsJobEndpoint操作を呼び出すことによってのみ変更できます。 API操作の詳細については、「ModifyDtsJobEndpoint」をご参照ください。