すべてのプロダクト
Search
ドキュメントセンター

PolarDB:よくある質問

最終更新日:Nov 09, 2025

このトピックでは、PolarDB for PostgreSQL (Compatible with Oracle) に関するよくある質問への回答を提供します。

基本的な質問

  • Q: PolarDB とは何ですか?

    A: PolarDB は、世界中の 10 以上のリージョンにまたがるデータセンターにデプロイされたリレーショナルデータベースクラウドサービスであり、すぐに使えるオンラインデータベースサービスを提供します。PolarDB は、MySQL と 100% 互換、PostgreSQL と 100% 互換、Oracle 構文と高い互換性を持つ 3 つの独立したエンジンをサポートしています。最大 200 TB のストレージ容量を提供します。詳細については、「PolarDB for PostgreSQL (Compatible with Oracle) とは」をご参照ください。

  • Q: クラウドネイティブデータベース PolarDB が従来のデータベースより優れているのはなぜですか?

    A: 従来のデータベースと比較して、クラウドネイティブデータベース PolarDB は数百テラバイトのデータを保存でき、高い可用性と信頼性を提供し、高速な弾性スケーリングやロックフリーバックアップなどの機能をサポートします。詳細については、「メリット」をご参照ください。

  • Q: PolarDB はいつリリースされ、いつ商用化されましたか?

    A: PolarDB は 2017 年 9 月にパブリックプレビューとしてリリースされ、2018 年 3 月に商用化されました。

  • Q: クラスターとノードとは何ですか?

    A: PolarDB Cluster Edition は、マルチノードのクラスターアーキテクチャを使用します。クラスターには 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: いいえ、できません。購入後にクラスターのリージョンを変更することはできません。

  • Q: PolarDB には自動的にパーティショニングメカニズムが含まれていますか?

    A: はい。PolarDB はストレージレイヤーでデータをパーティショニングします。このプロセスはユーザーに対して透過的です。

  • Q: Single Node シリーズは、どのようにサービスの可用性とデータの信頼性を保証しますか?

    A: Single Node シリーズは、特定の目的のために単一の計算ノードを提供するデータベース製品です。ノードは 1 つしかありませんが、Single Node シリーズは、秒レベルの計算スケジューリングや分散マルチレプリカストレージなどの技術を使用して、高いサービスの可用性とデータの信頼性を保証します。

  • Q: シングルノードの PolarDB クラスターを購入するにはどうすればよいですか?

    A: Single Node 製品シリーズは提供を終了しました。ただし、クラスターを作成する際に [ノード数] を 0 に設定することで、シングルノードの PolarDB クラスターを購入できます。

