PolarDB engine FAQ - PolarDB - Alibaba Cloud ドキュメントセンター

このトピックでは、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 は数百テラバイトのデータを保存でき、高可用性、高信頼性、高速な弾性スケーリング、ロックフリーバックアップを提供します。詳細については、メリットをご参照ください。
Q: PolarDB はいつリリースされましたか？商用利用はいつから開始されましたか？
A: 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 は、Parallel 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: Single Node シリーズは、どのようにサービスの可用性とデータの信頼性を保証しますか？
A: Single Node シリーズは、単一の計算ノードに基づいて特定の機能を提供するデータベース製品です。ノードは 1 つだけですが、Single Node シリーズは、秒単位のコンピュートスケジューリングや分散マルチレプリカストレージなどの技術を使用して、高いサービスの可用性とデータの信頼性を保証します。
Q: シングルノードの PolarDB クラスターを購入するにはどうすればよいですか？
A: Single Node 製品シリーズは現在提供されていません。ただし、クラスターを購入する際に、[ノード数] セクションで読み取り専用ノードの数を 0 に設定することで、シングルノードの PolarDB クラスターを購入できます。

互換性

Q: コミュニティ版 MySQL と互換性がありますか？
A: PolarDB for MySQL は、コミュニティ版 MySQL と 100% 互換性があります。
Q: どのトランザクション分離レベルがサポートされていますか？
A: PolarDB for MySQL は、READ_UNCOMMITTED、READ_COMMITTED (デフォルト)、REPEATABLE_READ の 3 つの分離レベルをサポートしています。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: バイナリログのフォーマットは、ネイティブ MySQL のフォーマットと異なりますか？
A: 違いはありません。
Q: performance_schema と sys スキーマはサポートされていますか？
A: はい。
Q: テーブル統計の収集はコミュニティ版 MySQL と異なりますか？
A: PolarDB for MySQL のプライマリノードのテーブル統計は、コミュニティ版 MySQL と同じです。プライマリノードと読み取り専用ノードの実行計画の一貫性を確保するため、プライマリノードは統計を更新するたびに読み取り専用ノードに同期します。さらに、読み取り専用ノードは ANALYZE TABLE 操作を実行して、ディスクから最新の統計を能動的に読み込むことができます。
Q: PolarDB は XA トランザクションをサポートしていますか？公式 MySQL との違いはありますか？
A: はい、違いはありません。
Q: PolarDB はフルテキストインデックスをサポートしていますか？
A: はい。
説明
現在、フルテキストインデックスを使用する場合、読み取り専用ノードのインデックスキャッシュデータには一定の遅延があります。最新のデータを読み取るには、フルテキストインデックスの読み書き両方の操作にプライマリエンドポイントを使用してください。
Q: Percona Toolkit はサポートされていますか？
A: はい。ただし、オンライン DDL を使用してください。
Q: gh-ost はサポートされていますか？
A: はい。ただし、オンライン DDL を使用してください。

課金

