私はオンザフライでデータベース構成を作成するようなプロジェクトに取り組んでおり、mysqlインスタンスの読み取りレプリカの配列を取得し、それぞれに1つのオープン接続を維持し、そのサービスで静的を維持するため、クライアントが読み取りレプリカに接続しようとすると、忙しくないものを返します。
私の質問は、その公式はどうあるべきかということです。
これまでのところ変数は2つしかないので、その変数の改善も歓迎します。
同様のシナリオでクエリボリュームを管理するシステムを設計しました。さらにいくつかのものを含めることは興味深いかもしれません:
以前、各リソースに重みを付けてから、基本的にそれらを合計しました。したがって、単一のサーバーから戻ってくる可能性があります。
memory 50(%)
cpu 40(%)
disk 4000 (iops, if you know the limit here making it a % is good)
ms 300 (msecs average response time)
このサーバーの重みは4390になります(ここでは高いほど悪くなります)。ここで、CPUの問題が少ない場合は、計算でその「重み」を変更して、環境に合わせて使用するクライアントをより正確に決定できることがわかります。
これを収集する方法は、収集できる頻度と信頼性に違いをもたらす可能性があります(最も使用されていないサーバーのリストを作成してからノードが停止した可能性があります)。 1つのアプローチは、各候補に対してレポートデーモンを実行し、クライアント要求を受け取ったときに、おそらくマルチキャストを介してそれをクエリすることです。レポートデーモンは、統計を非常に頻繁に収集して、決定情報を可能な限り正確にすることができます。
生成している構成がどれほど一時的であるかは明確ではありません。これは、配布を行う際の重要な考慮事項です。クライアントを長期間接続しますか?サーバーが過負荷になったために、クライアントを切断して再配布する必要がある可能性はありますか?おそらくあなたはすでに考えたことがあるでしょう。
それがどれほど一時的であるか、およびクエリについてどれだけ知っているかに応じて、意思決定メトリックにさらにデータを追加することもできます。
うまくいけば、それが役立ちます!それは興味深い問題です。
簡単なスクリプトでそれを行うか、Nagiosプラグインを使用することができます。
check_ping または check_icmp
check_mysql_health 、次のようなもの:
define command { command_name check_mysql_health command_line $ USER1 $/check_mysql_health -t 20 --hostname $ HOSTADDRESS $ --port $ ARG1 $ --username $ ARG2 $ --password $ ARG3 $ --mode $ ARG4 $ --warning $ ARG5 $ --critical $ ARG6 $ } define service { use generic-service Host_name mysql_slave service_description MySQL_threads-connected check_command check_mysql_health!3306!user!password!threads-connected!30!40 }
define service { usecritical-service Host_name mysql_slave service_description MySQL_slave-io-running check_command check_mysql_health!3307! user!password!slave-io-running contact_groups admin-sms } define service { usecritical-service Host_name mysql_slave service_description MySQL_slave-sql-running check_command check_mysql_health!3307!user!password!slave-sql-running contact_groups admin-sms }