このトピックでは、PolarDB for MySQL に関するよくある質問とその回答をまとめています。
基本的な質問
Q: PolarDB とは何ですか？
A: PolarDB は、クラウドベースのリレーショナルデータベースサービスです。世界中の 10 以上の Alibaba Cloud リージョンにデプロイされており、すぐに利用可能なオンラインデータベースサービスを提供します。PolarDB は、MySQL と完全互換、PostgreSQL と完全互換、Oracle 構文と高度に互換の 3 つの独立したエンジンをサポートしています。最大ストレージ容量は 200 TB です。詳細については、「PolarDB for MySQL Enterprise Edition とは？」をご参照ください。
Q: クラウドネイティブデータベースである PolarDB は、従来のデータベースと比べてどのような点で優れていますか？
A: 従来のデータベースと比較して、PolarDB は数百 TB スケールの大規模データストレージをサポートします。また、高い可用性および信頼性、迅速なエラスティックスケーリング、ロックフリーバックアップを実現します。詳細については、「主な特徴」をご参照ください。
Q: PolarDB はいつリリースされ、商用利用可能になりましたか？
A: PolarDB は 2017 年 9 月にパブリックプレビューを開始し、2018 年 3 月に商用利用が開始されました。
Q: クラスターとノードとは何ですか？
A: PolarDBクラスターエディション は、マルチノードクラスターアーキテクチャを採用しています。各クラスターには 1 つのプライマリノードと複数の読み取り専用ノードがあります。PolarDB クラスターは、ゾーン間デプロイメントをサポートしますが、リージョン間デプロイメントはサポートしません。クラスターは単位として管理および課金されます。詳細については、「用語集」をご参照ください。
Q: サポートしているプログラミング言語は何ですか？
A： PolarDB は、Java、Python、PHP、Golang、C、C++、.NET、および Node.js をサポートしています。 MySQL のネイティブ機能をサポートするプログラミング言語であれば、PolarDB for MySQL を直接使用できます。詳細については、「MySQL ウェブサイト」をご参照ください。
Q: システムがサポートするストレージエンジンは何ですか？
A: PolarDB は 2 つの製品シリーズをサポートしています。サポートされるストレージエンジンはシリーズによって異なります。
PolarDB for MySQLクラスターエディション のすべてのテーブルは InnoDB ストレージエンジンを使用します。テーブルを作成する際、PolarDB for MySQL は MyISAM、Memory、CSV などの非 InnoDB エンジンを自動的に InnoDB に変換します。そのため、ソーステーブルが他のエンジンを使用していても、PolarDB for MySQL への移行は正常に完了します。
Q: PolarDB は分散データベースですか？
A: はい。PolarDB は Parallel Raft 一貫性プロトコルに基づく分散ストレージクラスターです。コンピュートエンジンは、異なるサーバーに分散配置された 1～16 個のコンピュートノードで構成されます。最大ストレージ容量は 200 TB、最大構成は 88 vCPU および 710 GB のメモリをサポートします。ストレージおよびコンピュートリソースは、ビジネス運用に影響を与えることなく、オンラインかつ動的にスケールできます。
Q: PolarDB を購入した後、データベースおよびテーブルのシャーディングを行うために、PolarDB-X データベースミドルウェアを別途購入する必要がありますか？
A: はい。
Q: PolarDB はテーブルパーティショニングをサポートしていますか？
A: はい。
Q: PolarDB クラスターを購入した後、リージョンを変更できますか？
A: いいえ。クラスターを購入した後は、リージョンを変更できません。
Q: PolarDB には組み込みのパーティショニング機能がありますか？
A: PolarDB はストレージ層でデータをパーティショニングします。これはユーザーに対して透明であり、特別な操作は必要ありません。
Q: シングルノード シリーズは、サービスの可用性およびデータの信頼性をどのように確保していますか？
A: シングルノードシリーズは、単一のコンピューティングノードに基づく専用のデータベースプロダクトです。使用するノードは 1 つだけですが、シングルノードシリーズは、サブセカンドのコンピューティングスケジューリングや分散マルチレプリカストレージなどのテクノロジーを使用することで、高いサービスの可用性と高いデータ信頼性を確保します。
Q: PolarDB クラスターをシングルノードモードで購入するにはどうすればよいですか？
A: 現在、シングルノード製品シリーズは提供されていませんが、クラスター購入時に読み取り専用ノード数を 0 に設定することで、シングルノード PolarDB クラスターを購入できます。
互換性
Q: PolarDB for MySQL はコミュニティ版 MySQL と互換がありますか？
A: PolarDB for MySQL はコミュニティ版 MySQL と 100 % 互換です。
Q: PolarDB for MySQL はどのトランザクション分離レベルをサポートしていますか？
A: PolarDB for MySQL は READ_UNCOMMITTED、READ_COMMITTED（デフォルト）、REPEATABLE_READ をサポートしています。SERIALIZABLE はサポートしていません。
Q: SHOW PROCESSLIST はコミュニティ版 MySQL と異なりますか？
A: プライマリエンドポイントを使用してクエリを実行する場合は、違いはありません。クラスターエンドポイントを使用する場合、結果がわずかに異なることがあります。同じスレッド ID を持つ複数の行が表示され、それぞれが PolarDB for MySQL クラスター内のノードに対応します。
Q: PolarDB for MySQL のメタデータロック（MDL）機構は、コミュニティ版 MySQL と異なりますか？
A: PolarDB for MySQL の MDL 機構はコミュニティ版 MySQL と一致しています。ただし、PolarDB for MySQL は共有ストレージを使用するため、プライマリノードでの DDL 操作中に読み取り専用ノードが中間データにアクセスすると、データ不整合が発生する可能性があります。これを防ぐため、PolarDB for MySQL は DDL 操作に関連する排他的 MDL ロックを、redo ログ経由で読み取り専用ノードに同期します。これにより、DDL 操作中の読み取り専用ノード上の他のユーザースレッドによるテーブルデータへのアクセスがブロックされます。場合によっては、DDL 操作自体がブロックされることがあります。
show processlistコマンドを実行して DDL 実行ステータスを確認してください。ステータスがWait for syncing with replicasと表示されている場合は、この問題が発生しています。解決手順については、「DDL 実行ステータスおよび MDL ロックステータスの確認」をご参照ください。Q: Binlog のフォーマットはネイティブ MySQL と異なりますか？
A: いいえ。
Q: PolarDB は performance_schema および sys スキーマをサポートしていますか？
A: はい。
Q: PolarDB for MySQL のテーブル統計情報の収集は、コミュニティ版 MySQL と異なりますか？
A: PolarDB for MySQL のプライマリノードにおけるテーブル統計情報は、コミュニティ版 MySQL と一致します。プライマリノードおよび読み取り専用ノード間で実行計画を一貫させるため、プライマリノードは更新された統計情報を読み取り専用ノードに同期します。読み取り専用ノードは、
ANALYZE TABLEコマンドを使用して、ディスクから最新の統計情報を読み込むこともできます。Q: PolarDB は XA トランザクションをサポートしていますか？また、公式の MySQL と比較して違いはありますか？
A: はい。違いはありません。
Q: PolarDB はフルテキストインデックスをサポートしていますか？
A: はい。
説明フルテキストインデックスを使用する場合、読み取り専用ノードでインデックスキャッシュの遅延がわずかに発生することがあります。最新のデータを確実に読み取るため、すべてのフルテキストインデックスの読み書き操作には、プライマリエンドポイントの使用を推奨します。
Q: PolarDB は Percona Toolkit をサポートしていますか？
A: はい。ただし、オンライン DDL の使用を推奨します。
Q: PolarDB は gh-ost をサポートしていますか？
A: はい。ただし、オンライン DDL の使用を推奨します。
課金
Q: PolarDB の課金項目には何が含まれますか？
A: 課金項目には、ストレージ容量、コンピュートノード、バックアップ（無料クォータあり）、SQL Explorer（オプション）が含まれます。詳細については、「課金項目の概要」をご参照ください。
Q: 課金対象のストレージ容量には何が含まれますか？
A: 課金対象のストレージ容量には、データベーステーブルファイル、インデックスファイル、undo ログファイル、redo ログファイル、Binlog ファイル、スローログファイル、および少数のシステムファイルが含まれます。詳細については、「概要」をご参照ください。
Q: 読み取り専用ノードを追加する場合の料金はいくらですか？
A: 読み取り専用ノードの料金は、プライマリノードと同じです。詳細については、「コンピュートノードの価格詳細」をご参照ください。
Q: 読み取り専用ノードを追加すると、ストレージ容量が倍増しますか？
A: PolarDB はコンピュート・ストレージ分離アーキテクチャを採用しています。読み取り専用ノードはコンピュートリソースのみを追加します。ストレージ容量は増加しません。
ストレージはサーバーレスモデルを採用しており、購入時にストレージサイズを選択する必要はありません。データの増加に応じて、ストレージはオンラインかつ自動的にスケールします。実際に保存されたデータ量のみが課金対象となります。各クラスター仕様には最大ストレージ容量が定義されています。ストレージ制限を拡大するには、クラスター仕様のアップグレードを行ってください。
Q: 従量課金のクラスターについて、今後課金されないようにするにはどうすればよいですか？
A: クラスターが不要になった場合は、クラスターをリリースしてください。リリース後は、以降の課金は発生しません。
Q: 一時的なアップグレード中にクラスターの構成を変更できますか？
A: 一時的なアップグレード中（クラスターのステータスが「実行中」の場合）、手動で仕様をアップグレードできます。ただし、手動でのスペックダウン、自動スケーリング、およびノードの追加または削除はサポートされていません。
Q: PolarDB のインターネット帯域幅はどのくらいですか？ 課金されますか？
A: PolarDB にはインターネット帯域幅の制限はありません。帯域幅は、お客様が使用する SLB サービスに依存します。PolarDB はパブリックネットワーク接続に対して課金しません。
Q: サブスクリプションのクラスターに対して、なぜ毎日課金されるのですか？
A: PolarDB の課金項目には、コンピュートノード（プライマリおよび読み取り専用ノード）、ストレージ容量、データバックアップ（無料クォータを超えた分のみ課金）、SQL Explorer（オプション）、グローバルデータベースネットワーク（GDN）（オプション）が含まれます。詳細については、「課金項目の概要」をご参照ください。サブスクリプションとは、クラスター作成時にコンピュートノードの料金を前払いすることを意味します。ストレージ容量、データバックアップ、SQL Explorer の料金は含まれません。クラスターがストレージ容量を使用すると、アカウントに対して時間単位で課金されます。したがって、サブスクリプション契約であっても、従量課金の請求書を受け取ることがあります。
Q: RDS から PolarDB へのワンクリック移行を利用する場合、追加の料金は発生しますか？
A: ワンクリック移行は無料です。RDS インスタンスおよび PolarDB クラスターの料金のみが発生します。
Q: PolarDB のテーブルデータに対して
DELETEコマンドを実行した後も、なぜストレージ料金が引き続き課金されるのですか？A:
deleteは行を削除対象としてマークするだけで、表領域を解放しません。
クラスターへのアクセス（読み書き分離）
Q: PolarDB の読み書き分離を実装するにはどうすればよいですか？
A: アプリケーションでクラスターエンドポイントを使用します。読み書き分離は、設定された読み書きモードに基づいて自動的に動作します。詳細については、「データベースプロキシの設定」をご参照ください。
Q: PolarDB クラスターは、最大でいくつの読み取り専用ノードをサポートしますか？
A: PolarDB は分散クラスターアーキテクチャを採用しています。各クラスターには 1 つのプライマリノードと、最大 15 個の読み取り専用ノード（高可用性のために最低 1 個必要）があります。
Q: なぜ読み取り専用ノード間の負荷が均等でないのですか？
A: 読み取り専用ノードの一部が接続数が少ない、またはカスタムクラスターエンドポイントで特定の読み取り専用ノードが除外されているため、負荷の不均衡が発生することがあります。
Q: なぜプライマリノードの負荷が高くなったり低くなったりするのですか？
A: プライマリノード（プライマリデータベース）の負荷が高い原因としては、プライマリエンドポイントへの直接接続、プライマリデータベースへの読み取り要求、大量のトランザクショントラフィック、レプリケーションの遅延によるクエリのプライマリノードへのルーティング、読み取り専用ノードの障害による読み取り要求のプライマリノードへのルーティングなどが考えられます。
プライマリノードの負荷が低い原因としては、プライマリデータベースが読み取りを拒否するように設定されていることが挙げられます。
Q: プライマリノードの負荷を軽減するにはどうすればよいですか？
A: 以下のいずれかの方法を使用します。
クラスターエンドポイントを使用して PolarDB クラスターに接続します。詳細については、「データベースプロキシの設定」をご参照ください。
トランザクション量が多くてプライマリノードの負荷が高くなる場合は、コンソールでトランザクション分割を有効化します。これにより、トランザクション内の一部のクエリが読み取り専用ノードにルーティングされます。詳細については、「トランザクション分割」をご参照ください。
レプリケーションの遅延によってクエリがプライマリノードにルーティングされる場合は、整合性レベルを下げます（たとえば、最終的整合性を使用）。詳細については、「整合性レベル」をご参照ください。
読み取り要求の受付もプライマリノードの負荷を高める要因となります。コンソールで「プライマリノードからの読み取りをオフロード」機能を有効化することで、プライマリノードにルーティングされる読み取り要求の数を減らすことができます。詳細については、「プライマリノードからの読み取りをオフロード」をご参照ください。
Q: さ刚刚挿入したデータを読み取ることができません。原因は何ですか？
A: この問題は、整合性レベルの設定が原因である可能性があります。PolarDB クラスターエンドポイントは、以下の整合性レベルをサポートしています。
最終的整合性：同一セッション（接続）内またはセッション間においても、新しく挿入されたデータを即座に読み取ることは保証されません。
セッションの一貫性：同一セッション内で挿入されたデータは、常に読み取ることができます。
グローバル整合性：同一セッションおよびセッション間においても、最新のデータを読み取ることができます。
説明整合性レベルが高いほど、パフォーマンスが低下し、プライマリノードの負荷が高まります。慎重に選択してください。ほとんどのアプリケーションには、セッションの一貫性で十分です。強い整合性が必要なステートメントには、
/* FORCE_MASTER */ヒントを使用します。詳細については、「整合性レベル」をご参照ください。Q: SQL を強制的にプライマリノードで実行するにはどうすればよいですか？
A: クラスターエンドポイントを使用する場合、SQL 文の前に
/* FORCE_MASTER */または/* FORCE_SLAVE */を追加することで、ルーティングを強制できます。詳細については、「ヒント構文」をご参照ください。/* FORCE_MASTER */は、リクエストをプライマリデータベースにルーティングするよう強制します。整合性の高い読み取り要求に使用します。/* FORCE_SLAVE */は、リクエストを読み取り専用ノードにルーティングするよう強制します。ストアドプロシージャの呼び出しやマルチステートメントの使用など、PolarDB プロキシが正しく読み取り専用ノードにルーティングするために特定の構文を必要とするケースで使用します（デフォルトではプライマリノードにルーティングされます）。
説明ヒントは最も高いルーティング優先度を持ち、整合性レベルおよびトランザクション分割の設定を上書きします。適用する前に、その使用を検討してください。
ヒント内に GUC パラメーターの変更コマンドを含めないでください。たとえば、/*FORCE_SLAVE*/ set enable_hashjoin = off; のような記述は避けてください。このようなコマンドは、予期しないクエリ結果を引き起こす可能性があります。
Q: 異なるビジネスアプリケーションに異なるエンドポイントを割り当てることはできますか？ これらのエンドポイントは隔離されますか？
A: 異なるビジネスアプリケーション向けに複数のカスタムエンドポイントを作成できます。基盤となるノードが異なる場合、カスタムエンドポイントは相互に隔離され、影響を及ぼしません。カスタムエンドポイントの作成手順については、「カスタムクラスターエンドポイントの追加」をご参照ください。
Q: 複数の読み取り専用ノードがある場合、特定の読み取り専用ノード向けにシングルノードエンドポイントを作成するにはどうすればよいですか？
A: クラスターエンドポイントの読み書きモードが「読み取り専用」であり、クラスターに 3 つ以上のノードがある場合にのみ、シングルノードエンドポイントを作成できます。詳細な手順については、「クラスターエンドポイントの設定」をご参照ください。
警告シングルノードエンドポイントを作成した後、ノードが障害を起こした場合、最大 1 時間の間、そのエンドポイントが利用不可になる可能性があります。本番環境では使用しないでください。
Q: クラスター内で作成できるシングルノードエンドポイントの数はいくつですか？
A: クラスターに 3 つのノードがある場合、読み取り専用ノードのうち 1 つに対してのみシングルノードエンドポイントを作成できます。クラスターに 4 つのノードがある場合、読み取り専用ノードのうち 2 つに対してシングルノードエンドポイントを作成できます。同様のパターンが続きます。
Q: 私はプライマリエンドポイントのみを使用していますが、読み取り専用ノードに負荷が発生しています。プライマリエンドポイントは読み書き分離をサポートしていますか？
A: プライマリエンドポイントは読み書き分離をサポートしていません。常にプライマリノードに接続します。読み取り専用ノードに小さな QPS が発生するのは正常であり、プライマリエンドポイントとは無関係です。
管理およびメンテナンス
Q: オンラインでカラムおよびインデックスを追加するにはどうすればよいですか？
A: ネイティブのオンライン DDL、pt-osc、gh-ost を使用できます。ネイティブのオンライン DDL の使用を推奨します。
説明pt-osc を使用する場合、
recursion-methodのようなマスタースレーブ検出に関連するパラメーターは使用しないでください。pt-osc は Binlog レプリケーションを使用してマスタースレーブのステータスを検出しますが、PolarDB は内部で物理レプリケーションを使用しており、Binlog ベースのレプリケーション情報を提供していません。Q: PolarDB はバルク挿入をサポートしていますか？
A: はい。
Q: 書き込み専用ノードにのみデータを書き込む場合、PolarDB はバルク挿入をサポートしていますか？ 1 回の INSERT で指定できる値の最大数はいくつですか？
A: はい。1 回の INSERT で指定できる値の最大数は、max_allowed_packet パラメーターによって決定されます。詳細については、「レプリケーションと max_allowed_packet」をご参照ください。
Q: PolarDB はクラスターエンドポイントを使用したバルク挿入をサポートしていますか？
A: はい。
Q: プライマリノード（プライマリ）と読み取り専用ノード（スタンバイ）の間にレプリケーションの遅延は発生しますか？
A: はい。レプリケーションの遅延はミリ秒単位です。
Q: レプリケーションの遅延が増加する原因は何ですか？
A: 以下のケースでレプリケーションの遅延が増加します。
プライマリノードの書き込み負荷が高く、過剰な redo ログが生成され、読み取り専用ノードが処理しきれない場合。
読み取り専用ノードの負荷が高く、redo ログの適用に必要なリソースが消費される場合。
I/O ボトルネックにより、redo ログの読み書きが遅延する場合。
Q: レプリケーションの遅延が存在する場合、クエリの一貫性を確保するにはどうすればよいですか？
A: クラスターエンドポイントを使用し、適切な整合性レベルを選択します。整合性レベルは、最も高いものから順に、グローバル整合性（強い整合性）、セッションの一貫性、最終的整合性です。詳細については、「整合性レベル」をご参照ください。
Q: シングルノード障害発生時に RPO をゼロにすることができますか？
A: はい。
Q: 仕様のアップグレード（たとえば、2 vCPU および 8 GB から 4 vCPU および 16 GB へのアップグレード）は、バックエンドでどのように動作しますか？ ビジネス運用にどのような影響がありますか？
A: PolarDB プロキシおよびデータベースノードの両方が、新しい構成へとアップグレードされます。複数のノードにわたるローリングアップグレードにより、ビジネスへの影響を最小限に抑えます。各アップグレードには約 10～15 分かかります。ビジネスへの影響は最大 30 秒間で、その間に 1～3 回の瞬断が発生する可能性があります。詳細については、「手動で仕様を変更」をご参照ください。
Q: ノードを追加するのにどれくらい時間がかかりますか？ ビジネス運用に影響がありますか？
A: 各ノードの追加には 5 分かかり、ビジネス運用への影響はありません。手順については、「ノードの追加」をご参照ください。
説明読み取り専用ノードを追加した後に作成された新しい読み書き分離接続は、そのノードにリクエストを転送します。既存の読み書き分離接続は、新しいノードにリクエストを転送しません。アプリケーションを再起動するなどして、切断および再接続する必要があります。
Q: 最新のリビジョンへのアップグレードにはどれくらい時間がかかりますか？ ビジネス運用に影響がありますか？
A: PolarDB は複数のノードにわたるローリングアップグレードを使用して、ビジネスへの影響を最小限に抑えます。アップグレードには通常 30 分以内かかります。アップグレード中、データベースプロキシまたはカーネルエンジンが再起動し、瞬断が発生する可能性があります。ピーク時間帯を避け、アプリケーションに自動再接続機能が備わっていることを確認してください。詳細については、「マイナーバージョン管理」をご参照ください。
Q: 自動フェールオーバーはどのように動作しますか？
A: PolarDB はアクティブ/アクティブな高可用性アーキテクチャを使用しています。読み書き可能なプライマリノードと読み取り専用ノード間で自動フェールオーバーが発生します。システムが自動的に新しいプライマリノードを選出します。各 PolarDB ノードにはフェールオーバー優先度があり、それがプライマリノードとして選出される可能性を決定します。優先度が等しい場合、ノードは同等の選出確率を持ちます。詳細については、「プライマリ/スタンバイノードの自動または手動フェールオーバー」をご参照ください。
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 つのプロキシノードに均等に（1:1）分散されます。システムは継続的にプロキシノードの健全性をチェックします。ノードが障害を起こした場合、システムはそのノード上の接続を積極的に切断します。残りの健全なノードがすべてのトラフィックを自動的に処理し、サービスの中断を防ぎます。また、システムは障害を起こしたプロキシノードを自動的に再構築および復元します。このプロセスは通常 2 分以内に完了します。この期間中、データベースクラスターへのアクセスは可能です。
極端なケースでは、障害を起こしたノード上の接続が即座に切断されず、応答しなくなる可能性があります。これを解決するため、クライアント側で適切なタイムアウトポリシー（JDBC の
socketTimeoutおよびconnectTimeoutなど）を設定してください。これにより、アプリケーション層でハング状態の接続を迅速に検出して終了でき、フォールトトレランスおよび応答効率が向上します。Q: PolarDB for MySQL クラスターのエラーログを表示するにはどうすればよいですか？
A: PolarDB コンソール にアクセスします。対象クラスターの詳細ページの左側ナビゲーションウィンドウで、 を選択します。その後、運用ログ タブでエラーログを表示します。
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 とやり取りする際に、ロック待ちによってビジネス運用が中断され、データベース上で
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のトランザクションが見つかります。このトランザクションは長時間実行されており、他のトランザクションをブロッキングしています。
原因
InnoDB ストレージエンジンでは、
trx_mysql_thread_idが0であることは、XA トランザクションを識別します。これは、XA トランザクションの 2 フェーズコミット処理中に一般的に発生します。XA PREPAREを正常に実行して準備状態に入った後、ネットワーク障害、プログラム例外、その他の理由により、外部トランザクションマネージャーがXA COMMIT（コミット）またはXA ROLLBACK（ロールバック）を送信できない場合、トランザクションは準備状態のままになります。この状態では、トランザクションが取得したロックを保持し続け、他のトランザクションがそれらのリソースを必要とするときにブロッキングし、最終的にロック待ちタイムアウトを引き起こします。解決策
ビジネスの文脈に基づき、準備済みの XA トランザクションを手動でコミット（COMMIT）またはロールバック（ROLLBACK）する必要があります。
未コミットの XA トランザクションの検索:
XA RECOVER;コマンドを実行して、未コミットの XA トランザクションを一覧表示します。処理するトランザクションのformatID、gtrid_length、bqual_length、およびdataの値を記録します。これらの値は次のステップで重要です。
XA トランザクションの手動コミットまたはロールバック: XA トランザクションを特定した後、必要に応じてコミットまたはロールバックを選択します。
XA トランザクション識別子（
xid）の取得:xidはgtrid、bqual、およびformatIDで構成されます。前のステップで取得した値を使用して、xidを構築します。gtrid:dataフィールドの先頭からgtrid_lengthの長さの文字列を抽出します。bqual:dataフィールドの末尾からbqual_lengthの長さの文字列を抽出します。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 トランザクション構文の詳細については、MySQL ドキュメント：XA ステートメントをご参照ください。
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 つのバージョンは、この失敗時の動作が異なります。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: バックアップセット（スナップショット）からの復元（クローン）には、TB 当たり 40 分かかります。時点復元には、redo ログの適用が必要で、GB 当たり約 20～70 秒かかります。総復元時間は、これらの合計です。
パフォーマンスおよび容量
Q: PolarDB for MySQL の RDS for MySQL に対するパフォーマンス向上が顕著でないのはなぜですか？
A: PolarDB for MySQL と RDS for MySQL のパフォーマンスを比較する前に、正確かつ妥当な比較結果を得るために以下の点を確認してください。
PolarDB for MySQL と RDS for MySQL を、同一の仕様で比較します。
PolarDB for MySQL と RDS for MySQL を、同一のバージョンで比較します。
バージョンが異なると、実装メカニズムも異なります。たとえば、MySQL 8.0 は Log_writer、log_fluser、log_checkpoint、log_write_notifier などのスレッドを抽象化することで、マルチコア CPU を最適化します。ただし、CPU コア数が少ないシステムでは、MySQL 5.6 や 5.7 よりもパフォーマンスが低下する可能性があります。PolarDB for MySQL 5.6 と RDS for MySQL 5.7 や 8.0 を比較することは避けてください。MySQL 5.6 は古いオプティマイザーを使用しています。
パフォーマンス比較には、実際の本番ワークロードをシミュレートするか、sysbench を使用することを推奨します。これにより、実際のシナリオに近い結果が得られます。
読み取りパフォーマンスを比較する場合、単一の SQL ステートメントを使用しないでください。
PolarDB はコンピュート・ストレージ分離アーキテクチャを採用しています。単一のステートメントはネットワーク遅延の影響を受け、RDS と比較して読み取りパフォーマンスが低下します。本番データベースのキャッシュヒット率は通常 99 % 以上です。最初の読み取りのみ I/O をトリガーし、その後の読み取りはバッファープールを使用して I/O をトリガーしないため、パフォーマンスは同等になります。
書き込みパフォーマンスを比較する場合、単一の SQL ステートメントを使用しないでください。代わりに、本番ワークロードをシミュレートしてください。
RDS のパフォーマンスと比較するには、PolarDB（プライマリノード＋読み取り専用ノード）と RDS（プライマリインスタンス＋準同期読み取り専用インスタンス）を比較します。PolarDB は書き込みにクオーラムメカニズムを使用しており、3 つのレプリカのうち 2 つ以上に書き込まれると書き込みが成功します。PolarDB は、ストレージ層でデータ冗長性および強力な同期レプリケーションを保証します。RDS for MySQL の準同期レプリケーション（非同期ではない）と比較するのがより適切です。
PolarDB for MySQL と RDS for MySQL のパフォーマンス比較結果については、「パフォーマンス比較：PolarDB for MySQL vs. RDS for MySQL」をご参照ください。
Q: テーブルの最大数はいくつですか？ どの時点でパフォーマンスが低下する可能性がありますか？
A: テーブルの最大数はファイル数によって制限されます。詳細については、「制限事項」をご参照ください。
Q: テーブルパーティショニングは、PolarDB のクエリパフォーマンスを向上させますか？
一般的に、SQL クエリが単一のパーティションに限定される場合、パフォーマンスを向上させることができます。
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（完全 SQL ログ監査）を有効化した場合のパフォーマンスへの影響は何ですか？
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: 遅延 SQL ステートメントを特定するにはどうすればよいですか？
A: 次の 2 つの方法で遅延 SQL ステートメントを特定できます。
コンソールで直接遅延 SQL を照会します。詳細については、「遅延 SQL」をご参照ください。
データベースクラスターに接続した後、
show processlist;を実行して、実行時間が長い SQL ステートメントを特定します。データベースクラスターへの接続手順については、「データベースクラスターへの接続」をご参照ください。
Q: 遅延 SQL ステートメントを終了するにはどうすればよいですか？
A: 遅延 SQL ステートメントを特定した後、その ID を確認し、
kill <Id>を実行して終了します。
データライフサイクル
Q: PolarDB for MySQL は、ホットデータおよびウォームデータをコールドストレージにアーカイブするにはどうすればよいですか？
A: PolarDB for MySQL は、InnoDB エンジンからのホットデータおよび PolarStore の X-Engine エンジン からのウォームデータのアーカイブをサポートしています。DDL ポリシーを指定することで、データを OSS コールドストレージメディア（CSV または ORC 形式）にアーカイブできます。データがアーカイブされると、PolarStore 上のストレージスペースが解放され、データベース全体のストレージコストが効果的に削減されます。詳細については、「コールドデータの手動アーカイブ」をご参照ください。
Q: PolarDB for MySQL は、ホット、ウォーム、コールドデータの自動分離およびアーカイブをサポートしていますか？ それはどのように機能しますか？
A: PolarDB for MySQL は、ホット、ウォーム、コールドデータの自動分離およびアーカイブをサポートしています。指定された DLM ポリシーを使用することで、PolarStore のデータが低コストの OSS ストレージメディアに自動的にアーカイブされ、データベースのストレージコストが削減されます。詳細については、「コールドデータの自動アーカイブ」をご参照ください。