MySQL の高可用性 MMM 構築計画とアーキテクチャ原理の詳細説明_MySQL

まず、以下に示すアーキテクチャを見てみましょう:

展開

1. ホストを変更する

すべてのサーバーで同じ操作を実行します。

vim /etc/hosts

リーリー

2. mysql ユーザーを追加します

監視側ではなく、すべてのデータベース側で実行するだけで済みます。

リーリー

注: repl ユーザーは、マスター/スレーブ サービスの構築時にすでに作成されています。

3. 監視ソフトウェアをインストールします

注: すべての監視端末がインストールされていますが、監視端末は mysql-mmm-monitor を使用するだけでよく、mysql-mmm-agent を起動する必要はありません。

データベース側では、mysql-mmm-agent をインストールするだけです

1.監視サーバー上で実行します

リーリー

2. データベースサーバーで実行します。すべてのデータベースサーバーで実行する必要があります

リーリー

パスの説明:

4. 設定ファイル

dbサーバー設定ファイル: mmm_agent.conf，mmm_common.conf

監視サーバーの設定ファイル: mmm_mon.conf，mmm_common.conf (このファイルはすべてのサーバーで同じです)

データベースサーバーを構成する

1.マスターサーバーを変更します

リーリー

リーリー

同時に、このファイルを監視サーバーを含む他のサーバーにコピーしても、構成は変更されません

リーリー

2. プロキシファイルの設定

vim /etc/mysql-mmm/mmm_agent.conf

注: この設定は db サーバーを設定するだけであり、これ以降のホスト名は現在のサーバーの host コマンドに変更され、master2 とslave もサーバーのホスト名に変更されます。対応するサーバー。

3. エージェントプロセスを開始します

リーリー

リーリー

各DBサーバーで起動する必要があります

監視サーバーを構成する

リーリー

リーリー

注: 構成ファイル内のコメントは、理解を容易にするためのものであり、コメントによる潜在的な影響を避けるために、展開中にコメントを削除することをお勧めします。

モニタリングプロセスを開始

リーリー

注: DB 側でも監視側でも、設定ファイルが変更された場合は、エージェント プロセスと監視プロセスを再起動する必要があります。

動作分析

ログファイル

ログ ファイルはエラー分析の鍵となることが多いため、ログ ファイルを使用して問題を分析することに熟達している必要があります。

データベース側：/var/log/mysql-mmm/mmm_agentd.log

監視端末：/var/log/mysql-mmm/mmm_mond.log

コマンドファイル

mmm_agentd: DB エージェントプロセスの起動ファイル

mmm_mond: 監視プロセスの起動ファイル

mmm_backup: バックアップ ファイル

mmm_restore: ファイルを復元します

mmm_clone

mmm_control: 監視操作コマンドファイル

DB サーバー側には mmm_agentd プログラムのみがあり、その他はモニター サーバー側にあります。

mmm_control の使用法

mmm_control プログラムは、クラスターのステータスの監視、ライターの切り替え、オンラインおよびオフライン操作の設定などに使用できます。

リーリー

1. すべての DB サーバークラスターのステータスを確認します

リーリー

チェック項目には、ping、mysqlが正常に実行されているか、コピースレッドが正常かなどがあります。

2. クラスター環境のオンライン状態を確認します

リーリー

3. 指定したホストでオフライン操作を実行します

リーリー

4. 指定されたホスト上で 1 つの操作を実行します

リーリー

5.書き込み切り替えを実行します

1. 現在のスレーブに対応するマスターを表示します

リーリー

2.ライターの切り替え、mmm_common.conf ファイルのライター属性に対応するホストが設定されていることを確認してください。そうでない場合は切り替えられません

リーリー

3.保存はライブラリから新しいマスターに自動的に切り替わります

リーリー

その他の処理の問題

 如果不想让writer从master切换到backup（包括主从的延时也会导致写VIP的切换），那么可以在配置/etc/mysql-mmm/mmm_common.conf时，去掉3612df8997eca9306e1f789dddf71f78中的backup

<role writer> ####writer角色配置
 hosts master ###这里只配置一个Hosts
 ips  192.168.137.100 #####对外提供的写操作的虚拟IP
 mode exclusive #####exclusive代表只允许存在一个主，也就是只能提供一个写的IP
</role>

 这样的话当master出现故障了writer写操作不会切换到backup服务器，并且slave也不会指向新的master，此时当前的MMM之前对外提供写服务。

总结

主从的延时会导致写VIP的切换。

       1.对外提供读写的虚拟IP是由monitor程序控制。如果monitor没有启动那么db服务器不会被分配虚拟ip,但是如果已经分配好了虚拟ip当monitor程序关闭了原先分配的虚拟ip不会立即关闭外部程序还可以连接访问（只要不重启网络），这样的好处就是对于monitor的可靠性要求就会低一些，目前还不知道能维持多长的时间，但是如果这个时候其中的某一个db服务器故障了就无法处理切换，也就是原先的虚拟ip还是维持不变，挂掉的那台DB的虚拟ip会变的不可访问。

       2.agent程序受monitor程序的控制处理write切换，从库切换等操作。如果monitor进程关闭了那么agent进程就起不到什么作用，它本身不能处理故障。

       3.monitor程序负责监控db服务器的状态，包括Mysql数据库、服务器是否运行、复制线程是否正常、主从延时等；它还用于控制agent程序处理故障。

       4.monitor会每隔几秒钟监控db服务器的状态，如果db服务器已经从故障变成了正常，那么monitor会自动在60s之后将其设置为online状态(默认是60s可以设为其它的值)，有监控端的配置文件参数“auto_set_online”决定，群集服务器的状态有三种分别是：HARD_OFFLINE→AWAITING_RECOVERY→online

       5.默认monitor会控制mmm_agent会将writer db服务器read_only修改为OFF，其它的db服务器read_only修改为ON,所以为了严谨可以在所有的服务器的my.cnf文件中加入read_only=1由monitor控制来控制writer和read,root用户和复制用户不受read_only参数的影响

以上就是本文的全部内容，希望本文对大家学习mysql有所帮助。