Azure Database for MySQL - Flexible Server でのサーバー運用のベスト プラクティス
Azure Database for MySQL フレキシブル サーバーを使用する場合のベスト プラクティスについて説明します。 Microsoft は、プラットフォームに新しい機能を追加していく中で、このセクションで詳しく説明するベスト プラクティスを改善することに注力していきます。
Azure Database for MySQL フレキシブル サーバーの運用ガイドライン
Azure Database for MySQL フレキシブル サーバーを使用してデータベースのパフォーマンスを向上させるために従う必要がある運用ガイドラインを次に示します。
コロケーション: ネットワーク待ち時間を短縮するために、クライアントとデータベース サーバーを同じ Azure リージョンに配置します。
メモリ、CPU、ストレージ使用を監視する: システムのパフォーマンスと可用性を維持できるようにするために、使用パターンが変化したとき、またはデプロイの容量に近づいたときに通知を受け取るようにアラートを設定できます。
ログの高速化によるパフォーマンス向上: 高速ログ機能を有効にすると、トランザクション ログ関連の操作が最適化され、サーバーのスループットとパフォーマンスが向上します。 追加コストなしで利用できるこの機能は、Business Critical サービス レベルの利用者にとって、運用ベスト プラクティスの追加項目として重要です。
DB インスタンスのスケールアップ: ストレージ容量の上限に近づいてきたらスケールアップできます。 アプリケーションからの予期しない需要増加に対応するために、ストレージとメモリにはある程度の余裕を持たせる必要があります。 また、ストレージの上限に近づいたときに、サービスによってストレージが自動的にスケーリングされるようにするために、ストレージの自動拡張機能を "オン" にすることもできます。
バックアップを構成する:ビジネスの要件に基づいて、ローカルまたは geo 冗長バックアップを有効にします。 また、バックアップがビジネス継続性のために利用できる期間に基づいて、保有期間を変更します。
自動スケール IOPS による I/O キャパシティの最適化: データベース ワークロードにより、プロビジョニングしたよりも多くの I/O が必要になる場合、データベースの復旧またはその他のトランザクション操作は低速になります。 サーバー インスタンスの I/O 容量を増やすには、次のいずれかを実行します。
自動スケール IOPS を使用する: 自動スケール IOPS を使用すると、1 秒あたりの特定の数の I/O 操作を事前にプロビジョニングする必要がなくなります。 代わりに、お使いのサーバーでは、ワークロード要件に基づいて IOPS を自動調整できるようになります。 つまり、ワークロードのニーズに応じて、サーバーで IOPS を自動的にスケール アップまたはスケール ダウンできます。
Azure Database for MySQL フレキシブル サーバーは、プロビジョニングされた GB ストレージあたり 3 IOPS の比率での IOPS スケーリングを提供します。 パフォーマンスを向上させるために、プロビジョニングされたストレージを増やして IOPS をスケーリングします。
プロビジョニングされた IOPS ストレージを既に使用している場合は、追加のスループット容量をプロビジョニングします。
コンピューティングをスケーリングする:また、データベースのワークロードは、CPU またはメモリが原因で制限されることがあります。これにより、トランザクション処理に重大な影響が及ぶ可能性があります。 Compute (価格レベル) は、汎用またはメモリ最適化サービス レベル間でのみスケールアップまたはスケールダウンできることに注意してください。
フェールオーバーのテスト:サーバー インスタンスのフェールオーバーを手動でテストして、自分のユース ケースに対してプロセスでどの程度時間がかかるか把握します。また、サーバー インスタンスにアクセスするアプリケーションがフェールオーバー後に新しいサーバー インスタンスに自動的に接続できることを確認します。
主キーの使用: Azure Database for MySQL フレキシブル サーバー インスタンスで操作を行うときに、テーブルに主キーまたは一意キーがあることを確認します。 これにより、バックアップやレプリカなどの作成に大いに役立ち、パフォーマンスを向上させることができます。
TTL 値を構成する:クライアント アプリケーションがサーバー インスタンスのドメイン ネーム サービス (DNS) データをキャッシュする場合は、有効期限 (TTL) の値を 30 秒未満に設定します。 フェールオーバー後にサーバー インスタンスの基になる IP アドレスが変更される可能性があります。このため、DNS データを長期間キャッシュすると、アプリケーションがサービスに存在しなくなった IP アドレスに接続しようとした場合に接続エラーが発生する可能性があります。
接続プールを使用して接続数の上限に達しないようにします。また、再試行ロジックを使用して断続的な接続の問題を回避します。
レプリカを使用する場合は、プライマリ サーバーと読み取り可能なセカンダリ レプリカ サーバーの間で負荷を分散させるために ProxySQL を使用します。 セットアップ手順については、こちらを参照してください。
リソースをプロビジョニングする際に、Azure Database for MySQL フレキシブル サーバー インスタンスの自動拡張を有効にしたことを確認してください。 これによって、追加コストが発生することはなく、発生する可能性があるストレージのボトルネックからデータベースが保護されます。
Azure Database for MySQL フレキシブル サーバーで InnoDB を使用する
ibdata1機能を使用する場合、システム テーブルスペースのデータ ファイルは、テーブルからデータを削除したり、file-per-tabletablespacesにテーブルを移動したりしても、圧縮または消去することはできません。データベースのサイズが 1 TB を超える場合は、innodb_file_per_table
tablespaceでテーブルを作成する必要があります。 1 つのテーブル サイズが 1 TB を超える場合は、パーティション テーブルを使用する必要があります。多数の
tablespaceがあるサーバーでは、Azure Database for MySQL フレキシブル サーバーの起動時またはフェールオーバー時のシーケンシャル テーブルスペース スキャンが原因でエンジンの起動が非常に低速になります。テーブルの合計数が 500 未満の場合は、テーブルを作成する前に innodb_file_per_table = ON を設定します。
データベースに 500 を超えるテーブルがある場合は、個々のテーブルのテーブル サイズを確認します。 大規模なテーブルの場合でも、システム テーブルスペース ファイルが最大ストレージ制限に達しないようにするために、file-per-table テーブルスペースを使用することを検討してください。
注意
サイズが 5 GB 未満のテーブルの場合は、システム テーブルスペースを使用することを検討してください。
CREATE TABLE tbl_name ... *TABLESPACE* = *innodb_system*;
1 TB を超える可能性がある大規模なテーブルがある場合は、テーブルの作成時にテーブルをパーティション分割します。
複数の Azure Database for MySQL フレキシブル サーバー インスタンスを使用し、それらのサーバー間でテーブルを分散します。 約 10,000 以上のテーブルがある場合、1 つのサーバーにテーブルを配置しすぎないようにしてください。