すべてのプロダクト
Search

このプロダクト

    PolarDB:よくある質問

    ドキュメントセンター

    PolarDB:よくある質問

    最終更新日:May 23, 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は、Java、Python、PHP、Golang、C、Cなどのプログラミング言語をサポートしています。NET、およびNode.js。 PolarDB for MySQLは、ネイティブMySQLと同じプログラミング言語をサポートしています。 詳細については、MySQL公式Webサイトをご覧ください。

    • サポートされているストレージエンジン

      PolarDBは4つのエディションをサポートしています。 次の項目では、さまざまなエディションでサポートされているストレージエンジンについて説明します。

      • PolarDB for MySQL Cluster EditionおよびSingle Node Editionのすべてのテーブルは、InnoDBストレージエンジンを使用します。 テーブルを作成すると、PolarDB for MySQLはMyISAM、Memory、CSVなどの非InnoDBエンジンをInnoDBエンジンに自動的に変換します。 したがって、InnoDBエンジンに格納されていないテーブルは、PolarDB for MySQLに移行できます。

      • デフォルトでは、PolarDB for MySQLはX-Engineを使用します。 X-Engineは強力なデータ圧縮機能を提供し、低ストレージコストでアーカイブデータベースを使用できます。 詳細については、「X-Engine Edition」をご参照ください。

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

      はい。PolarDBは、Parallel Raftプロトコルに基づく分散ストレージクラスタです。 コンピューティングエンジンは、異なるサーバーに分散された1〜16の計算ノードで構成されています。 クラスターは、最大200テラバイト、最大88コア、710 GBのメモリをサポートします。 ストレージとコンピューティングリソースをオンラインで動的にスケールアウトできます。 サービスはスケールアウト中に期待どおりに実行できます。

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

      はい。

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

      はい。

    • PolarDBは自動的にパーティショニングメカニズムを含みますか?

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

    • クラスターのエディションを変更できますか?

      はい、クラスターのエディションを変更できます。 次の表に、エディションを変更できるエディションを示します。

      エディション

      宛先エディション

      クラスターエディション

      単一ノードエディション

      X-Engineエディション

      ソース版

      クラスターエディション

      N/A

      非対応

      非対応

      単一ノードエディション

      非対応

      N/A

      非対応

      X-Engineエディション

      非対応

      非対応

      N/A

    • Single Node Editionは、サービスの可用性とデータの信頼性を確保する方法?

      Single Node Editionは、特定の目的のためにデータを格納するために使用され、1つの計算ノードのみを含みます。 Single Node Editionは、数秒以内のコンピューティングスケジューリングや分散マルチレプリカストレージなどの新しいテクノロジーを使用して、高いサービス可用性と高いデータ信頼性を確保します。

    互換性

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

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

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

      PolarDB for MySQLは、READ_UNCOMMITTED、READ_COMMITTED、REPEATABLE_READの3つの分離レベルをサポートしています。 デフォルトの分離レベルはREAD_COMMITTEDです。 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ステートメントとメタデータロックの実行ステータスの表示」をご参照ください。

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

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

    • パフォーマンススキーマと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は、コンピューティングがストレージから切り離されるアーキテクチャを使用します。 購入した読み取り専用ノードは、コンピューティングリソースとして使用されます。 したがって、記憶容量は増加しない。

      サーバーレスアーキテクチャはストレージに使用されます。 したがって、クラスターを購入するときにストレージ容量を指定する必要はありません。 ストレージ容量は、データ量が増加すると自動的にスケールアウトされます。 使用したストレージに対してのみ課金されます。 最大ストレージ容量は、クラスターの仕様によって異なります。 最大ストレージ容量を増やすには、クラスター仕様のアップグレードを行います。

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

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

    • 一時的なアップグレードがまだ有効な場合、クラスターの仕様を変更できますか。

      一時的なアップグレードがまだ有効な場合 (クラスターが実行中の状態) 、手動アップグレードを実行できます。 詳細については、「PolarDBクラスターの手動アップグレードまたはダウングレード」をご参照ください。 ただし、手動ダウングレード、自動構成変更、読み取り専用ノードの追加または削除の操作はサポートされていません。

    • PolarDBクラスターの最大パブリック帯域幅はどれくらいですか。 パブリック帯域幅の料金はかかりますか?

      PolarDBクラスターでは、パブリック帯域幅に制限はありません。 PolarDBクラスターの最大パブリック帯域幅は、使用するSLBサービスのパブリック帯域幅によって異なります。 PolarDBクラスターへのインターネット接続に対しては課金されません。

    • サブスクリプションクラスターの料金を毎日支払うのはなぜですか?

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

    • ApsaraDB RDSインスタンスがPolarDBクラスターに移行されたときに課金されますか。

      ApsaraDB RDSインスタンスがPolarDBクラスターに移行されても、課金されません。 ApsaraDB RDSインスタンスとPolarDBクラスターに対してのみ課金されます。

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

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

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

    • PolarDBで読み書き分離を実装する方法

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

      指定された整合性レベルでは、新しく挿入されたデータをすぐに取得できない可能性があります。 PolarDBのクラスターエンドポイントは、次の整合性レベルをサポートしています。

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

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

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

      説明

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

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

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

      • /* FORCE_MASTER * /は、要求をプライマリノードに強制的にルーティングするために使用されます。 この方法は、読み取り要求に強い一貫性が必要ないくつかのシナリオに適用されます。

      • /* FORCE_SLAVE * /は、リクエストを読み取り専用ノードに強制的にルーティングするために使用されます。 この方法は、PolarDBプロキシが、正確性を確保するために特別な構文を読み取り専用ノードにルーティングするよう要求するシナリオに適用されます。 たとえば、このメソッドを使用する場合、ストアドプロシージャを呼び出し、マルチステートメントを使用するステートメントは、既定で読み取り専用ノードにルーティングされます。

      説明

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

      • ヒントには、* 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のプロキシノードとデータベースノードを最新の設定にアップグレードする必要があります。 ローリングアップグレード方法は、サービスへの影響を最小限に抑えるために複数のノードをアップグレードするために使用されます。 各アップグレードには約10〜15分かかります。 サービスへの影響は30秒以内に続きます。 この期間中に、1〜3回の一時的な接続エラーが発生する可能性があります。 詳細については、「PolarDBクラスターの手動アップグレードまたはダウングレード」「」「」をご参照ください。

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

      ノードの追加には約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のパフォーマンスが大幅に向上しないのはなぜですか。

      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ではコンピューティングがストレージから切り離されているアーキテクチャが使用されており、ネットワークの待ち時間が単一のSQLステートメントの応答時間に影響するためです。 したがって、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文を実行して、データを直接コピーできます。

      テーブルBをselect * from Aとして作成

    安定性

    • 同時実行性の高いシナリオで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