このトピックでは、PolarDB for MySQL、、 に関するよくある質問に回答します。
よくある質問
Q：PolarDB とは何ですか？
A：PolarDB は、世界中の 10 以上のリージョンにあるデータセンターにデプロイされているリレーショナルデータベースのクラウドサービスで、すぐに利用を開始できます。PolarDB は、MySQL と 100% 互換、PostgreSQL と 100% 互換、そして Oracle の構文と高い互換性を持つ 3 つの独立したエンジンをサポートしています。最大 200 TB のストレージ容量を提供します。詳細については、「PolarDB for MySQL Enterprise Edition とは」、「」、または「」をご参照ください。
Q：PolarDB が従来のデータベースよりも優れた選択肢である理由は何ですか？
A：従来のデータベースと比較して、PolarDB は最大 200 TB のデータを保存でき、高可用性、高い信頼性、エラスティックスケーリング、ロックフリーバックアップなどの機能を提供します。詳細については、「メリット」、「」、または「」をご参照ください。
Q：PolarDB はいつリリースされ、いつ商用利用が可能になりましたか？
A：PolarDB は 2017 年 9 月にパブリックプレビューとしてリリースされ、2018 年 3 月に商用利用が可能になりました。
Q：クラスターとノードとは何ですか？
A：PolarDB Cluster Edition は、マルチノードアーキテクチャを採用しています。クラスターには、1 つのプライマリノードと複数の読み取り専用ノードを含みます。単一の PolarDB クラスターは、ゾーンをまたいでデプロイできますが、リージョンをまたいでデプロイすることはできません。サービスはクラスターレベルで管理および課金されます。詳細については、「用語」、「」、または「」をご参照ください。
Q：どのプログラミング言語がサポートされていますか？
A：PolarDB は、Java、Python、PHP、Go、C、C++、.NET、Node.js など、さまざまなプログラミング言語をサポートしています。ネイティブ MySQL をサポートするプログラミング言語はすべて、PolarDB for MySQL で動作します。詳細については、MySQL の公式サイトをご参照ください。
Q：どのストレージエンジンがサポートされていますか？
A：PolarDB は 2 つの製品シリーズを提供しています。サポートされているストレージエンジンはシリーズによって異なります。
PolarDB for MySQL Cluster Edition は、すべてのテーブルに InnoDB ストレージエンジンを使用します。テーブルを作成すると、PolarDB for MySQL は、MyISAM、Memory、CSV などの InnoDB 以外のエンジンを自動的に InnoDB に変換します。これにより、移行元のテーブルが InnoDB を使用していなくても、PolarDB for MySQL に正常に移行できます。
Q：PolarDB は分散データベースですか？
A：はい。PolarDB は、並列 Raft コンセンサスプロトコルに基づく分散ストレージクラスターです。そのコンピュートエンジンは、異なるサーバーに分散された 1〜16 個のコンピュートノードで構成されています。このクラスターは、最大 200 TB のストレージ容量を提供し、最大 88 CPU コアと 710 GB のメモリをサポートします。ワークロードに影響を与えることなく、ストレージリソースとコンピュートリソースをオンラインで動的にスケーリングできます。
Q：PolarDB クラスターを購入した後、シャーディングを実装するために PolarDB-X データベースミドルウェアも購入する必要がありますか？
A：はい。
Q：PolarDB はテーブルパーティショニングをサポートしていますか？
A：はい。
Q：購入後に PolarDB クラスターのリージョンを変更できますか？
A：いいえ、購入後にクラスターのリージョンを変更することはできません。
Q：PolarDB にはパーティショニングメカニズムが自動的に含まれていますか？
A：はい。PolarDB はストレージレイヤーでパーティショニングを実行しますが、これはユーザーに対して透過的です。
Q：シングルノードクラスターは、どのようにしてサービス可用性とデータの信頼性を確保しますか？
A：シングルノードクラスターは、特定の目的のために単一のコンピュートノードで動作します。ノードは 1 つだけですが、シングルノードクラスターは、瞬時のコンピュートスケジューリングや分散マルチレプリカストレージなどのテクノロジーを活用して、高いサービス可用性とデータの信頼性を確保します。
Q：シングルノードの PolarDB クラスターはどのように購入しますか？
A：シングルノード製品シリーズは提供を終了しました。ただし、PolarDB クラスターの購入時に読み取り専用ノードの数を 0 に設定することで、シングルノードクラスターとして動作するクラスターを作成できます。
互換性
Q：PolarDB は MySQL Community Edition と互換性がありますか？
A：PolarDB for MySQL は MySQL Community Edition と 100% 互換性があります。
Q：どのトランザクション分離レベルがサポートされていますか？
A：PolarDB for MySQL は、READ-UNCOMMITTED、READ-COMMITTED (デフォルト) 、および REPEATABLE-READ のトランザクション分離レベルをサポートしています。SERIALIZABLE トランザクション分離レベルはサポートされていません。
Q：SHOW PROCESSLIST の出力は MySQL Community Edition と異なりますか？
A：プライマリエンドポイントを使用してクラスターに接続する場合、出力は同じです。クラスターエンドポイントを使用する場合、出力は若干異なります。同じスレッド ID を持つ複数のレコードが見つかりますが、それぞれが PolarDB for MySQL クラスター内のノードに対応しています。
Q：PolarDB for MySQL のメタデータロック (MDL) メカニズムは MySQL Community Edition と異なりますか？
A：いいえ、PolarDB for MySQL の MDL メカニズムは MySQL Community Edition と同じです。ただし、PolarDB for MySQL ノードは共有ストレージアーキテクチャを使用しているため、プライマリノードで DDL 操作を実行すると、読み取り専用ノードが DDL 操作からの中間データを読み取り、データ不整合につながる可能性があります。これを防ぐために、PolarDB for MySQL は、DDL 操作に関与する排他的な MDL を REDO ログを使用して読み取り専用ノードに同期します。これにより、DDL 操作中に読み取り専用ノード上の他のユーザースレッドがテーブルにアクセスできなくなります。場合によっては、これにより DDL 操作が停止することがあります。
SHOW PROCESSLISTコマンドを実行して、DDL 操作の実行ステータスを表示できます。ステータスがWait for syncing with replicasの場合、停止が発生したことを示します。この問題の解決方法については、「DDL ステートメントの実行ステータスと MDL ステータスの表示」をご参照ください。Q：バイナリログフォーマットは、ネイティブの MySQL フォーマットと異なりますか？
A：いいえ、違いはありません。
Q：パフォーマンススキーマと sys スキーマはサポートされていますか？
A：はい。
Q：テーブル統計の収集メカニズムは MySQL Community Edition と異なりますか？
A：PolarDB for MySQL クラスターのプライマリノード上のテーブル統計は、MySQL Community Edition のものと一致しています。プライマリノードと読み取り専用ノード間で一貫した実行計画を確保するために、プライマリノードでの各統計更新は読み取り専用ノードに同期されます。さらに、読み取り専用ノードで
ANALYZE TABLEコマンドを実行して、ディスクから最新の統計をプロアクティブに読み込むことができます。Q：PolarDB は XA トランザクションをサポートしていますか？ 公式の MySQL 実装と異なりますか？
A：はい、PolarDB は XA トランザクションをサポートしており、公式の MySQL 実装との違いはありません。
Q：PolarDB は全文検索をサポートしていますか？
A：はい。
説明全文検索インデックスを使用する場合、読み取り専用ノードのインデックスキャッシュにデータレイテンシーが発生する可能性があります。最新のデータを取得できるように、全文検索インデックスを使用する読み取り操作と書き込み操作の両方でプライマリエンドポイントを使用することを推奨します。
Q：Percona Toolkit はサポートされていますか？
A：はい。ただし、オンライン DDL の使用を推奨します。
Q：gh-ost はサポートされていますか？
A：はい。ただし、オンライン DDL の使用を推奨します。
課金
Q：PolarDB クラスターの課金項目は何ですか？
A：課金項目には、ストレージスペース、コンピュートノード、バックアップ (無料クォータあり)、および SQL Explorer (オプション) が含まれます。詳細については、「課金項目」、「」、または「」をご参照ください。
Q：課金対象のストレージスペースには何が含まれますか？
A：課金対象のストレージスペースには、データベーステーブルファイル、インデックスファイル、undo ログファイル、redo ログファイル、binlog ファイル、スローログファイル、およびいくつかのシステムファイルが含まれます。詳細については、「概要」、「」、または「」をご参照ください。
Q：読み取り専用ノードを追加した場合、どのように課金されますか？
A：読み取り専用ノードの価格は、プライマリノードの価格と同じです。詳細については、「コンピュートノードの料金詳細」、「」、または「」をご参照ください。
Q：読み取り専用ノードを追加すると、ストレージ容量は 2 倍になりますか？
A：いいえ。 PolarDB は、コンピューティングとストレージを分離するアーキテクチャを使用しています。
ストレージスペースはサーバーレスであるため、購入時に容量を選択する必要はありません。データが増加するにつれて自動的にスケールし、実際に使用したデータ量に応じて課金されます。各クラスター仕様には最大ストレージ容量があります。ストレージの上限を増やすには、クラスター仕様をアップグレードする、する、またはする必要があります。
Q：従量課金クラスターの課金を停止するにはどうすればよいですか？
A：クラスターが不要になった場合は、リリースしてください。クラスターをリリースすると、以降のすべての課金が停止します。
Q：一時的なアップグレード中にクラスターの仕様を変更できますか？
A：一時的なアップグレード中、クラスターのステータスが Running の間は、手動で仕様をアップグレードすることが可能です。ただし、手動でのダウングレード、オートスケーリングの有効化、またはノードの追加または削除はできません。
Q：PolarDB のパブリック帯域幅とは何ですか？また、関連費用は発生しますか？
A：PolarDB 自体にはパブリック帯域幅の制限はありません。帯域幅は、主に使用する Server Load Balancer (SLB) サービスに依存します。PolarDB 自体は、パブリック接続に対して課金しません。
Q：サブスクリプションのクラスターで日次料金が引き続き請求されるのはなぜですか？
A：PolarDB の課金項目には、コンピュートノード (プライマリノードと読み取り専用ノード)、ストレージスペース、データバックアップ (無料クォータを超えた場合にのみ課金)、SQL Explorer (オプション)、およびグローバルデータベースネットワーク (GDN) (オプション) が含まれます。詳細については、「課金項目」をご参照ください。サブスクリプションの課金方法では、クラスター作成時にコンピュートノードの料金を前払いする必要がありますが、ストレージスペース、データバックアップ、および SQL Explorer の費用は含まれていません。これらの従量課金項目の料金は、1時間ごとにアカウントから引き落とされます。したがって、サブスクリプションであっても、従量課金の請求が発生します。
Q：ApsaraDB RDS for MySQL から PolarDB へのワンクリック移行に追加料金はかかりますか？
A：ワンクリック移行プロセスは無料です。課金対象となるのは、ApsaraDB RDS for MySQL インスタンスと PolarDB クラスター自体のみです。
Q：
DELETEコマンドを使用して PolarDB テーブルからデータを削除した後も、ストレージ料金が課金され続けるのはなぜですか？A：
DELETEコマンドは行を削除対象としてマークするだけで、テーブルスペースを解放しません。
クラスターアクセスと読み書き分離
Q: PolarDB で読み書き分離を実装するにはどうすればよいですか？
A: アプリケーションでクラスターエンドポイントを使用するだけで、設定済みの読み書きモードに基づいて読み書き分離が実装されます。詳細については、「データベースプロキシの設定」、、または をご参照ください。
Q: PolarDB クラスターでサポートされている読み取り専用ノードの最大数はいくつですか？
A: PolarDB は分散クラスターアーキテクチャを採用しています。クラスターには、1 つのプライマリノードと最大 15 個の読み取り専用ノードが含まれます。高可用性を確保するには、少なくとも 1 つの読み取り専用ノードが必要です。
Q: 複数の読み取り専用ノード間でワークロードが不均衡になるのはなぜですか?
A: 読み取り専用ノード間のワークロードが不均衡になる原因として、ノードへの接続数が少ないことや、カスタムクラスターエンドポイントの設定にすべての読み取り専用ノードが含まれていないことなどが考えられます。
Q: プライマリノードの負荷が高い、または低い原因は何ですか?
A: プライマリノードの負荷が高くなる原因として、プライマリエンドポイントへの直接接続、プライマリノードによる読み取りリクエストの受け入れ、大量のトランザクションリクエスト、高いレプリケーションレイテンシーによるプライマリノードへのリクエストルーティング、読み取り専用ノードの障害によるプライマリノードへの読み取りリクエストのルーティングなどが挙げられます。
プライマリノードの負荷が低くなるのは、プライマリノードで読み取りリクエストを受け入れるオプションが無効になっている場合に発生することがあります。
Q: プライマリノードの負荷を軽減するにはどうすればよいですか?
A: 次の方法で、プライマリノードの負荷を軽減できます。
クラスターエンドポイントを使用してPolarDB クラスターに接続します。 詳細については、「データベースプロキシを設定する」、「」、または「」をご参照ください。
大量のトランザクションがプライマリノードに高い負荷をかけている場合、コンソールでトランザクション分離機能を有効にして、トランザクション内の一部のクエリを読み取り専用ノードにルーティングできます。詳細については、「トランザクション分離」、、または をご参照ください。
レプリケーションレイテンシーが高いためにリクエストがプライマリノードにルーティングされる場合、結果整合性を使用するなど、整合性レベルを下げることを検討してください。詳細については、「整合性レベル」、、または をご参照ください。
プライマリノードが読み取りリクエストを受け入れる場合も、高い負荷につながる可能性があります。コンソールでプライマリノードによる読み取りリクエストを無効にすることで、プライマリノードへルーティングされる読み取りリクエストの数を減らすことができます。詳細については、「プライマリノードが読み取りリクエストを受け入れる」をご参照ください。
Q: データを挿入した直後にデータを読み取れないのはなぜですか?
A: この問題は、一貫性レベルの設定が原因である可能性があります。PolarDB クラスターのクラスターエンドポイントは、以下の一貫性レベルをサポートしています:
結果整合性：このレベルでは、同一セッション (接続) からか、別セッションからかにかかわらず、新しく挿入されたデータをすぐに読み取れる保証はありません。
セッション整合性：このレベルでは、同一セッション内で挿入されたデータを読み取れることが保証されます。
グローバル整合性：このレベルでは、同一セッションと別セッションの両方から最新のデータを読み取れることが保証されます。
説明整合性レベルが高いほど、パフォーマンスが低下し、プライマリノードへの負荷が大きくなります。整合性レベルは慎重に選択してください。ほとんどのアプリケーションシナリオでは、セッション整合性で通常の業務運用を確保するのに十分です。強い整合性が必要な一部の SQL ステートメントについては、
/*FORCE_MASTER*/ヒントを使用できます。詳細については、「整合性レベル」、、または をご参照ください。Q: SQL ステートメントをプライマリノードで強制的に実行するにはどうすればよいですか?
A: クラスターエンドポイントを使用する場合、SQL ステートメントの前に
/*FORCE_MASTER*/または/*FORCE_SLAVE*/を付加して、そのルーティング方向を指定できます。詳細については、「ヒント構文」、、または をご参照ください。/*FORCE_MASTER*/ヒントは、リクエストをプライマリノードに強制的にルーティングします。これは、より高いレベルの整合性が必要な読み取りリクエストに使用できます。/*FORCE_SLAVE*/ヒントは、リクエストを読み取り専用ノードに強制的にルーティングします。 これは、ストアドプロシージャの呼び出しやマルチステートメントの使用など、正確性を確保するために PolarDB プロキシがデフォルトで特別な構文をプライマリノードにルーティングするシナリオで使用できます。
説明ヒントはルーティングの優先度が最も高く、整合性レベルやトランザクション分離の影響を受けません。使用する前に、考えられる影響を評価してください。
ヒントとともに GUC パラメータを変更する SQL ステートメント (例: /*FORCE_SLAVE*/ SET enable_hashjoin = off;) は使用しないでください。このような SQL ステートメントは、予期しないクエリ結果につながる可能性があります。
Q: 異なるサービスに異なるエンドポイントを割り当てることはできますか? また、これらのエンドポイントでサービス間を分離できますか?
A: はい、サービスごとに異なるカスタムエンドポイントを作成できます。これらのエンドポイントが異なる基盤ノードを使用している場合、サービスは分離され、相互に影響を与えません。カスタムエンドポイントの作成方法については、「カスタムクラスターエンドポイントの作成」、、または をご参照ください。
Q: 複数の読み取り専用ノードがある場合に、特定の1ノードに対して専用の単一ノードエンドポイントを作成するにはどうすればよいですか?
A: 単一ノードエンドポイントを作成できるのは、クラスターエンドポイントの読み書きモードが読み取り専用に設定されており、かつクラスターに 3 つ以上のノードがある場合のみです。詳細な手順については、「クラスターエンドポイントの設定」、、または をご参照ください。
警告単一ノードエンドポイントを作成した後、ノードに障害が発生すると、エンドポイントが最大 1 時間使用できなくなる可能性があります。本番環境では単一ノードエンドポイントを使用しないでください。
Q: クラスターで作成できる単一ノードエンドポイントの最大数はいくつですか?
A: クラスターに 3 つのノードがある場合、1 つの読み取り専用ノードに対してのみ単一ノードエンドポイントを作成できます。クラスターに 4 つのノードがある場合、2 つの読み取り専用ノードに対して個別の単一ノードエンドポイントを作成できます。以降もノード数の増加に伴い、同様です。
Q: プライマリエンドポイントのみを使用していますが、読み取り専用ノードに負荷がかかっています。プライマリエンドポイントも読み書き分離をサポートしていますか?
A: いいえ、プライマリエンドポイントは読み書き分離をサポートしておらず、常にプライマリノードにのみ接続します。読み取り専用ノードでわずかな QPS が観測されるのは正常な動作であり、プライマリエンドポイントとは関係ありません。
管理とメンテナンス
Q：フィールドとインデックスをオンラインで追加するにはどうすればよいですか？
A：ネイティブのオンライン DDL、または pt-online-schema-change や gh-ost などのツールを使用できます。ネイティブのオンライン DDL の使用を推奨します。
説明pt-online-schema-change を使用する場合、
recursion-methodパラメーターなど、マスター/スレーブ検出に関連するパラメーターは使用しないでください。これは、ツールが binlog レプリケーションに基づいてマスター/スレーブ検出を実行するためです。しかし、PolarDB は物理レプリケーションを使用しており、binlog ベースのレプリケーション情報はありません。Q：一括挿入機能はサポートされていますか？
A：はい。
Q：プライマリノードにのみデータを書き込む場合でも一括挿入はサポートされますか？ 1 回に挿入できる値の最大数はいくつですか？
A：はい、サポートしています。1 回に挿入できる値の最大数は、 max_allowed_packet パラメーターの値によって決まります。詳細については、「Replication and max_allowed_packet」をご参照ください。
Q：クラスターエンドポイント経由で一括挿入操作を実行できますか？
A：はい。
Q：プライマリノードと読み取り専用ノードの間にレプリケーションの遅延はありますか？
A：はい。ミリ秒レベルの遅延があります。
Q：レプリケーションの遅延が増加する原因は何ですか？
A：レプリケーションの遅延は、次の状況で増加する可能性があります。
プライマリノードの書き込み負荷が高い場合、過剰な REDO ログが生成され、読み取り専用ノードで適用が間に合わなくなります。
読み取り専用ノードの負荷が高い場合、REDO ログの適用に必要なリソースが消費されます。
I/O ボトルネックが発生し、REDO ログの読み書き処理が遅くなります。
Q：レプリケーションの遅延がある場合、クエリの整合性をどのように確保すればよいですか？
A：クラスターエンドポイントを使用し、適切な整合性レベルを選択してください。使用可能な整合性レベルは、高い順に、 グローバル整合性 (強い整合性)、セッション整合性、結果整合性です。詳細については、「Consistency levels」、「」、または「」をご参照ください。
Q：単一ノード障害が発生した場合、目標復旧時点 (RPO) を 0 にすることは保証されますか？
A：はい。
Q：仕様のアップグレード (例：2 コア、8 GB のメモリから 4 コア、16 GB のメモリへ) はバックエンドでどのように実行されますか？ サービスへの影響はありますか？
A： PolarDB は、サービスへの影響を最小限に抑えるために、プロキシノードとデータベースノードの両方でローリングアップグレードを実行します。アップグレードは通常 10～15 分で完了し、サービスへの影響は 30 秒以内です。この期間中に、1～3 回の一時的な接続エラーが発生する場合があります。詳細については、「Manual scaling」、「」、または「」をご参照ください。
Q：ノードの追加にはどのくらい時間がかかりますか？ サービスに影響はありますか？
A：ノードの追加には約 5 分かかり、サービスには影響しません。ノードの追加方法については、「Add a node」、「」、または「」をご参照ください。
説明読み取り専用ノードを追加すると、新しい読み書き分離接続はそのノードにリクエストを転送します。ノード追加前に確立された読み書き分離接続は、新しいノードにリクエストを転送しません。アプリケーションを再起動するなどして、いったん切断してから再接続してください。
Q：最新のリビジョンバージョンへのアップグレードにはどのくらい時間がかかりますか？ サービスに影響はありますか？
A： PolarDB は、サービスへの影響を最小限に抑えるために、複数ノードにまたがるローリングアップグレード方式を採用しています。バージョンアップグレードは通常 30 分以内で完了します。アップグレード中は、データベースプロキシまたは DB カーネルエンジンが再起動されるため、一時的な接続エラーが発生する場合があります。オフピーク時間帯にアップグレードを実施し、アプリケーションに自動再接続の仕組みがあることを確認してください。詳細については、「Minor version management」、「」、または「」をご参照ください。
Q：自動フェイルオーバーはどのように動作しますか？
A： PolarDB は Active-Active の高可用性クラスターアーキテクチャを採用しています。自動フェイルオーバーは、読み書きプライマリノードと読み取り専用ノードの間で発生します。システムは新しいプライマリノードを自動的に選出します。 PolarDB クラスター内の各ノードにはフェイルオーバー優先度が設定されており、フェイルオーバー時に新しいプライマリノードとして選出される確率がこの優先度によって決まります。複数のノードの優先度が同じ場合、それらが選出される確率も同じになります。詳細については、「Automatic and manual primary/standby node switchover」、「」、または「」をご参照ください。
Q： PolarDB for MySQL クラスターで接続を終了するには、どの権限が必要ですか？
A：MySQL では、
KILLコマンドを使用して接続を終了するには、特定の権限が必要です。具体的には、別の一般ユーザーの接続を終了するには、PROCESS権限が必要です。説明自身の接続を終了する：追加の権限なしで、どのユーザーでも自身の接続を終了できます。
同一ユーザーの他のセッションを終了する：
PROCESS権限が必要です。別の一般ユーザーの接続を終了する： PolarDB for MySQL では、高権限アカウントは
KILLコマンドを慎重に使用してください。
Q：実行ログに
[ERROR] InnoDB: fil_space_extend space_name:xxxエラーが表示されます。現在のサービスに影響はありますか？A：いいえ。サービスに影響はありません。このログは、PolarDB クラスターの読み書きノードでファイルサイズが拡張された後に、読み取り専用ノードがメモリ内のファイルサイズ情報を同期していることを示しています。MySQL 5.7 を実行するクラスターでは、このメッセージのログレベルが調整されておらず、
ERRORのままです。読み取り専用ノードでは、このメッセージをINFOレベルのメッセージとして扱って問題ありません。サービスに影響はありません。Q：データベースプロキシのアーキテクチャはどのようになっていますか？ フェイルオーバーの仕組みはありますか？ 高可用性はどのように確保されますか？
A：データベースプロキシは、2 ノードの高可用性アーキテクチャを採用しており、2 つのプロキシノードにトラフィックを均等に分散します。システムはプロキシノードの健全性を継続的にチェックします。ノード障害を検知すると、システムはそのノード上の接続を能動的に切断し、残りの正常なノードがすべてのトラフィックを自動的に引き継いで、サービスの継続性を確保します。同時に、システムは障害が発生したプロキシノードを自動的に再構築し、復旧させます。このプロセスは通常約 2 分で完了します。この間も、データベースクラスターにはアクセスできます。
まれに、障害が発生したノードへの接続が適時に切断されず、応答しなくなる場合があります。このような状況に備えて、JDBC の
socketTimeoutやconnectTimeoutなど、クライアント側で適切なタイムアウトポリシーを設定してください。これにより、アプリケーション層が停止した接続を迅速に検知して終了でき、システムの耐障害性と応答効率をさらに向上させることができます。Q：PolarDB for MySQL クラスターのエラーログを表示するにはどうすればよいですか？
A： PolarDB console に移動します。クラスター詳細ページで、左側メニューから を選択します。[Running Logs] タブで、エラーログを確認できます。
Q： PolarDB for MySQL は、主キーのないテーブルに対して暗黙の主キーを自動的に作成しますか？
A：はい。デフォルトでは、 PolarDB for MySQL は主キーのないすべてのテーブルに暗黙の主キーを作成します。
暗黙の主キーの表示
クラスターにログインして、
SET show_ipk_info = 1を実行します。その後、SHOW CREATE TABLEコマンドを実行して、キーを確認できます。-- 暗黙の主キーを表示するようにパラメーターを設定します。 SET show_ipk_info = 1; -- テーブルスキーマを表示します。 SHOW CREATE TABLE t;テーブルスキーマを表示します。
__#alibaba_rds_row_id#__列が暗黙の主キーです。+-------+------------------------------------------------------------------------------------------------------------+ | Table | Create Table | +-------+------------------------------------------------------------------------------------------------------------+ | t | CREATE TABLE `t` ( `id` int(11) DEFAULT NULL, `__#alibaba_rds_row_id#__` bigint(20) NOT NULL AUTO_INCREMENT COMMENT 'Implicit Primary Key by RDS', KEY `__#alibaba_rds_row_id#__` (`__#alibaba_rds_row_id#__`) ) ENGINE=InnoDB DEFAULT CHARSET=utf8 | +-------+------------------------------------------------------------------------------------------------------------+Q：
Lock wait timeout exceededエラーが表示され、trx_mysql_thread_idが 0 のトランザクションが見つかるのはなぜですか？A：アプリケーションが PolarDB for MySQL と連携する際に、ロック競合によってサービス中断が発生し、データベース内で
trx_mysql_thread_idが 0 のトランザクションが確認された場合、通常は未完了の XA トランザクションがロックを保持していることを意味します。このセクションでは、この問題の解決方法を説明します。症状
アプリケーションまたはクライアントが、データベースへの接続時に
ERROR 1205 (HY000): Lock wait timeout exceeded; try restarting transactionエラーを受け取ります。データベースにログインして
SELECT * FROM information_schema.innodb_trx;を実行すると、出力内に、trx_mysql_thread_idフィールドの値が0の長時間実行中トランザクションが見つかります。このトランザクションが他のトランザクションをブロックしています。
MySQL xxx > select * from information_schema.innodb_trx\G *************************** 1. row *************************** trx_id: 3317965 trx_state: RUNNING trx_started: 2025-12-23 11:29:17 trx_requested_lock_id: NULL trx_wait_started: NULL trx_weight: 3 trx_mysql_thread_id: 0 trx_query: NULL原因
InnoDB ストレージエンジンでは、
trx_mysql_thread_idが0であることは XA トランザクションの指標です。この問題は通常、XA トランザクションの 2フェーズコミットのプロセス中に発生します。トランザクションがXA PREPAREを正常に実行してプリペア状態に入った後、外部トランザクションコーディネーターがネットワークの問題、アプリケーション例外、またはその他の理由によりXA COMMITまたはXA ROLLBACKコマンドを発行できない場合、トランザクションはプリペア状態でスタックします。スタックしたトランザクションはロックを保持し続けるため、他のトランザクションをブロックし、最終的にロック待機タイムアウトが発生します。ソリューション
ビジネス要件に基づき、プリペア状態の XA トランザクションをコミットまたはロールバックするために手動で介入する必要があります。
未コミットの XA トランザクションを特定する：
XA RECOVER;コマンドを実行して、未コミットの XA トランザクションを照会します。対象トランザクションのformatID、gtrid_length、bqual_length、dataフィールドの値を記録します。これらの情報は、次の手順で必要になります。MySQL [xxx]> xa recover; +----------+---------------+--------------+----------------------------+ | formatID | gtrid_length | bqual_length | data | +----------+---------------+--------------+----------------------------+ | 10000 | 11 | 14 | 192.168.1.2_app_name_test | +----------+---------------+--------------+----------------------------+XA トランザクションを手動でコミットまたはロールバックする： XA トランザクションが特定できたら、ビジネス要件に基づいて、コミットするかロールバックするかを選択します。
XA トランザクションの一意の識別子 (
xid) の取得：xidは、gtrid、bqual、およびformatIDの 3 つの部分で構成されます。 前のステップで取得した情報に基づいてxidを構築する必要があります。gtrid：gtrid_lengthで指定された長さの文字列で、dataフィールドの先頭から抽出します。bqual：bqual_lengthで指定された長さの文字列で、dataフィールドの末尾から抽出します。formatID：formatIDフィールドの値です。
前の手順の例に基づいて、
xidの 3 つのパートを構成できます。SUBSTRINGを使用してdataフィールドを分割できます。SELECT SUBSTRING('192.168.1.2_app_name_test',1,11) AS gtrid, SUBSTRING('192.168.1.2_app_name_test',-14) AS bqual; +-------------+----------------+ | gtrid | bqual | +-------------+----------------+ | 192.168.1.2 | _app_name_test | +-------------+----------------+gtrid：'192.168.1.2'bqual：'_app_name_test'formatID：10000
XA トランザクションをコミットまたはロールバックする： XA トランザクションを手動でコミットまたはロールバックすると、トランザクションコーディネーターの本来の意図と異なる最終状態になる可能性があり、データ不整合を引き起こすおそれがあります。次のコマンドを実行する前に、トランザクションのビジネスコンテキストを十分に理解し、実行しても安全であることを確認してください。
コミット： トランザクションをコミットすべきと判断した場合は、次のコマンドを実行します。
XA COMMIT '192.168.1.2', '_app_name_test', 10000;ロールバック： トランザクションをロールバックすべきと判断した場合は、次のコマンドを実行します。
XA ROLLBACK '192.168.1.2', '_app_name_test', 10000;
コマンドが正常に実行されると、未コミットの XA トランザクションが保持していたロックが解放され、データベースサービスは正常な状態に戻ります。
XA トランザクション構文の詳細については、「official MySQL documentation on XA Transactions」をご参照ください。
PolarDB for MySQL 8.0 クラスターで、無効な日付型および時刻型を比較した際のエラー処理の動作に一貫性がないのはなぜですか？
問題の説明： PolarDB for MySQL 8.0 クラスターには、 MySQL 8.0.1 と MySQL 8.0.2 の 2 つのバージョンがあり、それぞれ MySQL 8.0.13 と MySQL 8.0.18 と完全に互換性があります。ただし、これら 2 つのバージョンでは、無効な日付型および時刻型の扱いが一貫していません。
具体的には、文字列リテラルを時刻型の値と比較すると、文字列を時刻型に変換しようとします。文字列が無効な日付である場合、変換に失敗します。変換失敗時の動作は、2 つのバージョンで異なります。MySQL 8.0.13 互換バージョンでは
WARNINGのみが発行されますが、MySQL 8.0.18 互換バージョンではER_WRONG_VALUEエラーが返されます。その結果、無効な日付と時刻フィールドを比較した場合、これら 2 つの PolarDB for MySQL 8.0 クラスターでは、エラー報告の動作に一貫性がありません。ソリューション： SQL の実行結果を一貫させる (すべて成功またはすべて失敗) には、複数の PolarDB for MySQL クラスターで同じメジャーカーネルバージョンを使用してください。具体的には、すべて MySQL 8.0.1 またはすべて MySQL 8.0.2 を使用します。
バックアップと復元
Q：PolarDB はどのようにデータをバックアップしますか？
A: PolarDB はスナップショットを使用してデータをバックアップします。 詳細については、「バックアップ方法 1: 自動バックアップ」および「バックアップ方法 2: 手動バックアップ」、「」、または「」をご参照ください。
Q：データベースはどのくらいの速さで復元できますか？
A：バックアップ セット (スナップショット) からデータベースを復元する場合、またはデータベースのクローンを作成する場合は、1 TB あたり約 40 分かかります。特定の時点にデータを復元する場合、redo ログを適用するために必要な時間も含まれます。redo ログの適用には、1 GB あたり約 20〜70 秒かかります。合計復元時間は、この 2 つを合計した時間です。
パフォーマンスと容量
Q: PolarDB for MySQL のパフォーマンスが ApsaraDB RDS for MySQL よりも大幅に優れていないのはなぜですか？
A: PolarDB for MySQL と ApsaraDB RDS for MySQL の正確なパフォーマンス比較を行うには、以下の点を考慮してください。
同じ仕様の PolarDB for MySQL クラスターと ApsaraDB RDS for MySQL インスタンスを使用します。
同じ MySQL バージョンの PolarDB for MySQL クラスターと ApsaraDB RDS for MySQL インスタンスを使用します。
実装メカニズムはバージョンによって異なります。 たとえば、MySQL 8.0 は、Log_writer、log_fluser、log_checkpoint、log_write_notifier のような抽象化されたスレッドでマルチコア CPU 向けに最適化されています。 しかし、CPU コア数が少ないシステムでは、そのパフォーマンスは MySQL 5.6 または 5.7 よりも低くなります。 MySQL 5.6 のオプティマイザは新しいバージョンのものよりも古く、効率が低いため、PolarDB for MySQL 5.6 と ApsaraDB RDS for MySQL 5.7 または 8.0 を比較することはお勧めしません。
現実的なパフォーマンス比較のために、オンライン負荷シナリオをシミュレートするか、
sysbenchを使用してテストしてください。これらの方法で得られるデータは、実際のオンラインシナリオに近いものになります。読み取りパフォーマンスを比較する場合、単一の SQL ステートメントを使用することは推奨しません。
PolarDB は、コンピューティングとストレージを分離したアーキテクチャを採用しているため、単一のステートメントはネットワークレイテンシーの影響を受け、ApsaraDB RDS for MySQL と比較して読み取りパフォーマンスが低下する可能性があります。 オンラインデータベースでは、キャッシュヒット率は通常 99% を超えます。 読み取りパフォーマンスを低下させる I/O コールは、最初の読み取り操作でのみ発生します。 後続のデータは、I/O コールを必要としないバッファプールから取得されます。 したがって、パフォーマンスは同じです。
書き込みパフォーマンスを比較する場合も、単一の SQL ステートメントを使用することは推奨しません。ストレステストのために、オンライン環境をシミュレートすることを推奨します。
ApsaraDB RDS for MySQL とのパフォーマンスを比較するには、プライマリノードと読み取り専用ノードで構成される PolarDB クラスターと、プライマリインスタンスと準同期読み取り専用インスタンスを持つ ApsaraDB RDS for MySQL インスタンスを比較します。これは、PolarDB アーキテクチャがデフォルトでデータ書き込みにクォーラムメカニズムを使用するためです。つまり、書き込み操作は、3 つのレプリカの過半数 (2 つ以上) に書き込まれた場合に成功したと見なされます。PolarDB は、ストレージレイヤーでデータ冗長性を提供し、3 つのレプリカで強力な一貫性と高い信頼性を保証します。したがって、より合理的な比較を行うには、非同期レプリケーションではなく、ApsaraDB RDS for MySQL で準同期レプリケーションを使用します。
PolarDB for MySQL と ApsaraDB RDS for MySQL のパフォーマンス比較については、「PolarDB for MySQL と ApsaraDB RDS for MySQL のパフォーマンス比較」をご参照ください。
Q：テーブルの最大数はいくつですか? どの時点でパフォーマンスが低下する可能性がありますか?
A：テーブルの最大数は、ファイル数によって制限されます。詳細については、「制限」、「」、または「」をご参照ください。
Q. テーブルパーティショニングによってPolarDB のクエリパフォーマンスは向上しますか？
A：はい、一般的に向上します。クエリを特定のパーティションに絞り込める場合、パフォーマンスを向上させることができます。
Q: PolarDB クラスターに 10,000 個のデータベースを作成できますか？データベースの最大数はいくつですか？
A: はい、PolarDB クラスターに 10,000 個のデータベースを作成できます。データベースの最大数は、ファイル数によって制限されます。詳細については「制限事項」、「」、または「」をご参照ください。
Q：最大接続数は、読み取り専用ノードの数に関連していますか? 読み取り専用ノードを追加することで、最大接続数を増やすことができますか?
A: いいえ、読み取り専用ノードの数は最大接続数とは関係ありません。PolarDB の最大接続数は、ノード仕様によって決まります。詳細については、「制限」をご参照ください。より多くの接続が必要な場合は、仕様をアップグレードする必要があります。
Q: IOPS はどのように制限および分離されますか？ 複数の PolarDB クラスターノード間で I/O 競合は発生しますか？
A: PolarDB クラスターでは、各ノードに仕様に応じた IOPS の上限があります。各ノードの IOPS は分離されており、他のノードに影響を与えません。
Q：読み取り専用ノードのパフォーマンス低下は、プライマリノードに影響を与える可能性がありますか?
A：はい。読み取り専用ノードの負荷が高くなったり、レプリケーション遅延が増加したりした場合、プライマリノードのメモリ消費量がわずかに増加する可能性があります。
Q：
binlogを有効にすると、パフォーマンスにどのような影響がありますか?A：
binlogを有効にしても、クエリ (SELECT) のパフォーマンスには影響しませんが、書き込み操作 (INSERT、UPDATE、DELETE) には影響します。読み書きのワークロードのバランスが取れているデータベースでは、binlogを有効にすると、通常、パフォーマンスへの影響は 10% 未満です。Q：
SQL Explorerを有効にすると、パフォーマンスにどのような影響がありますか?A：パフォーマンスへの影響はありません。
Q: PolarDB はどの高速ネットワークプロトコルを使用していますか？
A: PolarDB は、コンピュートノードとストレージノード間、およびストレージデータレプリカ間の通信に、デュアル 25 Gbps RDMA 技術を使用します。これにより、低レイテンシー・高スループットで強力な I/O パフォーマンスを提供します。
Q: PolarDB への外部接続の最大帯域幅はどのくらいですか？
A: PolarDB への外部接続の最大帯域幅は 10 Gbit/s です。
大規模テーブル
Q：ローカルディスクを使用する従来のデータベースと比較して、 PolarDB for MySQL に大規模テーブルを保存する利点は何ですか？
A： PolarDB for MySQL では、単一テーブルが物理的に分割され、複数のストレージサーバーに保存されます。その結果、テーブルに対する I/O 操作は複数のストレージディスクに分散されます。I/O レイテンシは別として、全体の I/O 読み取りスループットは、ローカルディスクを使用する集中型データベースより大幅に優れています。
Q：大規模テーブルを最適化するにはどうすればよいですか？
A：パーティションテーブルの使用を推奨します。
Q：パーティションテーブルはどのような場合に適していますか？
A：パーティションテーブルは、クエリでアクセスするデータ量を制御するために大規模テーブルのプルーニングが必要で、かつそのプルーニングをビジネスコードを変更せずに透過的に実行したい、といったシナリオに適しています。たとえば、パーティションテーブルを使用して、業務履歴データを定期的にクリーンアップできます。具体的には、最も古い月のパーティションを削除し、翌月用に新しいパーティションを作成することで、直近 6 か月分のデータのみを保持できます。
Q：同一の PolarDB for MySQL データベース内で、非常に大きなテーブル (例：テーブル A をテーブル B にコピー) をコピーする最適な方法は何ですか？
A：次の SQL ステートメントを使用して、テーブルを直接コピーできます。
CREATE TABLE B AS SELECT * FROM A;
安定性
Q：高同時実行シナリオで PHP の短時間の接続を最適化できますか？
A：はい。クラスターエンドポイントの設定でセッションレベル接続プールを有効にすることで最適化できます。詳細については、「クラスターエンドポイントの設定」、「」、または「」をご参照ください。
Q：一部の非効率な SQL クエリによる、データベース全体のパフォーマンス低下を防ぐにはどうすればよいですか？
A：お使いの PolarDB for MySQL クラスターがバージョン 5.6 または 8.0 の場合、同時実行制御機能を使用して、特定のステートメントにレート制限を適用できます。
Q：PolarDB はアイドルセッションタイムアウトをサポートしていますか？
A：はい。wait_timeout パラメーターを変更することで、アイドルセッションのタイムアウトをカスタマイズできます。詳細な手順については、「クラスターとノードのパラメーターの指定」をご参照ください。
Q：スロークエリを見つけるにはどうすればよいですか？
A：次の 2 つの方法でスロークエリを見つけることができます。
コンソールで直接スロークエリログを照会します。詳細については、「スロークエリ」をご参照ください。
データベースクラスターに接続し、
SHOW PROCESSLIST;を実行して、実行に時間がかかりすぎているクエリを特定します。データベースクラスターへの接続方法の詳細については、「データベースクラスターへの接続」をご参照ください。SHOW PROCESSLISTコマンドを実行して、現在のプロセスリストを表示します。この例では、ID 33554499 のクエリSELECT SLEEP(600)は 250 秒間実行されているスロークエリです。mysql> show processlist; +----------+------+-------------------------------+------+---------+------+------------+--------------------+ | Id | User | Host | db | Command | Time | State | Info | +----------+------+-------------------------------+------+---------+------+------------+--------------------+ | 33554490 | acc | xxx:19358 | NULL | Query | 0 | starting | show processlist | | 33554499 | acc | xxx | NULL | Query | 250 | User sleep | select sleep(600) | | 33554501 | acc | xxx | NULL | Sleep | 253 | | NULL | +----------+------+-------------------------------+------+---------+------+------------+--------------------+ 3 rows in set, 13312 warnings (0.00 sec)
Q：スロークエリを終了させるにはどうすればよいですか？
A：スロークエリを特定したら、その ID を見つけて
KILL <Id>を実行して終了させることができます。mysql> KILL 33554499; Query OK, 0 rows affected (0.01 sec)
データライフサイクル管理
Q：PolarDB for MySQL クラスターは、ホットデータとウォームデータをコールドデータとしてどのようにアーカイブしますか？
A：PolarDB for MySQL クラスターは、DDL ポリシーを使用して、PolarStore にある InnoDB ストレージエンジンのホットデータと X-Engine のウォームデータを、CSV または ORC フォーマットのコールドデータとして Object Storage Service (OSS) にアーカイブできます。このアーカイブにより、PolarStore 上のストレージ領域を効果的に解放し、データベース全体のストレージコストを削減できます。詳細については、「Manually archive cold data」をご参照ください。
Q：PolarDB for MySQL クラスターは、ホットデータ、ウォームデータ、コールドデータの自動分離とアーカイブをサポートしていますか？ また、どのように実装しますか？
A：PolarDB for MySQL は、ホットデータ、ウォームデータ、コールドデータの自動分離とアーカイブをサポートしています。DLM ポリシーを指定することで、PolarStore から低コストの OSS ストレージにデータを自動的にアーカイブし、データベースのストレージコストを削減および最適化できます。詳細については、「Automatically archive cold data」をご参照ください。