Q: PolarDB の課金項目は何ですか？
A: 課金項目には、ストレージ容量、計算ノード、バックアップ (無料クォータあり)、SQL Explorer (オプション) が含まれます。詳細については、課金項目をご参照ください。
Q: 課金対象のストレージ容量には何が含まれますか？
A: データベーステーブルファイル、インデックスファイル、undo ログファイル、Redo ログファイル、バイナリログファイル、スローログファイル、および少数のシステムファイルが含まれます。詳細については、概要をご参照ください。
Q: PolarDB ストレージプランはどのように使用しますか？
A: サブスクリプションと従量課金の両方のクラスターで、ストレージプランを使用してストレージコストを相殺できます。たとえば、それぞれ 40 GB のストレージ容量を持つ 3 つのクラスター (合計 120 GB) がある場合、これらの 3 つのクラスターは 100 GB のストレージプランを共有できます。超過分の 20 GB は従量課金で請求されます。詳細については、ストレージプランの購入をご参照ください。
Q: 読み取り専用ノードを追加するコストはいくらですか？
A: 読み取り専用ノードの価格は、プライマリノードの価格と同じです。詳細については、計算ノードの価格をご参照ください。
Q: 読み取り専用ノードを追加すると、ストレージ容量は 2 倍になりますか？
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: delete コマンドを使用して PolarDB テーブルからデータを削除した後も、なぜストレージ容量に対して課金されるのですか？
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: 複数の読み取り専用ノードがある場合、そのうちの 1 つに対して個別のシングルノードエンドポイントを作成するにはどうすればよいですか？
A: シングルノードエンドポイントは、クラスターエンドポイントの読み書きモードが読み取り専用で、クラスターに 3 つ以上のノードがある場合にのみ作成できます。詳細な手順については、クラスターエンドポイントの設定をご参照ください。
警告
シングルノードエンドポイントを作成した後、ノードに障害が発生した場合、エンドポイントは最大 1 時間利用できなくなる可能性があります。本番環境ではこのエンドポイントを使用しないでください。
Q: 1 つのクラスターで作成できるシングルノードエンドポイントの最大数はいくつですか？
A: クラスターに 3 つのノードがある場合、読み取り専用ノードの 1 つに対してのみシングルノードエンドポイントを作成できます。クラスターに 4 つのノードがある場合、読み取り専用ノードの 2 つに対して個別のシングルノードエンドポイントを作成できます。以下同様です。
Q: プライマリエンドポイントしか使用していませんが、読み取り専用ノードにも負荷がかかっていることに気づきました。プライマリエンドポイントも読み書き分離をサポートしていますか？
A: プライマリエンドポイントは読み書き分離をサポートしていません。常にプライマリノードにのみ接続します。読み取り専用ノードの少量の QPS は正常であり、プライマリエンドポイントとは関係ありません。

管理とメンテナンス

Q: オンラインでフィールドとインデックスを追加するにはどうすればよいですか？
A: ネイティブのオンライン DDL 操作を使用します。pt-online-schema-change や gh-ost などのツールもサポートされています。
説明
pt-online-schema-change ツールを使用する場合、recursion-method パラメーターなど、プライマリ/レプリカ検出に関連するパラメーターは使用しないでください。これは、pt-online-schema-change ツールがバイナリログレプリケーションに基づいてプライマリ/レプリカ検出を実行するためですが、PolarDB は内部で物理レプリケーションを使用しており、バイナリログに基づくレプリケーション情報を持たないためです。
Q: 一括挿入機能はサポートされていますか？
A: はい。
Q: 書き込みノードにのみデータを書き込む場合、一括挿入はサポートされていますか？一度に挿入できる値の最大数はいくつですか？
A: はい。max_allowed_packet パラメーターによって最大値の数が決まります。詳細については、レプリケーションと max_allowed_packet をご参照ください。
Q: クラスターエンドポイントを介して一括挿入操作を実行できますか？
A: はい。
Q: プライマリノードと読み取り専用ノードの間にレプリケーション遅延はありますか？
A: はい、ミリ秒レベルの遅延があります。
Q: レプリケーション遅延が増加する原因は何ですか？
A: 次の状況でレプリケーション遅延が増加します：
- プライマリノードの書き込み負荷が高く、読み取り専用ノードが時間内に適用できないほど多くの Redo ログが生成される。
- 読み取り専用ノードの負荷が高すぎ、元々 Redo ログの適用に割り当てられていたリソースを過剰に消費する。
- I/O ボトルネックにより、Redo ログの読み書きが遅くなる。
Q: レプリケーション遅延がある場合、クエリの一貫性をどのように確保できますか？
A: クラスターエンドポイントを使用し、適切な整合性レベルを選択します。現在、整合性レベルは高い順にグローバル整合性 (強力な整合性)、セッションの一貫性、最終的な整合性です。詳細については、整合性レベルをご参照ください。
Q: 単一ノード障害が発生した場合、目標復旧時点 (RPO) 0 を保証できますか？
A: はい。
Q: スペックアップ (例：2 CPU コア、8 GB メモリから 4 CPU コア、16 GB メモリへ) はバックエンドでどのように実装されますか？サービスへの影響はありますか？
A: PolarDB のプロキシとデータベースノードの両方を最新の仕様にアップグレードする必要があります。PolarDB は、サービスへの影響を最小限に抑えるために、複数のノードにまたがるローリングアップグレード方式を採用しています。アップグレードには現在約 10〜15 分かかります。サービスへの影響は 30 秒以内です。この期間中に 1〜3 回の一時的な切断が発生する可能性があります。詳細については、手動での仕様変更をご参照ください。
Q: ノードの追加にはどのくらいの時間がかかりますか？サービスに影響はありますか？
A: ノードの追加には約 5 分かかり、サービスには影響しません。ノードの追加方法については、ノードの追加をご参照ください。
説明
読み取り専用ノードが追加された後、新しい読み書き分離接続はそのノードにリクエストを転送します。ノードが追加される前に確立された読み書き分離接続は、新しいノードにリクエストを転送しません。これらの接続を切断して再確立する必要があります (例：アプリケーションの再起動)。
Q: 最新のリビジョンバージョンへのアップグレードにはどのくらいの時間がかかりますか？サービスに影響はありますか？
A: PolarDB は、サービスへの影響を最小限に抑えるために、複数のノードにまたがるローリングアップグレード方式を採用しています。バージョンアップグレードは通常 30 分以内で完了します。アップグレード中に、データベースプロキシまたは DB カーネルエンジンが再起動され、一時的な切断が発生する可能性があります。アップグレードはオフピーク時に実行し、アプリケーションに自動再接続メカニズムがあることを確認してください。詳細については、マイナーバージョン管理をご参照ください。
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: データベースプロキシは、デュアルノードの高可用性アーキテクチャを採用しています。トラフィックは 1:1 の比率で 2 つのプロキシノードに均等に分散されます。システムはプロキシノードの健全性状態を継続的にチェックします。ノード障害が検出されると、システムはそのノード上の接続を能動的に切断し、残りの正常なノードがすべてのトラフィックを自動的に引き継いでサービスの継続性を確保します。同時に、システムは障害が発生したプロキシノードを自動的に再構築して回復します。このプロセスは通常、約 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: PolarDB はどのバックアップ方法を使用しますか？
A: PolarDB はバックアップにスナップショットを使用します。詳細については、「バックアップ方法 1: 自動バックアップ」および「バックアップ方法 2: 手動バックアップ」をご参照ください。
Q: データベースの回復速度はどのくらいですか？
A: 現在、バックアップセット (スナップショット) からの回復 (クローニング) には、1 テラバイトあたり約 40 分かかります。ポイントインタイムリカバリを実行する場合、Redo ログを適用する時間も含まれます。この部分の回復には、1 ギガバイトあたり約 20〜70 秒かかります。合計回復時間は、これら 2 つの部分の合計です。