料金

  • Q: PolarDB の料金には何が含まれますか?

    A: PolarDB の料金には、ストレージ容量、計算ノード、バックアップ (無料クォータを含む)、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: いいえ、すべての仕様を変更できるわけではありません。一時的なアップグレード中 (クラスターのステータスが `running` の場合)、手動アップグレードはサポートされています。ただし、手動ダウングレード、自動アップグレードまたはダウングレード、およびノードの追加または削除はサポートされていません。

  • 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 */ は、リクエストを強制的に読み取り専用ノードにルーティングします。これは、PolarProxy が正確性を確保するために読み取り専用ノードにルーティングされる特別な構文を必要とするいくつかのシナリオで使用できます。たとえば、ストアドプロシージャの呼び出しやマルチステートメントの使用は、デフォルトでプライマリノードにルーティングされます。

    説明
    • ヒントは最高のルーティング優先度を持ち、整合性レベルやトランザクション分割に制約されません。実装前にその使用を評価してください。

    • ヒントステートメントに GUC パラメーターを変更するステートメントを含めないでください。例: /*FORCE_SLAVE*/ set enable_hashjoin = off;。このようなステートメントは、予期しないクエリ結果を引き起こす可能性があります。

  • Q: 異なるサービスに異なるエンドポイントを割り当てることはできますか? これらのエンドポイントは互いに分離できますか?

    A: はい、できます。異なるサービスに対して複数のカスタムエンドポイントを作成できます。基盤となるノードが異なる場合、カスタムエンドポイントは分離を提供し、互いに影響しません。カスタムエンドポイントの作成方法の詳細については、「カスタムクラスターエンドポイントの作成」をご参照ください。

  • Q: 読み取り専用ノードが複数ある場合、特定の読み取り専用ノードのシングルノードエンドポイントを作成するにはどうすればよいですか?

    A: シングルノードエンドポイントは、クラスターエンドポイントの読み書きモードが読み取り専用で、クラスターに 3 つ以上のノードがある場合にのみ作成できます。詳細な手順については、「カスタムクラスターエンドポイントの作成」をご参照ください。

    警告

    シングルノードエンドポイントを作成した後、ノードに障害が発生した場合、エンドポイントは最大 1 時間利用できなくなる可能性があります。本番環境では使用しないでください。

  • Q: 1 つのクラスターで作成できるシングルノードエンドポイントの最大数はいくつですか?

    A: クラスターに 3 つのノードがある場合、読み取り専用ノードの 1 つに対してのみシングルノードエンドポイントを作成できます。クラスターに 4 つのノードがある場合、読み取り専用ノードの 2 つに対して別々のシングルノードエンドポイントを作成できます。以下同様です。

  • Q: プライマリエンドポイントしか使用していませんが、読み取り専用ノードにも負荷があります。プライマリエンドポイントも読み書き分離をサポートしていますか?

    A: いいえ、サポートしていません。プライマリエンドポイントは読み書き分離をサポートしておらず、常にプライマリノードにのみ接続します。読み取り専用ノードに少量の QPS があるのは正常であり、プライマリエンドポイントとは無関係です。

