Enterprise Manager: ComcastによるMySQL InnoDBクラスタのモニタリングの拡張方法 (2024/04/22)

Enterprise Manager: ComcastによるMySQL InnoDBクラスタのモニタリングの拡張方法 (2024/04/22)

https://blogs.oracle.com/observability/post/enterprise-manager-how-comcast-enhanced-monitoring-for-mysql-innodb-clusters

投稿者: Desiree Abrokwa | Product Manager, Enterprise and Cloud Manageability


ゲスト著者:Charles Ju、エンジニア5、テクノロジ・オペレーション、Comcast、Nirup Sama、エンジニア3、ソフトウェア開発およびエンジニアリング、Comcast


Comcastは、世界中の何億人ものお客様にコネクティビティ、エンターテイメント、スポーツ、ニュース、エクスペリエンスを提供する、世界有数のメディアおよびテクノロジー企業です。ComcastのDBAチームは、堅牢で可用性の高いOracle Enterprise Manager(EM)インフラストラクチャを導入し、大規模なOracle Database DBaaS操作のプロビジョニング、パッチ適用、監視、サポートを行っています。Enterprise EditionのMySQLデータベースを監視するために、EMを使用して、個別のMySQL Enterprise Monitor (MEM)インフラストラクチャを設定するのではなく、信頼性の高いインフラストラクチャを活用することを決定しました。


このブログでは、メトリック拡張を使用して、InnoDBクラスタ・メンバー・ノードがオフラインまたはイジェクトされたときに監視およびアラートを発するソリューションを共有しています。


一般的なMySQL InnoDBクラスタは、3つ以上の個別のMySQL Serverノードで構成されます。MySQL InnoDBクラスタは、MySQL Group Replicationテクノロジを使用して、クラスタ・メンバー・ノード間の仮想同期レプリケーションと、組込みの競合検出または処理、およびすべてのクラスタ・ノード間での一貫性の保証を提供します。また、自動メンバーシップ管理、フォルト・トレランス、自動フェイルオーバーなどの機能も提供します。


図1: MySQL InnoDBクラスタ・アーキテクチャ


ネットワークの問題などの様々な理由により、MySQL InnoDBクラスタ・メンバー・ノードが特定の時間枠内に他のメンバー・ノードと通信できない場合があります。これにより、InnoDBクラスタ・メンバー・ノードがイジェクトされる場合があります。当社のDBAチームは、EMがこのような問題を検出し、DBAチームにアラートを送信して、対応する修正アクションをできるだけ早く実行できるようにすることを希望しています。MySQLのEMでは、現在この監視機能が提供されていないため、このようなInnoDBクラスタの問題を取得するための独自のメトリック拡張を開発しました。



ComcastがMySQL InnoDBクラスタのメトリック拡張を作成した方法


最初に、InnoDBクラスタ・メンバー・ノードのステータスを検出するカスタム・スクリプトを作成しました。カスタム・スクリプトのロジックを次に説明します。


次の疑似コードは、InnoDBクラスタ・メンバー・ノードのステータスを検出するために使用されます。メンバー・ノードのステータスがOFFLINEの場合、MySQL InnoDBクラスタからイジェクトされたことを意味します。

ClusterMemberState=Get-InnoDBCluster-Member-State 

if [ -z "$ClusterMemberState" ]
then
    if [[ -s /tmp/temp_master_status ]];then
        echo "ONLINE"
    else
        echo "OFFLINE"
    fi
else
    echo "$ClusterMemberState"
fi


次に、EMを使用して、カスタム・スクリプトを使用してメトリック拡張を定義しました。メトリック拡張定義の最初のページで、MySQL Databaseターゲット・タイプであるOSコマンド・アダプタを選択し、15分ごとに収集スケジュールを設定します。


図2: メトリック拡張に対して定義されたMySQLターゲット・タイプ、OSコマンド・アダプタおよび収集スケジュール




2番目のステップでは、カスタム・スクリプトをメトリック拡張にアップロードしました。


図3: メトリック拡張にアップロードされたカスタム・スクリプト




3番目のステップでは、スクリプトから返されたInnoDBメンバー・ノード・ステータスを含む新しいメトリック列を作成しました。ノード・ステータスは「ONLINE」または「OFFLINE」のいずれかになります。ノード・ステータスがオンラインでない場合にトリガーするクリティカル・アラートを指定しました。


図4: InnoDBメンバー・ノードのステータスを含むように定義されたメトリック列




既存のターゲットに対してメトリック拡張をテストして、スクリプトが正しいメンバー・ノード・ステータスを返していることを確認しました。


図5: メトリック拡張スクリプトが既存のターゲットに対して正常にテストされました




結果をテストして確認した後、一般的な使用のためにメトリック拡張を公開しました。


図6: 公開されたメトリック拡張




新しいMySQLデータベースへのメトリック拡張のデプロイメントを自動化するために、メトリック拡張をデフォルトのMySQLモニタリング・テンプレートに追加しました。


図7: デフォルトのMySQLモニタリング・テンプレートに追加されたメトリック拡張




最後に、InnoDBクラスタ・メンバーがクラスタから取り出されるたびに、DBAチームに通知を送信するようにインシデント・ルールを更新しました。


Enterprise Managerおよびメトリック拡張を使用して、MySQL InnoDBクラスタのフリートに影響を与える可能性のある問題を事前に監視します。これにより、DBAチームは、当社のビジネスに必要な可用性の高いMySQLデータベースを維持できます。


リソース


詳細は、次を参照してください。

コメント

このブログの人気の投稿

Oracle RACによるメンテナンスのためのドレインとアプリケーション・コンティニュイティの仕組み (2023/11/01)

Oracle Cloud Infrastructure Secure Desktopsを発表: デスクトップ仮想化のためのOracleのクラウドネイティブ・サービス (2023/06/28)

Oracle Cloudのデータベースをオブジェクト・ストレージにバックアップする3つの方法 (2021/12/13)