パフォーマンスと容量

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 はマルチコア CPU に最適化されており、Log_writer、log_flusher、log_checkpoint、log_write_notifier などのスレッドを抽象化しています。しかし、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 のアーキテクチャが、データを書き込む際にデフォルトで Quorum メカニズムを使用するためです。つまり、3 つのレプリカのうち過半数 (2 つ以上) にデータが書き込まれれば、書き込み操作は成功と見なされます。PolarDB はすでにストレージレイヤーでデータ冗長性を実装しており、3 つのレプリカ間での強力な同期により高い信頼性を確保しています。非同期レプリケーションではなく、準同期レプリケーションを使用する RDS for MySQL と比較する方が合理的です。
PolarDB for MySQL と 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: バイナリログを有効にすることによるパフォーマンスへの影響は何ですか？
A: バイナリログを有効にしても、クエリ (SELECT) のパフォーマンスには影響しません。書き込みおよび更新 (INSERT、UPDATE、DELETE) のパフォーマンスにのみ影響します。読み書き負荷が均衡しているデータベースでは、バイナリログを有効にすることによるパフォーマンスへの影響は通常 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 は、DDL ポリシーを指定することで、PolarStore の InnoDB エンジンからのホットデータと X-Engine エンジンからのウォームデータを、OSS 上のコールドストレージメディアに CSV または ORC 形式でアーカイブすることをサポートしています。アーカイブ後、PolarStore 上のストレージ容量が効果的に解放され、データベース全体のストレージコストが削減されます。詳細については、コールドデータの手動アーカイブをご参照ください。
Q: PolarDB for MySQL は、ホット、ウォーム、コールドデータの自動分離とストレージをサポートしていますか？これはどのように実装されますか？
A: PolarDB for MySQL は、ホット、ウォーム、コールドデータを分離する自動アーカイブをサポートしています。データライフサイクル管理 (DLM) ポリシーを指定することで、PolarStore から低コストの OSS ストレージメディアにデータを自動的にアーカイブでき、データベースのストレージコストを効果的に削減できます。詳細については、コールドデータの自動アーカイブをご参照ください。