管理とメンテナンス

  • Q: プライマリノードと読み取り専用ノードの間にレプリケーション遅延はありますか?

    A: はい、ミリ秒レベルの遅延があります。

  • Q: レプリケーション遅延が増加する原因は何ですか?

    A: 次の状況により、レプリケーション遅延が増加する可能性があります。

    • プライマリノードの書き込み負荷が高く、読み取り専用ノードが時間内に適用するには多すぎる Redo ログが生成される。

    • 読み取り専用ノードの負荷が過度に高く、Redo ログの適用に元々割り当てられていたリソースを過剰に占有する。

    • I/O ボトルネックにより、Redo ログの読み取りと書き込みが遅くなる。

  • Q: レプリケーション遅延がある場合にクエリの一貫性を確保するにはどうすればよいですか?

    A: クラスターエンドポイントを使用し、適切な整合性レベルを選択できます。整合性レベルは高い順にセッションの一貫性、結果整合性です。詳細については、「データベースプロキシの設定」をご参照ください。

  • Q: 単一ノード障害が発生した場合、目標復旧時点 (RPO) 0 を保証できますか?

    A: はい、できます。

  • Q: 仕様のアップグレード (例: 2 コア 8 GB から 4 コア 16 GB へ) はバックエンドでどのように実装されますか? ビジネスへの影響は何ですか?

    A: PolarDB のプロキシとデータベースノードの両方を新しい構成にアップグレードする必要があります。ビジネスへの影響を最小限に抑えるために、複数のノードのローリングアップグレードが使用されます。各アップグレードには約 10 ~ 15 分かかります。ビジネスへの影響は 30 秒以内です。この期間中、1 ~ 3 回の一時的な切断が発生する可能性があります。詳細については、「構成を変更する」をご参照ください。

  • Q: ノードの追加にはどのくらいの時間がかかりますか? ビジネスに影響はありますか?

    A: ノードの追加には約 5 分かかり、ビジネスに影響はありません。ノードの追加方法の詳細については、「読み取り専用ノードの追加」をご参照ください。

    説明

    読み取り専用ノードが追加された後、新しい読み書き分離接続はそのノードにリクエストを転送します。新しい読み取り専用ノードが追加される前に確立された読み書き分離接続は、そのノードにリクエストを転送しません。これらの接続を切断して再確立する必要があります (たとえば、アプリケーションを再起動するなど)。

  • Q: 最新のマイナーバージョンへのアップグレードにはどのくらいの時間がかかりますか? ビジネスに影響はありますか?

    A: PolarDB は、ビジネスへの影響を最小限に抑えるために、複数のノードのローリングアップグレードを使用します。バージョンのアップグレードは通常 30 分以内で完了します。アップグレード中、データベースプロキシまたはデータベースカーネルエンジンが再起動され、一時的なデータベース接続が発生する可能性があります。アップグレードはオフピーク時に実行し、アプリケーションに自動再接続メカニズムがあることを確認することをお勧めします。詳細については、「マイナーバージョン管理」をご参照ください。

  • Q: 自動フェールオーバーはどのように機能しますか?

    A: PolarDB は、アクティブ/アクティブの高可用性クラスターアーキテクチャを使用します。自動フェールオーバーは、プライマリノードと読み取り専用ノードの間で発生します。システムは自動的に新しいプライマリノードを選出します。PolarDB の各ノードにはフェールオーバーの優先順位があり、フェールオーバー中に新しいプライマリノードとして選出される確率を決定します。複数のノードが同じ優先順位を持つ場合、それらはプライマリノードとして選出される確率が同じになります。詳細については、「自動または手動のプライマリ/セカンダリフェールオーバー」をご参照ください。

  • Q: データベースプロキシのアーキテクチャは何ですか? フェールオーバーメカニズムはありますか? 高可用性はどのように保証されますか?

    A: データベースプロキシは、デュアルノードの高可用性アーキテクチャを使用します。トラフィックは 2 つのプロキシノード間で均等に分散されます。システムはプロキシノードの正常性を継続的にチェックします。ノード障害が検出されると、そのノードへの接続は切断され、残りの正常なノードが自動的にすべてのトラフィックを引き継ぎ、サービスの継続性を確保します。その後、システムは障害のあるプロキシノードを自動的に再構築して回復します。このプロセスは通常約 2 分かかります。この間、データベースクラスターはアクセス可能なままです。

    まれに、障害のあるノードへの接続が時間内に切断されず、リクエストに応答できなくなることがあります。このような状況に対処するために、クライアント側で合理的なタイムアウトポリシー (JDBC の socketTimeoutconnectTimeout など) を設定することをお勧めします。これにより、アプリケーション層が中断された接続を迅速に検出して終了できるようになり、システムのフォールトトレランスと応答効率が向上します。

バックアップと回復

  • Q: PolarDB はどのバックアップ方法を使用しますか?

    A: PolarDB はバックアップにスナップショットを使用します。詳細については、バックアップ方法 2: 手動バックアップをご参照ください。

  • Q: データベースの回復速度はどのくらいですか?

    A: 現在、バックアップセット (スナップショット) からの回復 (クローニング) 速度は、1 テラバイト (TB) あたり 40 分です。特定の時点に復元する場合、Redo ログを適用するために必要な時間も含まれます。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 は分離されており、互いに影響しません。したがって、ノード間で I/O 競合は発生しません。

  • Q: 読み取り専用ノードのパフォーマンス低下はプライマリノードに影響しますか?

    A: はい。読み取り専用ノードの負荷が高い場合やレプリケーション遅延が増加した場合、プライマリノードのメモリ消費がわずかに増加する可能性があります。

  • Q: SQL Explorer (完全な SQL ログ監査) を有効にすることによるパフォーマンスへの影響は何ですか?

    A: パフォーマンスへの影響はありません。

  • Q: PolarDB はどの高速ネットワークプロトコルを使用していますか?

    A: PolarDB は、データベース計算ノードとストレージノード間、および保存されたデータの複数のレプリカ間で、デュアル 25 Gbps RDMA テクノロジーを使用しています。これにより、低遅延かつ高スループットで高い I/O パフォーマンスを提供します。

  • Q: PolarDB への外部接続の帯域幅制限はどのくらいですか?

    A: PolarDB へのインターネット接続の帯域幅制限は 10 Gbit/s です。