すべてのプロダクト
Search

このプロダクト

    PolarDB:よくある質問

    ドキュメントセンター

    PolarDB:よくある質問

    最終更新日:Nov 13, 2024

    このトピックでは、PolarDB for MySQL に関するよくある質問に対する回答を提供します。

    基本

    • PolarDBとは

      PolarDBは、クラウドネイティブのリレーショナルデータベースサービスです。 PolarDBは、世界中の10を超えるリージョンのデータセンターに展開されています。 PolarDBは、すぐに使えるオンラインデータベースサービスを提供します。 PolarDBは3つの独立したエンジンをサポートします。 これにより、PolarDBはMySQLおよびPostgreSQLと完全に互換性があり、Oracle構文との互換性が高くなります。 PolarDBクラスターは、最大200テラバイトのストレージ容量を提供します。 詳細については、PolarDB for MySQL Enterprise Editionとは何ですか?をご参照ください。

    • PolarDBが従来のデータベースよりも優れているのはなぜですか。

      従来のデータベースと比較して、PolarDBは数百テラバイトのデータを保存できます。 また、高可用性、高信頼性、迅速な伸縮性のあるアップグレードとダウングレード、ロックフリーのバックアップなど、幅広い機能を提供します。 詳細については、「特典」「」「」をご参照ください。

    • PolarDBはいつリリースされましたか? それはいつ商用利用可能でしたか?

      PolarDBは2017年9月にパブリックプレビュー用にリリースされ、2018年3月に商用利用可能になりました。

    • クラスターとノードとは

      PolarDB Cluster Editionはマルチノードクラスタアーキテクチャを使用します。 クラスターには、1つのプライマリノードと複数の読み取り専用ノードがあります。 PolarDBクラスターは、ゾーン全体にデプロイできますが、リージョン全体にはデプロイできません。 PolarDBサービスは、クラスターレベルで管理および課金されます。 詳細については、用語をご参照ください。

    • PolarDBはどのプログラミング言語をサポートしていますか?

      PolarDBは、Java、Python、PHP、Golang、C、C++、.NETおよびNode.jsなどのプログラミング言語をサポートしています。ネイティブMySQLと対話できるプログラミング言語は、PolarDB for MySQLと直接対話できます。 詳細については、MySQL公式Webサイトをご覧ください。

    • PolarDBはどのストレージエンジンをサポートしていますか?

      PolarDB for MySQLには2つのエディションがあります。 使用可能なストレージエンジンは、エディションによって異なります。

      PolarDB for MySQL Cluster Editionは、すべてのテーブルに対してInnoDBストレージエンジンのみを使用します。 PolarDB for MySQLクラスターにテーブルを作成するときに、MyISAM、Memory、CSVなどのInnoDB以外のストレージエンジンを指定した場合、クラスターは自動的にストレージエンジンをInnoDBに変更します。 PolarDB for MySQLクラスターへの移行プロセスで、PolarDB for MySQLは非InnoDBストレージエンジンを使用するテーブルをInnoDBに変更し、スムーズな移行を保証します。

    • PolarDBは分散データベースですか?

      はい。PolarDBは、Parallel Raftコンセンサスプロトコルに基づく分散ストレージクラスターです。 そのコンピューティングエンジンは、異なるサーバーに分散された1〜16の計算ノードで構成されています。 クラスターの最大ストレージ容量は200テラバイト、最大88 CPUコアと710 GBのメモリです。 クラスターでは、ストレージとコンピューティングリソースのオンライン動的スケーリングが可能になり、スケーリングプロセス中に通常のビジネスオペレーションが影響を受けないようになります。

    • PolarDBを購入した後、シャーディングを実装するためにPolarDB-Xデータベースミドルウェアを購入する必要がありますか?

      はい。

    • PolarDBはテーブル分割をサポートしていますか?

      はい。

    • PolarDBにはデフォルトのパーティション分割メカニズムがありますか?

      PolarDBは、ストレージ層でパーティション分割を実装します。 これは透明であり、ユーザーには知覚できません。

    • 単一ノードクラスターでサービスの可用性とデータの信頼性を確保する方法?

      単一ノードクラスターは、特定の目的で単一の計算ノードを操作するように設計されています。 単一ノードのクラスターは、第2レベルのコンピューティングスケジューリングや分散マルチレプリカストレージなどのテクノロジーを使用して、高いサービス可用性と高いデータ信頼性を確保します。

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

      シングルノードクラスターは販売できなくなりました。 ただし、PolarDBクラスターの購入時に読み取り専用ノードの数を0に設定することで、シングルノードクラスターを作成できます。

    互換性

    • PolarDB for MySQLはMySQL Community Editionと互換性がありますか?

      はい、PolarDB for MySQLはMySQL Community Editionと完全に互換性があります。

    • サポートされているトランザクション分離レベル

      PolarDB for MySQLは、READ_UNCOMMITTED、READ_COMMITTED (デフォルト) 、およびREPEATABLE_READ分離レベルをサポートしていますが、SERIALIZABLE分離レベルはサポートしていません。

    • PolarDB for MySQLのSHOW PROCESSLISTステートメントのクエリ結果は、MySQL Community Editionのクエリ結果と同じですか。

      プライマリエンドポイントを使用してSHOW PROCESSLISTステートメントを実行すると、クエリ結果は同じになります。 クラスターエンドポイントを使用してSHOW PROCESSLISTステートメントを実行する場合、クエリ結果はPolarDB for MySQLとMySQL Community Editionで異なります。 PolarDB for MySQLのステートメントのクエリ結果では、同じスレッドIDを持つ複数のレコードを見つけることができます。 これらの各レコードは、PolarDB for MySQLクラスターのノードに対応しています。

    • PolarDB for MySQLのメタデータロック (MDL) メカニズムはMySQL Community Editionと同じですか?

      はい。PolarDB for MySQLのMDLロックメカニズムは、MySQL Community EditionのMDLロックメカニズムと同じです。 ただし、PolarDB for MySQLデータベースノードのアーキテクチャは共有ストレージに基づいています。 したがって、データ定義言語 (DDL) 操作がプライマリノードで実行されると、読み取り専用ノードがDDL操作の中間データにアクセスする可能性があり、データの不一致につながる可能性があります。 この問題を移行するために、PolarDB for MySQLはredoログを使用して、DDL操作に関与する専用MDLを読み取り専用ノードに同期します。 これにより、DDL操作中に読み取り専用ノード上の他のユーザースレッドがテーブルデータにアクセスできなくなります。 特定のシナリオでは、これはDDL動作をブロックし得る。 SHOW PROCESSLISTステートメントを実行して、DDL操作の状態を表示できます。 DDL操作がレプリカとの同期を待つ状態の場合、そのようなブロッキングが発生しています。 この問題を解決する方法については、「DDLステートメントの実行ステータスとMDLステータスの表示」をご参照ください。

    • PolarDB for MySQLのバイナリログ形式は、MySQLのネイティブバイナリログ形式と同じですか?

      はい。PolarDB for MySQLのバイナリログ形式は、MySQLのネイティブバイナリログ形式と同じです。

    • PolarDBはパフォーマンススキーマとsysスキーマをサポートしていますか?

      はい。

    • PolarDB for MySQLは、MySQL Community Editionと同じテーブル統計収集および更新メカニズムを使用していますか?

      はい、PolarDB for MySQLはMySQL Community Editionと同じテーブル統計収集および更新メカニズムを使用します。プライマリノードのテーブル統計の各更新は読み取り専用ノードに同期され、プライマリノードと読み取り専用ノード間で実行計画が一貫していることを確認します。 読み取り専用ノードでANALYZE TABLEステートメントを実行して、ディスクから最新の統計をプロアクティブにロードすることもできます。

    • PolarDBは拡張アーキテクチャ (XA) トランザクションをサポートしていますか? PolarDBはネイティブMySQLシステムと同じ方法でXAトランザクションをサポートしていますか?

      はい、PolarDBはネイティブMySQLシステムと同じ方法でXAトランザクションをサポートします。

    • PolarDBはフルテキストインデックスをサポートしていますか?

      はい。

      説明

      フルテキストインデックスを使用してデータをクエリする場合、インデックスキャッシュは読み取り専用ノードで使用されます。 インデックスキャッシュがあるため、インデックスに基づいて最新のデータを取得することはできません。 フルテキストインデックスに基づいてデータを読み書きするには、プライマリエンドポイントを使用することを推奨します。 これにより、最新のデータを確実に取得できます。

    • Percona Toolkitはサポートされていますか?

      はい、Percona Toolkitがサポートされています。 ただし、オンラインDDLの使用を推奨します。

    • gh-ostはサポートされていますか?

      はい、gh-ostはサポートされています。 ただし、オンラインDDLの使用を推奨します。

    課金

    • PolarDBクラスターの課金対象アイテムは何ですか。

      課金可能な項目には、ストレージスペース、計算ノード、データバックアップストレージ (無料クォータ付き) 、およびSQL Explorer機能 (オプション) が含まれます。 詳細については、「請求項目」「」「」をご参照ください。

    • 請求可能なストレージスペースに保存されているファイルはどれですか?

      請求可能なストレージスペースには、データベーステーブルファイル、インデックスファイル、アンドゥログファイル、redoログファイル、binlogファイル、slowlogファイル、および少数のシステムファイルが格納されます。 詳細については、「ストレージ料金の概要」「」「」をご参照ください。

    • PolarDBのストレージプランを使用する方法?

      ストレージプランを使用して、サブスクリプションまたは従量課金クラスターのストレージ料金を相殺できます。 たとえば、3つのクラスターがあり、それぞれのストレージ容量は40 GBで、合計容量は120 GBになります。 3つのクラスターには100 GBのストレージプランを使用できます。 次に、従量課金制で20 GBを超えるストレージに対して課金されます。 詳細については、「ストレージプランの購入」「」「」をご参照ください。

    • クラスターに読み取り専用ノードを追加した場合、どのように課金されますか?

      読み取り専用ノードの価格は、プライマリノードの価格と同じです。 詳細については、「コンピュートノードの料金」「」「」をご参照ください。

    • 読み取り専用ノードを追加すると、ストレージ容量は2倍になりますか?

      いいえ、読み取り専用ノードを追加してもストレージ容量は2倍になりません。 PolarDBは、コンピューティングがストレージから切り離されるアーキテクチャを使用します。 購入した読み取り専用ノードは、コンピューティングリソースとして使用されます。 したがって、記憶容量は増加しない。

      サーバーレスモードはストレージに使用されます。 そのため、クラスターを購入する際にストレージ容量を指定する必要はありません。 データ量が増加すると、ストレージ容量は自動的に拡張されます。 使用したストレージに対して課金されます。 最大ストレージ容量は、クラスターの仕様によって異なります。 最大ストレージ容量を増やす方法については、「クラスターの仕様を手動で変更する」「」「」をご参照ください。

    • 従量課金クラスターの料金を請求できなくなるにはどうすればよいですか?

      クラスターが不要になった場合は、クラスターをリリースできます。 詳細については、「クラスターのリリース」をご参照ください。 クラスターをリリースすると、クラスターに対して課金されなくなります。

    • 一時的なアップグレードプロセス中にクラスターの仕様を変更できますか?

      一時的なアップグレードプロセス中 (クラスターが実行中) 、クラスターの仕様を手動でアップグレードできますが、クラスターの仕様を手動でダウングレードしたり、クラスター仕様の自動スケーリングを許可したり、読み取り専用ノードの追加または削除 します。

    • PolarDBクラスターのパブリック帯域幅とは パブリック帯域幅の料金はかかりますか?

      PolarDBクラスターでは、パブリック帯域幅に制限はありません。 PolarDBクラスターのパブリック帯域幅は、使用するSLBサービスの帯域幅によって異なります。 PolarDBクラスターのパブリック帯域幅は課金されません。

    • サブスクリプションクラスターの請求書が毎日生成されるのはなぜですか?

      PolarDBクラスターの課金対象項目には、主に計算ノード (プライマリノードと読み取り専用ノード) 、ストレージスペース、無料クォータを超えたデータバックアップストレージ、SQL Explorer (オプション) 、およびGDN (オプション) が含まれます。 詳細については、「請求項目」をご参照ください。 サブスクリプション課金方法を使用する場合、クラスターの購入時にコンピュートノードの前払いが必要です。 前払いには、ストレージスペース、データバックアップストレージ、およびSQL Explorerの料金は含まれません。 ストレージ料金は、1時間ごとの実際のストレージ使用量に基づいて発生します。 したがって、サブスクリプションの課金方法が使用されている場合でも、従量課金の請求書が生成されます。

    • ApsaraDB RDSインスタンスをPolarDBクラスターに移行するために課金されますか。

      いいえ。ApsaraDB RDSインスタンスをPolarDBクラスターに移行する場合は課金されません。 ApsaraDB RDSインスタンスとPolarDBクラスターに対してのみ課金されます。

    • DELETEステートメントを実行してPolarDBのテーブルのデータを削除した後も、特定のテーブルが使用するストレージスペースに対して課金されるのはなぜですか。

      DELETEステートメントは、テーブルに削除マーカーを追加するだけです。 テーブルスペースは解放されません。

    クラスタアクセス (読み書き分離)

    • PolarDBで読み書き分離を実装する方法を教えてください。

      クラスターエンドポイントに設定された読み取り /書き込みモードに基づいて読み取り /書き込み分割を実装できるように、アプリケーションでクラスターエンドポイントを指定するだけで済みます。 詳細については、「PolarProxyの設定」「」「」をご参照ください。

    • PolarDBクラスターでサポートされている読み取り専用ノードの数

      PolarDBは分散クラスターアーキテクチャを使用します。 1 つのクラスターは、1 つのプライマリノードと最大 15 の読み取り専用ノードで構成されます。 高可用性を確保するには、少なくとも1つの読み取り専用ノードが必要です。

    • 読み取り専用ノード間で負荷が不均衡になるのはなぜですか?

      考えられる理由の1つは、読み取り専用ノードへの接続が少数しか存在しないことです。 もう1つの考えられる理由は、読み取り専用ノードの1つが、使用するカスタムクラスターエンドポイントに関連付けられていないことです。

    • プライマリノードの重い負荷または軽い負荷の原因は何ですか?

      次の原因により、プライマリノードに重い負荷が発生する可能性があります。 プライマリエンドポイントは、アプリケーションをクラスターに接続するために使用されます。 2. プライマリノードは読み取り要求を受け入れます。 3. 多数のトランザクション要求が存在する。 4. プライマリ /セカンダリレプリケーションの遅延が大きいため、リクエストはプライマリノードにルーティングされます。 5. 読み取り要求は、読み取り専用ノードの例外により、プライマリノードにルーティングされます。

      プライマリノードの負荷が軽い原因は、プライマリノードからのリードのオフロード機能が有効になっていることです。

    • クラスターのプライマリノードの負荷を減らすにはどうすればよいですか。

      次の方法を使用して、クラスターのプライマリノードの負荷を軽減できます。

      • クラスターエンドポイントを使用して、PolarDBクラスターに接続できます。 詳細については、「PolarProxyの設定」「」「」をご参照ください。

      • 多数のトランザクションがプライマリノードに大きな負荷をかける場合は、コンソールでトランザクション分割機能を有効にできます。 このようにして、トランザクション内のクエリの一部が読み取り専用ノードにルーティングされます。 詳細については、「トランザクション分割」「」「」をご参照ください。

      • レプリケーションの遅延が原因でリクエストがプライマリノードにルーティングされる場合、整合性レベルを下げることができます。 たとえば、最終的な整合性レベルを使用できます。 詳細については、「一貫性レベル」「」「」をご参照ください。

      • プライマリノードが読み取り要求を受け入れると、プライマリノードの負荷も重くなる可能性があります。 この場合、プライマリノードがコンソールで読み取り要求を受け入れることを許可する機能を無効にすることができます。 これにより、プライマリノードにルーティングされる読み取り要求の数が減少します。 詳細については、「プライマリノードが読み取り要求を受け入れる」をご参照ください。

    • 新しく挿入されたデータをすぐに取得できないのはなぜですか?

      この問題は、整合性レベルの設定によって引き起こされる可能性があります。 PolarDBクラスターのクラスターエンドポイントは、次の整合性レベルをサポートしています。

      • 最終的な一貫性: この一貫性レベルでは、同じセッション (接続) に基づくか異なるセッションに基づくかに関係なく、新しく挿入されたデータをすぐに取得できることは保証されません。

      • セッションの整合性: この整合性レベルでは、同じセッションに基づいて新しく挿入されたデータをすぐに取得できます。

      • グローバル整合性: この整合性レベルにより、同じセッションまたは異なるセッションに基づいて最新のデータをすぐに取得できます。

      説明

      整合性レベルが高いと、プライマリノードの負荷が大きくなります。 これにより、プライマリノードのパフォーマンスが低下します。 整合性レベルを選択するときは注意が必要です。 ほとんどのシナリオでは、セッションの整合性レベルによってサービスの可用性が保証されます。 強力な一貫性を必要とするいくつかのSQL文については、/* FORCE_MASTER */ ヒントをSQL文に追加して、一貫性レベルの要件を満たすことができます。 詳細については、「一貫性レベル」「」「」をご参照ください。

    • SQL文をプライマリノードで強制的に実行するにはどうすればよいですか。

      クラスターエンドポイントを使用する場合は、SQL文の前に /* FORCE_MASTER */ または /* FORCE_SLAVE */ を追加して、SQL文のルーティング場所を強制的に指定できます。 詳細については、「ヒント」「」「」をご参照ください。

      • is used to forcibly route requests to the primary node. この方法は、読み取り要求に強い一貫性が必要ないくつかのシナリオに適用されます。

      • is used to forcibly route requests to read-only nodes. この方法は、正確性を確保するために特別な構文を読み取り専用ノードにルーティングする必要があるシナリオに適用されます。 たとえば、ストアドプロシージャを呼び出し、複数のステートメントを使用するステートメントは、デフォルトで読み取り専用ノードにルーティングされます。

      説明

      • ヒントは、ルーティングのために最高の優先順位が割り当てられ、一貫性レベルまたはトランザクション分割によって制限されません。 ヒントを使用する前に、ビジネスへの影響を評価してください。

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

    • 異なるサービスに異なるエンドポイントを割り当てることはできますか? 異なるエンドポイントを使用してサービスを分離できますか?

      はい、複数のカスタムエンドポイントを作成し、それらを異なるサービスに割り当てることができます。 基になるノードが異なる場合、カスタムクラスタエンドポイントを使用してサービスを分離でき、相互に影響を与えることはありません。 カスタムエンドポイントの作成方法については、「カスタムクラスターエンドポイントの作成」「」「」をご参照ください。

    • 複数の読み取り専用ノードが存在する場合、読み取り専用ノードの1つに単一ノードのエンドポイントを個別に作成するにはどうすればよいですか。

      クラスターエンドポイントの読み取り /書き込みモードパラメーターが読み取り専用に設定されており、クラスターに3つ以上のノードがある場合にのみ、シングルノードエンドポイントを作成できます。 詳細については、「クラスターエンドポイントの設定」「」「」をご参照ください。

      警告

      ただし、読み取り専用ノードに単一ノードのエンドポイントを作成し、読み取り専用ノードに障害が発生した場合、単一ノードのエンドポイントが最大1時間使用できなくなる可能性があります。 運用環境では、単一ノードのエンドポイントを作成しないことをお勧めします。

    • クラスターに作成できる単一ノードエンドポイントの最大数はいくつですか。

      クラスターに3つのノードがある場合、読み取り専用ノードの1つにのみシングルノードエンドポイントを作成できます。 クラスターに4つのノードがある場合、読み取り専用ノードのうち2つ (それぞれに1つ) に単一ノードのエンドポイントを作成できます。 クラスターに5つ以上のノードがある場合も同様のルールが適用されます。

    • プライマリエンドポイントのみを使用すると、読み取り専用ノードに負荷がかかります。 プライマリエンドポイントは読み書き分離をサポートしていますか?

      いいえ、プライマリエンドポイントは読み書き分離をサポートしていません。 プライマリエンドポイントは常にプライマリノードにのみ接続されます。 読み取り専用ノードには、1秒あたりのクエリ数 (QPS) が少ない場合があります。 これは通常のケースであり、プライマリエンドポイントとは無関係です。

    管理とメンテナンス

    • オンラインでフィールドとインデックスを追加するにはどうすればよいですか?

      MySQLのネイティブオンラインDDL、pt-osc、gh-ostなどのツールを使用して、フィールドとインデックスをオンラインで追加できます。 MySQLのネイティブオンラインDDLを使用することを推奨します。

      説明

      pt-oscを使用する場合は、再帰メソッドパラメーターなど、プライマリノードと読み取り専用ノード間のデータの整合性を確認するためのパラメーターを使用しないでください。 これは、pt-oscがbinlogレプリケーションに基づいてプライマリノードと読み取り専用ノード間のデータの一貫性をチェックするためです。 ただし、PolarDBは物理レプリケーションを使用し、binlogレプリケーションをサポートしません。

    • 一括挿入機能はサポートされていますか?

      はい。

    • 書き込み専用ノードにのみデータを書き込む場合、データを一括挿入できますか? 一度に挿入できる値の最大数はいくつですか?

      はい。書き込み専用ノードにのみデータを書き込む場合は、データを一括挿入できます。 一度に挿入できる値の最大数は、max_allowed_packetパラメーターの値によって決まります。 詳細については、「レプリケーションとmax_allowed_packet」をご参照ください。

    • クラスターエンドポイントを使用して一括挿入操作を実行できますか。

      はい。

    • プライマリノードから読み取り専用ノードにデータをレプリケートすると、レプリケーションの遅延が発生しますか。

      はい、数ミリ秒のレプリケーション遅延が発生します。

    • レプリケーション遅延はいつ増加しますか?

      次のシナリオでは、レプリケーション遅延が増加します。

      • プライマリノードは、多数の書き込み要求を処理し、過剰なredoログを生成します。 その結果、これらのredoログは、時間内に読み取り専用ノードで再生できません。

      • 重い負荷を処理するために、読み取り専用ノードは、redoログの再生に使用される多数のリソースを占有します。

      • I/Oのボトルネックにより、システムは低レートでredoログを読み書きします。

    • レプリケーション遅延が発生した場合にクエリ結果の一貫性を確保するにはどうすればよいですか。

      クラスターエンドポイントを使用し、クラスターエンドポイントに適切な整合性レベルを選択できます。 次の一貫性レベルが降順でリストされています: グローバル一貫性 (強い一貫性) 、セッション一貫性、および最終的な一貫性。 詳細については、「一貫性レベル」「」「」をご参照ください。

    • 1つのノードに障害が発生した場合、回復ポイント目標 (RPO) をゼロにできますか?

      はい。

    • たとえば、ノード仕様を2コアと8 GBのメモリから4コアと16 GBのメモリにアップグレードするなど、ノード仕様はバックエンドでどのようにアップグレードされますか? アップグレードはサービスにどのような影響を与えますか?

      PolarDBのPolarProxyおよびデータベースノードを最新の設定にアップグレードする必要があります。 ローリングアップグレード方法は、サービスへの影響を最小限に抑えるために複数のノードをアップグレードするために使用されます。 各アップグレードには約10〜15分かかります。 サービスへの影響は30秒以内に続きます。 この期間中に、1〜3回の一時的な接続エラーが発生する可能性があります。 詳細については、「クラスターの仕様を手動で変更する」「」「」をご参照ください。

    • ノードの追加にはどのくらい時間がかかりますか? ノードが追加されると、サービスは影響を受けますか?

      ノードの追加には約5分かかります。 ノードが追加されても、サービスは影響を受けません。 ノードの追加方法については、「読み取り専用ノードの追加」「」「」をご参照ください。

      説明

      読み取り専用ノードを追加すると、読み取り専用ノードにリクエストを転送するための読み書き分離接続が確立されます。 読み取り専用ノードが追加される前に作成された読み書き分離接続は、要求を読み取り専用ノードに転送しません。 接続を閉じて、再度接続を確立する必要があります。 たとえば、アプリケーションを再起動して接続を確立できます。

    • カーネルマイナーバージョンを最新のリビジョンバージョンに更新するのにどれくらい時間がかかりますか? 更新が完了すると、サービスは影響を受けますか?

      PolarDBはローリング更新方法を使用して複数のノードをアップグレードし、サービスへの影響を最小限に抑えます。 ほとんどの場合、更新が完了するまでに30分未満かかります。 PolarProxyまたはデータベースエンジンは、アップグレード中に再起動されます。 これは、サービスを中断し得る。 オフピーク時に更新を実行することを推奨します。 アプリケーションがデータベースに自動的に再接続できることを確認します。 詳細については、「マイナーバージョンの更新」「」「」をご参照ください。

    • 自動フェールオーバーはどのように実装されますか?

      PolarDBは、アクティブ-アクティブ高可用性アーキテクチャを使用します。 プライマリノードに障害が発生すると、システムは自動的に読み取り専用ノードから新しいプライマリノードを選択し、元のプライマリノードから新しいプライマリノードへのサービスをフェールオーバーします。 フェールオーバーの優先度は、PolarDBクラスター内の各ノードに割り当てられます。 優先順位は、フェイルオーバー中にどのノードをプライマリノードとして選択できるかを決定する。 複数のノードが同じフェールオーバー優先度を持つ場合、それらは同じ確率でプライマリノードとして選択されます。 詳細については、「自動フェールオーバーと手動フェールオーバー」「」「」をご参照ください。

    バックアップと復元

    • PolarDBはどのようにデータをバックアップしますか?

      PolarDBはスナップショットを使用してデータをバックアップします。 詳細については、「バックアップ方法1: 自動バックアップ」および「バックアップ方法2: 手動バックアップ」をご参照ください。

    • データベースはどれくらい速く復元できますか?

      バックアップセットまたはスナップショットに基づいて、データベース内の1テラバイトのデータを復元または複製するには40分かかります。 特定の時点にデータを復元する場合は、redoログの再生に必要な時間を含める必要があります。 1 GBのredoログデータを再生するには、約20〜70秒かかります。 合計復元時間は、バックアップセットに基づいてデータを復元するのに必要な時間と、redoログを再生するのに必要な時間の合計です。

    パフォーマンスと容量

    • PolarDB for MySQLクラスターがApsaraDB RDS for MySQLインスタンスよりも大幅なパフォーマンス改善を示さないのはなぜですか。

      PolarDB for MySQLクラスターのパフォーマンスとApsaraDB RDS for MySQLインスタンスのパフォーマンスを比較する前に、正確で合理的なパフォーマンス比較結果を得るために、次の考慮事項に注意してください。

      • PolarDB for MySQLクラスターとApsaraDB RDS for MySQLインスタンスが同じ仕様を使用していることを確認します。

      • PolarDB for MySQLクラスターとApsaraDB RDS for MySQLインスタンスが同じバージョンであることを確認します。

        その理由は、実装メカニズムがバージョンによって異なるためです。 たとえば、MySQL 8.0は、Log_writer、log_fluser、log_checkpoint、log_write_notifierなどのスレッドを個別に抽象化することにより、マルチコアCPUを最適化します。 ただし、少数のCPUコアのみを使用する場合、MySQL 8.0のパフォーマンスはMySQL 5.6またはMySQL 5.7のパフォーマンスよりも低くなります。 PolarDB for MySQL 5.6とApsaraDB RDS for MySQL 5.7または8.0を比較しないことを推奨します。 これは、PolarDB for MySQL 5.6のオプティマイザが、それ以降のバージョンのPolarDB for MySQLほど機能しないためです。

      • 実際のオンライン環境で負荷をシミュレートするか、sysbenchベンチマークスイートを使用してパフォーマンスを比較することを推奨します。 これにより、得られたパフォーマンスデータが実際のオンラインシナリオで得られたものに近くなります。

      • PolarDB for MySQLとApsaraDB RDS for MySQLの読み取りパフォーマンスを比較するために、単一のSQL文を使用しないことを推奨します。

        これは、PolarDBでは、コンピューティングがストレージから切り離されたアーキテクチャが使用されているため、ネットワーク通信による単一クエリのレイテンシが増加するためです。 したがって、PolarDB for MySQLの読み取りパフォーマンスは、ApsaraDB RDS for MySQLの読み取りパフォーマンスよりも低くなります。 オンラインデータベースのキャッシュヒット率は、ほとんどの場合、99% を超えています。 最初の読み取り要求のみがI/Oリソースを消費し、読み取りパフォーマンスが低下します。 後続の読み取り要求は、データがバッファプールに格納されているため、I/Oリソースを消費しません。 後続の読み取り要求に対して、PolarDB For MySQLとApsaraDB RDS for MySQLは同じ読み取りパフォーマンスを提供します。

      • 書き込みパフォーマンスを比較するために単一のSQL文を使用しないことをお勧めします。 代わりに、本番環境をシミュレートし、ストレステストを実行することを推奨します。

        パフォーマンスを比較するために、PolarDBのプライマリノードと読み取り専用ノードをApsaraDB RDS for MySQLのプライマリインスタンスと読み取り専用インスタンスと比較することを推奨します。 半同期レプリケーションは、ApsaraDB RDS for MySQLの読み取り専用インスタンスに実装されています。 これは、PolarDBのアーキテクチャがデフォルトでデータ書き込みに定足数メカニズムを使用するためです。 データが3重のうちの2つまたは3重のすべてに書き込まれた場合、システムは、書き込み動作が成功したと判断する。 PolarDBは、ストレージ層でデータの冗長性を実装し、3重に強い一貫性と高い信頼性を保証します。 したがって、適切な比較方法は、非同期レプリケーションではなく半同期レプリケーションが実装されているApsaraDB RDS for MySQLとPolarDB for MySQLを比較することです。

      PolarDB For MySQLとApsaraDB RDS for MySQLのパフォーマンス比較結果の詳細については、「PolarDB for MySQLとApsaraDB RDS for MySQLのパフォーマンス比較」をご参照ください。

    • 削除されたデータベースが大量のストレージスペースを占有するのはなぜですか?

      これは、削除されたデータベースのredoログファイルがストレージ領域を占有するためです。 ほとんどの場合、redoログファイルは2 GBから11 GBのストレージスペースを占有します。 合計11 GBのストレージスペースが占有されている場合、バッファプール内の8つのredoログファイルによって8 GBのストレージスペースが占有されます。 残りの3 GBのストレージスペースは、書き込まれているredoログファイル、事前に作成されたredoログファイル、および最新のredoログファイルによって均等に占有されます。

      loose_innodb_polar_log_file_max_reuseパラメーターは、バッファープール内のredoログファイルの数を指定します。 このパラメーターのデフォルト値は8です。 このパラメーターの値を変更して、ログファイルが占有するストレージ容量を減らすことができます。 この場合、重い負荷が処理されると、周期的なパフォーマンス変動が発生する可能性があります。

      loose_innodb_polar_log_file_max_reuse

    • テーブルの最大数は何ですか? パフォーマンスが損なわれないようにするには、テーブルの数の上限は何ですか?

      テーブルの最大数は、ファイルの数に依存します。 詳細については、「制限」をご参照ください。

    • テーブルパーティションはPolarDBのクエリパフォーマンスを改善できますか?

      ほとんどの場合、SQLクエリ文がパーティションに含まれる場合、パフォーマンスを向上させることができます。

    • PolarDBクラスターに10,000データベースを作成できますか。 PolarDBクラスター内のデータベースの最大数はいくつですか。

      はい、PolarDBクラスターに10,000データベースを作成できます。 作成できるデータベースの最大数は、ファイルの数によって異なります。 詳細については、「制限」をご参照ください。

    • 接続の最大数は読み取り専用ノードの数に依存しますか? 読み取り専用ノードを追加して最大接続数を増やすことはできますか?

      読み取り専用ノードの数は、最大接続数とは無関係です。 PolarDBの最大接続数は、ノードの仕様によって決まります。 詳細については、「制限」をご参照ください。 さらに接続が必要な場合は、仕様をアップグレードします。

    • 1秒あたりの入出力操作 (IOPS) はどのように制限され、分離されますか? PolarDBクラスターの複数のノードがI/Oリソースを求めて競合しますか。

      IOPSは、ノードの仕様に基づいてPolarDBクラスターの各ノードに指定されます。 各ノードのIOPSは、他のノードのIOPSから分離され、互いに影響を及ぼさない。

    • 読み取り専用ノードのパフォーマンスが低下した場合、プライマリノードは影響を受けますか。

      はい。読み取り専用ノードの負荷が過度に重く、レプリケーション遅延が増加すると、プライマリノードのメモリ消費量がわずかに増加します。

    • バイナリログ機能を有効にすると、データベースのパフォーマンスにどのような影響がありますか。

      バイナリログ機能を有効にすると、書き込みと更新 (INSERT、update、およびDELETE) のパフォーマンスのみが影響を受けます。 クエリ (SELECT) のパフォーマンスには影響しません。 ほとんどの場合、読み取り要求と書き込み要求のバランスが取れているデータベースでバイナリログ機能を有効にした場合、データベースのパフォーマンスは10% 以下低下します。

    • SQL Explorer (完全なSQLログ監査) 機能を有効にすると、データベースのパフォーマンスにどのような影響がありますか。

      SQL Explorer機能を有効にしても、データベースのパフォーマンスは影響を受けません。

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

      PolarDBは、デュアルポートRDMA (Remote Direct Memory Access) を使用して、計算ノードとストレージノード間、およびデータレプリカ間の高いI/Oスループットを保証します。 各ポートは、低レイテンシで最大25 Gbit/sのデータレートを提供します。

    • インターネットからPolarDBにアクセスする場合に使用できる最大帯域幅はどれくらいですか?

      インターネットからPolarDBにアクセスする場合、最大帯域幅は10 Gbit/sです。

    大きなテーブル

    • 従来のデータベースのローカルディスクに対するPolarDB for MySQLの大きなテーブルの利点は何ですか?

      PolarDB for MySQLデータベース内の大きなテーブルは、N個の物理ストレージサーバーに分割されて保存されます。 したがって、大きなテーブルのI/O操作は複数のディスクに割り当てられます。 PolarDB for MySQLデータベースのI/O読み取り操作の全体的なスループット (I/Oレイテンシではなく) は、すべてのI/O操作がローカルディスクにスケジュールされているデータベースのスループットよりも高くなります。

    • 大きなテーブルを最適化する方法?

      大きなテーブルを最適化するには、パーティションテーブルを使用することを推奨します。

    • パーティションテーブルのアプリケーションシナリオは何ですか?

      大きなテーブルをプルーニングしてクエリのスキャンデータ量を制御し、ビジネスコードを変更しない場合は、パーティションテーブルを使用できます。 たとえば、パーティション分割テーブルを使用して、サービスの履歴データを定期的に消去できます。 最初の月に作成されたパーティションを削除し、次の月のパーティションを作成して、最新の6か月のデータのみを保持できます。

    • たとえば、テーブルaのすべてのデータをテーブルBにコピーするなど、同じPolarDB for MySQLデータベースに大量のデータがあるテーブルをコピーする場合、どのような方法が適していますか?

      次のSQL文を実行して、データを直接コピーできます。

      create table B as select * from A

    安定性

    • 同時実行性の高いシナリオでPHPの短期間の接続を最適化できますか?

      はい、同時実行性の高いシナリオでPHP短期接続を最適化できます。PHP短期接続を最適化するには、クラスターエンドポイントの設定でセッションレベルの接続プールを有効にします。 詳細については、「クラスターエンドポイントの指定」「」「」をご参照ください。

    • 低速SQLクエリがデータベース全体のパフォーマンスを低下させないようにするにはどうすればよいですか?

      PolarDB for MySQL 5.6または8.0クラスターを使用する場合、ステートメント同時実行制御機能を使用して、指定されたSQLステートメントにレート制限とスロットリングを実装できます。 この機能の詳細については、「同時実行制御」をご参照ください。

    • PolarDBはアイドルセッションタイムアウト機能をサポートしていますか?

      はい。 wait_timeoutパラメーターの値を変更して、アイドルセッションのタイムアウト期間を指定できます。 詳細については、「クラスターパラメーターとノードパラメーターの指定」をご参照ください。

    • 低速SQLクエリを識別する方法を教えてください。

      次の2つの方法を使用して、低速SQLクエリを識別できます。

      • コンソールで低速SQLクエリを取得します。 詳細については、「低速SQLクエリ」をご参照ください。

      • データベースクラスターに接続し、SHOW PROCESSLISTステートメントを実行して、実行に時間がかかるSQLステートメントを見つけます。 データベースクラスターへの接続方法の詳細については、「クラスターへの接続」をご参照ください。发现慢SQL

    • 低速SQLクエリを終了するにはどうすればよいですか?

      低速SQLクエリを識別したら、低速SQLクエリのIDを見つけ、kill <Id> コマンドを実行してSQLクエリを終了します。终止慢SQL

    データライフサイクル管理

    • PolarDB for MySQLクラスターは、ホットデータとウォームデータをコールドデータとしてアーカイブする方法を教えてください。

      PolarDB for MySQLクラスターは、InnoDBエンジンを使用して保存されたホットデータと、X-engineを使用して保存されたwarmデータを、データ定義言語 (DDL) ポリシーを使用してCSVまたはORC形式のコールドデータとしてPolarStoreからObject Storage Service (OSS) にアーカイブできます。 このアーカイブにより、PolarStoreのストレージスペースが効果的に解放され、データベースストレージ全体のコストが削減されます。 詳細については、「コールドデータの手動アーカイブ」をご参照ください。

    • PolarDB for MySQLクラスターは、ホット、ウォーム、コールドデータの自動分離とアーカイブをサポートしていますか?

      PolarDB for MySQLクラスターは、ホット、ウォーム、コールドデータの自動分離とアーカイブをサポートしています。 データライフサイクル管理 (DLM) ポリシーを設定して、PolarStoreから低コストのOSSストレージへのデータの自動アーカイブを実装できます。 これにより、データベースのストレージコストが削減され、ストレージ効率が向上します。 詳細については、「コールドデータの自動アーカイブ」をご参照ください。