このトピックでは、PolarDB for MySQL、、および に関するよくある質問への回答を提供します。
基本的な質問
Q: PolarDB とは何ですか？
A: PolarDB は、世界中の 10 以上のリージョンにまたがるデータセンターにデプロイされたリレーショナルデータベースクラウドサービスです。すぐに使えるオンラインデータベースサービスを提供します。PolarDB は 3 つの独立したエンジンをサポートしており、MySQL と PostgreSQL との完全な互換性、および Oracle 構文との高い互換性を実現しています。PolarDB クラスターは、最大 200 TB のストレージ容量を提供します。詳細については、「PolarDB for MySQL Enterprise Edition とは」をご参照ください。
Q: クラウドネイティブデータベース PolarDB が従来のデータベースよりも優れているのはなぜですか？
A: 従来のデータベースと比較して、クラウドネイティブデータベース PolarDB は数百テラバイトのデータを保存できます。また、高可用性、高信頼性、迅速な弾性的なスペックアップとスペックダウン、ロックフリーのバックアップなど、幅広い機能を提供します。詳細については、「メリット」をご参照ください。
Q: PolarDB はいつリリースされましたか？商用利用はいつから可能になりましたか？
A: PolarDB は 2017 年 9 月にパブリックプレビューとしてリリースされ、2018 年 3 月に商用利用が可能になりました。
Q: クラスターとノードとは何ですか？
A: PolarDB Cluster Edition は、マルチノードのクラスターアーキテクチャを使用します。クラスターには 1 つのプライマリノードと複数の読み取り専用ノードがあります。単一の PolarDB クラスターはゾーンをまたいでデプロイできますが、リージョンをまたぐことはできません。PolarDB サービスはクラスターレベルで管理および課金されます。詳細については、「用語集」をご参照ください。
Q: PolarDB はどのプログラミング言語をサポートしていますか？
A: PolarDB は、Java、Python、PHP、Go、C、C++、.NET、Node.js などのプログラミング言語をサポートしています。ネイティブの MySQL と対話できるプログラミング言語は、PolarDB for MySQL とも対話できます。詳細については、MySQL 公式ウェブサイト をご参照ください。
Q: PolarDB はどのストレージエンジンをサポートしていますか？
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: シングルノードクラスターはどのようにしてサービスの可用性とデータの信頼性を保証しますか？
A: シングルノードクラスターは、特定の目的のために単一の計算ノードを操作するように設計されています。シングルノードクラスターにはノードが 1 つしかありませんが、秒レベルの計算スケジューリングや分散マルチレプリカストレージなどの技術を使用して、高いサービスの可用性とデータの信頼性を保証します。
Q: シングルノードの PolarDB クラスターはどのように購入しますか？
A: シングルノードクラスターは現在販売されていません。ただし、クラスターを購入する際に [ノード数] セクションで読み取り専用ノードの数を 0 に設定することで、シングルノードの PolarDB クラスターを作成できます。
互換性
Q: PolarDB for MySQL は MySQL Community Edition と互換性がありますか？
A: はい、PolarDB for MySQL は MySQL Community Edition と完全に互換性があります。
Q: どのトランザクション分離レベルがサポートされていますか？
A: PolarDB for MySQL は、READ_UNCOMMITTED、READ_COMMITTED (デフォルト)、および REPEATABLE_READ の分離レベルをサポートしています。SERIALIZABLE 分離レベルはサポートしていません。
Q: PolarDB for MySQL の SHOW PROCESSLIST 文のクエリ結果は、MySQL Community Edition のものと同じですか？
A: プライマリエンドポイントを使用して SHOW PROCESSLIST 文を実行する場合、クエリ結果は同じです。クラスターエンドポイントを使用して SHOW PROCESSLIST 文を実行する場合、クエリ結果は異なります。PolarDB for MySQL クラスターでの文のクエリ結果では、同じスレッド ID を持つ複数のレコードが見つかることがあります。これらの各レコードは、クラスター内のノードに対応しています。
Q: PolarDB for MySQL のメタデータロック (MDL) メカニズムは、MySQL Community Edition のものと同じですか？
A: PolarDB for MySQL のメタデータロック (MDL) メカニズムは、MySQL Community Edition のものと同じです。ただし、PolarDB for MySQL のデータベースノードは共有ストレージアーキテクチャに基づいています。これは、プライマリノードでデータ定義言語 (DDL) 操作が実行されると、読み取り専用ノードが DDL 操作からの中間データにアクセスする可能性があり、データの不整合を引き起こす可能性があることを意味します。これを防ぐために、PolarDB for MySQL は redo ログを使用して、DDL 操作に関与する排他的な MDL を読み取り専用ノードに同期します。これにより、DDL 操作中に読み取り専用ノード上の他のユーザースレッドがテーブルデータにアクセスするのを防ぎます。特定のシナリオでは、これにより DDL 操作がブロックされる可能性があります。
show processlistコマンドを実行して、DDL 操作の状態を表示できます。DDL 操作がWait for syncing with replicas状態にある場合、このようなブロッキングが発生したことを示します。この問題を解決する方法については、「DDL 実行ステータスと MDL ステータスを表示する」をご参照ください。Q: PolarDB for MySQL のバイナリロギング形式は、MySQL のネイティブなバイナリロギング形式と同じですか？
A: 違いはありません。
Q: PolarDB はパフォーマンススキーマと sys スキーマをサポートしていますか？
A: はい、サポートしています。
Q: PolarDB for MySQL は、MySQL Community Edition と同じテーブル統計収集メカニズムを使用していますか？
A: PolarDB for MySQL のプライマリノードのテーブル統計は、MySQL Community Edition のものと一致しています。プライマリノードと読み取り専用ノードの間で実行計画が一致するように、プライマリノードでのテーブル統計の各更新は読み取り専用ノードに同期されます。また、読み取り専用ノードで
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 (オプション)、および Global Database Network (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: 複数の読み取り専用ノードがある場合、そのうちの 1 つに対して個別のシングルノードエンドポイントを作成するにはどうすればよいですか？
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 ツールがバイナリロギングレプリケーションに基づいてプライマリ/セカンダリ検出を実行するためです。しかし、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 のプロキシとデータベースノードは新しい仕様にスペックアップされます。ビジネスへの影響を最小限に抑えるために、複数のノードのローリングアップグレードが使用されます。現在、各スペックアップには約 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: PolarDB はどのバックアップ方法を使用しますか？
A: PolarDB はスナップショットを使用してデータをバックアップします。詳細については、「バックアップ方法 1: 自動バックアップ」および「バックアップ方法 2: 手動バックアップ」をご参照ください。
Q: データベースはどのくらいの速さで復元できますか？
A: 現在、バックアップセット (スナップショット) からデータを復元 (クローン) するには、1 TB あたり 40 分かかります。特定の時点にデータを復元する場合、redo ログを適用する時間も含まれます。この部分の復元には、1 GB あたり約 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 は、Log_writer、log_fluser、log_checkpoint、log_write_notifier などのスレッドを個別に抽象化することで、マルチコア CPU に最適化されています。ただし、使用される CPU コアが少ない場合、MySQL 8.0 のパフォーマンスは 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 つのレプリカの過半数に書き込まれます。データが 3 つのレプリカのうち 2 つ以上に書き込まれた場合、書き込み操作は成功したと見なされます。PolarDB はすでにストレージレイヤーでデータ冗長性を提供し、3 つのレプリカの強力な同期と高い信頼性を保証しています。したがって、比較には RDS for MySQL の非同期レプリケーションではなく、準同期レプリケーションを使用する方が合理的です。
PolarDB for MySQL と RDS for MySQL のパフォーマンス比較結果の詳細については、「PolarDB for MySQL と RDS for MySQL のパフォーマンス比較」をご参照ください。
Q: テーブルの最大数はいくつですか？どのくらいのテーブル数でパフォーマンスが低下し始める可能性がありますか？
A: テーブルの最大数はファイル数によって制限されます。詳細については、「制限」をご参照ください。
Q: テーブルパーティショニングは PolarDB のクエリパフォーマンスを向上させることができますか？
A: 一般的に、SQL クエリが特定のパーティション内に収まる場合、パフォーマンスは向上します。
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 のテーブルは、物理的に分割され、N 個のストレージサーバーに保存されます。したがって、テーブルの 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: 遅い SQL 文は次の 2 つの方法で見つけることができます。
コンソールで直接遅い 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 ポリシーを指定することで CSV または ORC 形式で OSS のコールドストレージメディアにアーカイブすることをサポートしています。アーカイブ後、PolarStore 上のストレージ容量が解放され、データベース全体のストレージコストが削減されます。詳細については、「コールドデータの手動アーカイブ」をご参照ください。
Q: PolarDB for MySQL クラスターは、ホット、ウォーム、コールドデータの自動分離と保存をサポートしていますか？これはどのように実装されますか？
A: PolarDB for MySQL クラスターは、ホット、ウォーム、コールドデータの自動分離とアーカイブをサポートしています。DLM ポリシーを指定することで、PolarStore から低コストの OSS ストレージメディアにデータを自動的にアーカイブできます。これにより、データベースのストレージコストが削減され、効果が最適化されます。詳細については、「コールドデータの自動アーカイブ」をご参照ください。