このトピックでは、PolarDB for PostgreSQL に関するよくある質問に回答します。
基本的な質問
Q: PolarDB とは何ですか？
A: PolarDB は、すぐに使えるデータベースサービスを提供するクラウドベースのリレーショナルデータベースサービスです。10 以上のリージョンにまたがるデータセンターにデプロイされています。PolarDB は PostgreSQL と完全な互換性があります。デフォルトでは、PolarDB クラスターは最大 500 TB のストレージ容量を提供します。
説明PolarStore (PSL4/PSL5) はペタバイト規模のストレージをサポートします。この規模のストレージが必要な場合は、お問い合わせいただき、リソースを予約してください。
Q: クラウドネイティブ PolarDB が従来のデータベースより優れているのはなぜですか？
A: 従来のデータベースと比較して、クラウドネイティブ PolarDB は数百テラバイトのデータを保存できます。また、高可用性、高信頼性、迅速な弾性スケーリング、ロックフリーバックアップなどの機能も提供します。詳細については、「メリット」をご参照ください。
Q: PolarDB はいつリリースされましたか？商用利用はいつから可能になりましたか？
A: PolarDB は 2017 年 9 月にパブリックプレビューとしてリリースされ、2018 年 3 月に商用利用が可能になりました。
Q: クラスターとノードとは何ですか？
A: PolarDB クラスター版は、マルチノードのクラスターアーキテクチャを使用します。クラスターには 1 つのプライマリノードと複数の読み取り専用ノードがあります。単一の PolarDB クラスターはゾーンをまたいでデプロイできますが、リージョンをまたぐことはできません。クラスターはクラスターレベルで管理および課金されます。詳細については、「用語集」をご参照ください。
Q: どのプログラミング言語がサポートされていますか？
A: PolarDB は、Java、Python、PHP、Go、C、C++、.NET、Node.js などのプログラミング言語をサポートしています。
Q: PolarDB を購入した後、シャーディングを実装するために PolarDB-X データベースミドルウェアを別途購入する必要がありますか？
A: はい、必要です。
Q: PolarDB はテーブルパーティショニングをサポートしていますか？
A: はい、サポートしています。
Q: PolarDB にはパーティショニングメカニズムが自動的に含まれていますか？
A: PolarDB はストレージレイヤーでパーティショニングを実行します。これはユーザーに対して透明です。
課金
Q: PolarDB の料金には何が含まれますか？
A: 料金には、ストレージ領域、計算ノード、バックアップ (無料クォータを含む)、および SQL Explorer (オプション) の料金が含まれます。詳細については、「仕様と価格」をご参照ください。
Q: 課金対象のストレージ領域には何が含まれますか？
A: 課金対象のストレージ領域には、データベーステーブルファイル、インデックスファイル、undo ログファイル、redo ログファイル、スローログファイル、および少数のシステムファイルが含まれます。詳細については、「仕様と価格」をご参照ください。
Q: PolarDB ストレージプランはどのように使用しますか？
A: サブスクリプションおよび従量課金クラスターは、ストレージプランを使用してストレージコストを相殺できます。たとえば、それぞれ 40 GB のストレージを持つ 3 つのクラスター (合計 120 GB) がある場合、3 つのクラスターは 100 GB のストレージプランを共有できます。超過分の 20 GB は従量課金制で請求されます。詳細については、「ストレージプランの購入」をご参照ください。
クラスターアクセス (読み書き分離)
Q: PolarDB で読み書き分離を実装するにはどうすればよいですか？
A: アプリケーションでクラスターエンドポイントを使用することで、読み書き分離を実装できます。分離は、設定された読み書きモードに基づいています。詳細については、「データベースプロキシの設定」をご参照ください。
Q: PolarDB クラスターはいくつの読み取り専用ノードをサポートできますか？
A: PolarDB は分散クラスターアーキテクチャを使用します。クラスターには 1 つのプライマリノードと最大 15 の読み取り専用ノードが含まれます。高可用性を確保するためには、少なくとも 1 つの読み取り専用ノードが必要です。
Q: 複数の読み取り専用ノード間で負荷が不均衡になるのはなぜですか？
A: 読み取り専用ノードへの接続が少ない、またはカスタムクラスターエンドポイントを設定した際に読み取り専用ノードが含まれていなかったため、読み取り専用ノード間で負荷が不均衡になることがあります。
Q: プライマリノードの負荷が高くなったり低くなったりする原因は何ですか？
A: プライマリノードの負荷が高くなる原因はいくつかあります。プライマリエンドポイントへの直接接続、プライマリノードが読み取りリクエストを受け付けている、トランザクションリクエストの量が多い、プライマリ/セカンダリのレプリケーション遅延によりリクエストがプライマリノードにルーティングされる、または読み取り専用ノードの例外により読み取りリクエストがプライマリノードにルーティングされるなどです。
プライマリノードの負荷が低いのは、プライマリノードからの読み取りをオフロードするオプションが有効になっているためかもしれません。
Q: プライマリノードの負荷を軽減するにはどうすればよいですか？
A: 次の方法を使用して、プライマリノードの負荷を軽減できます。
PolarDB クラスターに接続するためにクラスターエンドポイントを使用します。詳細については、「データベースプロキシの設定」をご参照ください。
多くのトランザクションがプライマリノードに高い負荷をかけている場合は、コンソールでトランザクション分割機能を有効にできます。これにより、トランザクション内の一部のクエリが読み取り専用ノードにルーティングされます。詳細については、「高度なオプション - トランザクション分割」をご参照ください。
レプリケーションの遅延のためにリクエストがプライマリノードにルーティングされる場合は、整合性レベルを下げることを検討してください。たとえば、結果整合性を使用します。詳細については、「高度なオプション - 整合性レベル」をご参照ください。
プライマリノードで読み取りリクエストを受け付けることも、高い負荷の原因となります。コンソールで「プライマリノードからの読み取りをオフロード」機能を有効にすると、プライマリノードにルーティングされる読み取りリクエストの数を減らすことができます。
Q: 挿入したばかりのデータを読み取れないのはなぜですか？
A: この問題は、整合性レベルの設定が原因である可能性があります。PolarDB のクラスターエンドポイントは、次の整合性レベルをサポートしています。
結果整合性: 同じセッション (接続) 内でも、異なるセッションでも、新しく挿入されたデータをすぐに読み取れることを保証しません。
セッションの一貫性: 同じセッション内で挿入されたデータを読み取れることを保証します。
説明整合性レベルが高いほど、パフォーマンスは低下し、プライマリノードへの負荷は大きくなります。慎重に選択してください。ほとんどのアプリケーションシナリオでは、セッションの一貫性でサービスの正常な動作が保証されます。強力な整合性を必要とする少数のステートメントについては、Hint
/* FORCE_MASTER */を使用できます。詳細については、「整合性レベル」をご参照ください。Q: SQL 文をプライマリノードで強制的に実行するにはどうすればよいですか？
クラスターエンドポイントを使用する場合、SQL 文の前に
/* FORCE_MASTER */または/* FORCE_SLAVE */を追加して、ルーティング方向を強制します。詳細については、「カスタムルート - Hint」をご参照ください。/* FORCE_MASTER */は、リクエストをプライマリノードに強制的にルーティングします。これは、高い整合性要件を持つ少数の読み取りリクエストに使用できます。/* FORCE_SLAVE */は、リクエストを読み取り専用ノードに強制的にルーティングします。これは、PolarDB プロキシが正当性を確保するために読み取り専用ノードにルーティングするために特別な構文を必要とする少数のシナリオで使用できます。たとえば、ストアドプロシージャを呼び出すステートメントやマルチステートメントを使用するステートメントは、デフォルトでプライマリノードにルーティングされます。
説明Hint は最高のルーティング優先度を持ち、整合性レベルやトランザクション分割に制約されません。使用前に評価してください。
/*FORCE_SLAVE*/ set names utf8;のように、環境変数を変更するステートメントを Hint 文に含めないでください。これらのタイプのステートメントは、予期しないクエリ結果につながる可能性があります。
Q: 異なるサービスに異なるエンドポイントを割り当てることはできますか？異なるエンドポイントで隔離を実現できますか？
A: はい。異なるサービスに対して複数のカスタムエンドポイントを作成できます。基盤となるノードが異なる場合、カスタムエンドポイントは隔離も提供し、互いに影響を与えません。カスタムエンドポイントの作成方法の詳細については、「データベースプロキシの設定」をご参照ください。
Q: 複数の読み取り専用ノードがある場合、そのうちの 1 つに対して個別のシングルノードエンドポイントを作成するにはどうすればよいですか？
A: シングルノードエンドポイントは、クラスターエンドポイントの読み書きモードが読み取り専用で、クラスターに 3 つ以上のノードがある場合にのみ作成できます。詳細な手順については、「データベースプロキシの設定」をご参照ください。
警告シングルノードエンドポイントを作成した後、このノードに障害が発生した場合、エンドポイントは最大 1 時間利用できなくなる可能性があります。本番環境では使用しないでください。
Q: クラスター内に作成できるシングルノードエンドポイントの最大数はいくつですか？
A: クラスターに 3 つのノードがある場合、読み取り専用ノードのうち 1 つに対してのみシングルノードエンドポイントを作成できます。クラスターに 4 つのノードがある場合、読み取り専用ノードのうち 2 つに対してシングルノードエンドポイントを作成できます。ノード数が多いクラスターにも同じロジックが適用されます。
Q: プライマリエンドポイントしか使用していませんが、読み取り専用ノードにも負荷がかかっているようです。プライマリエンドポイントも読み書き分離をサポートしていますか？
A: プライマリエンドポイントは読み書き分離をサポートしていません。常にプライマリノードにのみ接続します。読み取り専用ノードに小さなクエリ/秒 (QPS) の負荷がかかるのは正常であり、プライマリエンドポイントとは無関係です。
管理とメンテナンス
Q: プライマリノードと読み取り専用ノードの間にレプリケーションの遅延はありますか？
A: はい、ミリ秒レベルの遅延があります。
Q: レプリケーションの遅延が増加する原因は何ですか？
A: 次の状況でレプリケーションの遅延が増加する可能性があります。
プライマリノードの書き込み負荷が高く、読み取り専用ノードが適用できる速度よりも速く redo ログを生成している。
読み取り専用ノードの負荷が過度に高く、redo ログの適用に必要なリソースを奪っている。
I/O ボトルネックが発生し、redo ログの読み書きが遅くなっている。
Q: レプリケーションの遅延がある場合にクエリの一貫性を確保するにはどうすればよいですか？
A: クラスターエンドポイントを使用し、それに適切な整合性レベルを選択できます。現在、整合性レベルは高いものから順にセッションの一貫性、結果整合性です。詳細については、「データベースプロキシの設定」をご参照ください。
Q: シングルノード障害が発生した場合、RPO 0 を保証できますか？
A: デフォルトのデータベースクラスターパラメーターでは、目標復旧時点 (RPO) は 0 ではありません。ただし、
synchronous_commitパラメーターを調整することで RPO を 0 に設定できます。詳細については、「デフォルトのクラスターパラメーター値」をご参照ください。Q: スペックアップ (たとえば、2 コア 8 GB メモリから 4 コア 16 GB メモリへ) はバックエンドでどのように実装されますか？サービスへの影響は何ですか？
A: PolarDB のプロキシノードとデータベースノードの両方を最新の構成にアップグレードする必要があります。サービスへの影響を最小限に抑えるために、複数のノードのローリングアップグレードが使用されます。現在、各アップグレードには約 10〜15 分かかります。サービスへの影響は 30 秒以内です。この期間中に、1〜3 回の一時的な接続エラーが発生する可能性があります。詳細については、「仕様の変更」をご参照ください。
Q: ノードの追加にはどのくらい時間がかかりますか？サービスに影響はありますか？
A: ノードの追加には 5 分かかり、サービスへの影響はありません。ノードの追加方法の詳細については、「読み取り専用ノードの追加」をご参照ください。
説明新しい読み取り専用ノードが追加された後、新しい読み書き分離接続はリクエストをその読み取り専用ノードに転送します。新しい読み取り専用ノードが追加される前に確立された読み書き分離接続は、リクエストを新しいノードに転送しません。接続を切断して再確立する必要があります。たとえば、アプリケーションを再起動します。
Q: 最新のリビジョンバージョンへのアップグレードにはどのくらい時間がかかりますか？サービスに影響はありますか？
A: PolarDB は、サービスへの影響を最小限に抑えるためにマルチノードのローリングアップグレードを使用します。バージョンのアップグレードは通常 30 分以内で完了します。アップグレード中に、データベースプロキシまたは DB カーネルエンジンが再起動され、一時的な接続エラーが発生する可能性があります。アップグレードはオフピーク時に実行し、アプリケーションに自動再接続メカニズムがあることを確認してください。詳細については、「マイナーバージョン管理」をご参照ください。
Q: 自動フェールオーバーはどのように機能しますか？
A: PolarDB は、アクティブ/アクティブの高可用性クラスターアーキテクチャを使用します。読み書きプライマリノードと読み取り専用ノードの間で自動フェールオーバーを実行します。システムは自動的に新しいプライマリノードを選出します。PolarDB クラスター内の各ノードにはフェールオーバーの優先順位があり、これによりフェールオーバー中にプライマリノードとして選出される確率が決まります。複数のノードが同じ優先順位を持つ場合、それらはプライマリノードとして選出される確率が同じになります。詳細については、「自動および手動のプライマリ/セカンダリフェールオーバー」をご参照ください。
Q: データベースプロキシのアーキテクチャは何ですか？フェールオーバーメカニズムはありますか？高可用性はどのように保証されますか？
A: データベースプロキシは、デュアルノードの高可用性アーキテクチャを使用します。トラフィックは 2 つのプロキシノード間で均等に分散されます。システムはプロキシノードの健全性を継続的にチェックします。ノード障害が検出されると、そのノードへの接続は切断され、残りの正常なノードが自動的にすべてのトラフィックを引き継ぎ、サービスの継続性を確保します。その後、システムは障害のあったプロキシノードを自動的に再構築して回復します。このプロセスは通常、約 2 分かかります。この間、データベースクラスターはアクセス可能なままです。
まれに、障害のあったノードへの接続が時間内に切断されず、リクエストに応答できなくなることがあります。このような状況に対処するために、クライアント側で合理的なタイムアウトポリシーを設定することをお勧めします。たとえば、JDBC の
socketTimeoutやconnectTimeoutなどです。これにより、アプリケーション層が一時停止した接続を迅速に検出して終了させることができ、システムのフォールトトレランスと応答効率が向上します。
バックアップと復元
Q: PolarDB はどのバックアップ方法を使用しますか？
A: PolarDB はバックアップにスナップショットを使用します。詳細については、「バックアップ方法 2: 手動バックアップ」をご参照ください。
Q: データベースの回復速度はどのくらいですか？
A: 現在、バックアップセット (スナップショット) からの回復 (クローニング) には、1 テラバイト (TB) あたり 40 分かかります。特定の時点に回復する場合は、redo ログを適用する時間も加算する必要があります。この部分の回復には、1 ギガバイト (GB) あたり約 20〜70 秒かかります。合計回復時間は、これら 2 つの部分の合計です。
パフォーマンスと容量
Q: テーブルの最大数はいくつですか？どのくらいのテーブル数でパフォーマンスが低下し始める可能性がありますか？
A: テーブルの最大数はファイル数によって制限されます。詳細については、「制限」をご参照ください。
Q: テーブルパーティショニングは PolarDB のクエリパフォーマンスを向上させることができますか？
A: はい。クエリを特定のパーティションに限定できる場合、パフォーマンスを向上させることができます。
Q: PolarDB は 10,000 個のデータベースの作成をサポートしていますか？データベースの最大数はいくつですか？
A: PolarDB は 10,000 個のデータベースの作成をサポートしています。データベースの最大数はファイル数によって制限されます。詳細については、「制限」をご参照ください。
Q: IOPS はどのように制限され、隔離されますか？複数の PolarDB クラスターノードが I/O を競合しますか？
A: PolarDB クラスター内の各ノードの IOPS は、その仕様に従って設定されます。各ノードの IOPS は独立して隔離されており、他のノードに影響を与えません。
Q: 読み取り専用ノードのパフォーマンスが低下した場合、プライマリノードのパフォーマンスに影響はありますか？
A: 読み取り専用ノードの負荷が過度に高くなったり、レプリケーションの遅延が増加したりすると、プライマリノードのメモリ消費量がわずかに増加する可能性があります。
Q: SQL Explorer (完全な SQL ログ監査) を有効にすることによるパフォーマンスへの影響は何ですか？
A: パフォーマンスへの影響はありません。
Q: PolarDB はどの高速ネットワークプロトコルを使用していますか？
A: PolarDB は、データベース計算ノードとストレージノード間、およびストレージデータレプリカ間で、デュアル 25 Gbps の Remote Direct Memory Access (RDMA) 技術を使用しています。これにより、低遅延かつ高スループットの強力な I/O パフォーマンスが提供されます。
Q: PolarDB への外部接続の最大帯域幅はどれくらいですか？
A: PolarDB への外部接続の最大帯域幅は 10 Gbit/s です。
Q: ノードの再起動に時間がかかる場合はどうすればよいですか？
A: クラスター内のファイルが多いほど、ノードの再起動に時間がかかります。この場合、innodb_fast_startup パラメーターを ON に設定することで再起動を高速化できます。パラメーターの変更方法の詳細については、「クラスターおよびノードパラメーターの設定」をご参照ください。