このトピックでは、PolarDB for PostgreSQL に関するよくある質問にお答えします。
基本的な質問
Q: PolarDB とは何ですか？
PolarDB は、すぐに使えるオンラインデータベース機能を提供するクラウドネイティブなリレーショナルデータベースサービスです。 10 を超えるリージョンで展開されています。 PolarDB は PostgreSQL と 100% の互換性があります。 デフォルトで、PolarDB クラスターは最大 500 TB のストレージ容量を提供します。
説明PolarStore (PSL4/PSL5) はペタバイト規模のストレージをサポートしています。この規模のストレージが必要な場合は、弊社までご連絡いただき、リソースを予約してください。
Q: クラウドネイティブ PolarDB が従来のデータベースより優れているのはなぜですか？
A: 従来のデータベースと比較して、クラウドネイティブ PolarDB は数百テラバイトのデータを保存でき、高可用性、高信頼性、迅速なエラスティックスケーリング、ロックフリーバックアップなどの特徴を備えています。詳細については、「メリット」をご参照ください。
Q: PolarDB はいつリリースされ、いつ商用化されましたか？
A: 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: アプリケーションでクラスターエンドポイントを使用して、読み書き分離を実装します。分離は、設定された読み書きモードに基づいています。詳細については、「データベースプロキシの設定」をご参照ください。
Q. PolarDB クラスターは、最大でいくつの読み取り専用ノードをサポートできますか？
A: PolarDB は分散クラスタアーキテクチャを採用しています。クラスターには、1 つのプライマリノードと最大 15 の読み取り専用ノードが含まれます。高可用性を確保するには、少なくとも 1 つの読み取り専用ノードが必要です。
Q: 複数の読み取り専用ノード間で負荷が不均衡になるのはなぜですか？
A: 読み取り専用ノードへの接続が少ない、またはカスタムクラスターエンドポイントを設定する際に読み取り専用ノードが含まれていなかったため、読み取り専用ノード間で負荷が不均衡になることがあります。
Q: プライマリノードの負荷が高くなったり低くなったりする原因は何ですか？
A: プライマリノードの負荷が高くなる原因はいくつかあります：プライマリエンドポイントへの直接接続、プライマリノードが読み取りリクエストを受け付けている、トランザクションリクエストの量が多い、プライマリ/セカンダリ間のレプリケーション遅延によりリクエストがプライマリノードにルーティングされる、または読み取り専用ノードの例外により読み取りリクエストがプライマリノードにルーティングされるなどです。
プライマリノードの負荷が低い場合は、プライマリデータベースが読み取りリクエストを拒否するように設定されている可能性があります。
Q: プライマリノードの負荷を軽減するにはどうすればよいですか？
A: 次の方法を使用して、プライマリノードの負荷を軽減します：
クラスターエンドポイントを使用して PolarDB クラスターに接続します。詳細については、「データベースプロキシを設定する」をご参照ください。
多くのトランザクションがプライマリノードに高い負荷をかけている場合は、コンソールでトランザクション分割機能を有効にできます。これにより、トランザクション内の一部のクエリが読み取り専用ノードにルーティングされます。詳細については、「高度なオプション—トランザクション分割」をご参照ください。
レプリケーション遅延のためにリクエストがプライマリノードにルーティングされる場合は、整合性レベルを下げること (たとえば、最終的な整合性を使用する) を検討してください。詳細については、「高度なオプション—整合性レベル」をご参照ください。
プライマリノードで読み取りリクエストを受け付けることも、高い負荷の原因となります。コンソールで「プライマリノードからの読み取りをオフロード」機能を有効にすると、プライマリノードにルーティングされる読み取りリクエストの数を減らすことができます。
Q: 挿入したばかりのデータを読み取れないのはなぜですか？
A: この問題は、整合性レベルの構成が原因である可能性があります。PolarDB のクラスターエンドポイントは、以下の整合性レベルに対応しています:
最終的な整合性：同じセッション (接続) 内でも、異なるセッションでも、新しく挿入されたデータをすぐに読み取れることを保証しません。
セッション整合性：同じセッション内で挿入されたデータを読み取れることを保証します。
説明整合性レベルが高いほど、パフォーマンスは低下し、プライマリノードへの負荷は大きくなります。慎重に選択してください。ほとんどのアプリケーションシナリオでは、セッション整合性でサービスの正常な動作が保証されます。強力な整合性が必要な少数のステートメントについては、ヒント
/* FORCE_MASTER */を使用できます。詳細については、「整合性レベル」をご参照ください。Q: SQL 文をプライマリノードで強制的に実行するにはどうすればよいですか？
クラスターエンドポイントを使用する場合、SQL 文の前に
/* FORCE_MASTER */または/* FORCE_SLAVE */を追加して、そのルーティング方向を強制します。詳細については、「カスタムルート—ヒント」をご参照ください。/* FORCE_MASTER */は、リクエストをプライマリノードに強制的にルーティングします。これは、高い整合性要件を持つ少数の読み取りリクエストに使用できます。/* FORCE_SLAVE */は、リクエストを強制的に読み取り専用ノードにルーティングします。これは、PolarDB プロキシが、正確性を確保するために読み取り専用ノードへのルーティングで特別な構文を必要とする、一部のシナリオで使用できます。例えば、ストアドプロシージャを呼び出す文やマルチステートメントを使用する文は、デフォルトでプライマリノードにルーティングされます。
説明ヒントは最高のルーティング優先度を持ち、整合性レベルやトランザクション分割に制約されません。使用前に評価してください。
ヒントステートメントに環境変数を変更するステートメント (
/*FORCE_SLAVE*/ set names utf8;など) を含めないでください。これらのタイプのステートメントは、予期しないクエリ結果につながる可能性があります。
Q: 異なるサービスに異なるエンドポイントを割り当てることはできますか？ 異なるエンドポイントで分離を実現できますか？
A: 異なるサービスに対して複数のカスタムエンドポイントを作成できます。基盤となるノードが異なる場合、カスタムエンドポイントは分離も提供し、互いに影響を与えません。カスタムエンドポイントの作成方法の詳細については、「データベースプロキシの設定」をご参照ください。
Q: 複数の読み取り専用ノードがある場合、そのうちの 1 つに対して個別のシングルノードエンドポイントを作成するにはどうすればよいですか？
A: シングルノードエンドポイントは、クラスターエンドポイントの読み書きモードが読み取り専用で、クラスターに 3 つ以上のノードがある場合にのみ作成できます。詳細な手順については、「データベースプロキシの設定」をご参照ください。
警告シングルノードエンドポイントが作成された後、このノードで障害が発生した場合、エンドポイントは最大 1 時間利用できなくなる可能性があります。本番環境では使用しないでください。
Q: 1 つのクラスターで作成できるシングルノードエンドポイントの最大数はいくつですか？
A: クラスターに 3 つのノードがある場合、読み取り専用ノードのうち 1 つに対してのみシングルノードエンドポイントを作成できます。クラスターに 4 つのノードがある場合、読み取り専用ノードのうち 2 つに対してシングルノードエンドポイントを作成できます。より多くのノードを持つクラスターにも同じロジックが適用されます。
Q: プライマリエンドポイントしか使用していませんが、読み取り専用ノードにも負荷がかかっているようです。プライマリエンドポイントも読み書き分離をサポートしていますか？
A: プライマリエンドポイントは読み書き分離をサポートしていません。常にプライマリノードにのみ接続します。読み取り専用ノードに小さな QPS (1 秒あたりのクエリ数) 負荷がかかるのは正常であり、プライマリエンドポイントとは無関係です。
管理とメンテナンス
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 リモートダイレクトメモリアクセス (RDMA) テクノロジーを使用しています。これにより、低レイテンシー、高スループットの強力な I/O パフォーマンスを提供します。
Q: PolarDB への外部接続の最大帯域幅はどのくらいですか？
A: PolarDB への外部接続の最大帯域幅は 10 Gbit/s です。
Q: ノードの再起動に時間がかかる場合はどうすればよいですか？
A: クラスター内のファイルが多いほど、ノードの再起動に時間がかかります。この場合、innodb_fast_startup パラメーターを ON に設定することで再起動を高速化できます。パラメーターの変更方法の詳細については、「クラスターおよびノードパラメーターの設定」をご参照ください。