22_MySQL高可用性-デュアルマスター（keepalived）

実稼働環境のmysqlホストには単一障害点があるため、mysqlの高可用性を確保する必要があります。つまり、2つのMySQLサーバーの一方がダウンした場合、もう一方がすぐに引き継ぐことができます。

一般に、MySQLにはいくつかの高可用性ソリューションがあります。
キープアライブ+デュアルマスター、MHA、PXC、MMM、ハートビート+ DRBDなどです。より一般的に使用されるソリューションは、キープアライブ+デュアルマスター、MHA、PXCです。

このセクションでは、主に、MySQLデータベースの高可用性を実現するためのkeepalivedの使用法を紹介します。Keepalived + mysqlデュアルマスターでMySQL-HAを実現するには、2つのMySQLデータベースのデータが完全に同じであることを確認する必要があります。基本的な考え方は、2つのMySQLが互いにマスタースレーブ関係にあることです。Keepalivedを使用して仮想IPを構成します。 MySQLデータベースの1つがダウンしたことを認識します。マシンの後、アプリケーションは自動的に別のMySQLデータベースに切り替えて、システムの高可用性を確保できます。

周囲：

mysql1	192.168.1.65	mysql、keepalived
mysql2	192.168.1.67	mysql、keepalived

1.2つのMySQLマスターとマスター同期を構成します

プロセスの最初の部分は、マスターがバイナリログを記録することです。各トランザクションがデータを更新する前に、マスターはこれらの変更をバイナリログに記録します。MySQLはトランザクションをバイナリログに書き込みます。イベントがバイナリログに書き込まれた後、マスターはストレージエンジンにトランザクションをコミットするように通知します。次のステップは、スレーブがマスターのバイナリログを自身のリレーログにコピーすることです。

まず、スレーブはワーカースレッド（I / Oスレッド）を開始します。I / Oスレッドは、マスターで通常の接続を開き、binlogダンププロセスを開始します。ビンログダンププロセスは、マスターのバイナリログからイベントを読み取ります。マスターが同期されている場合、マスターはスリープ状態になり、マスターが新しいイベントを生成するのを待ちます。I / Oスレッドは、これらのイベントをリレーログに書き込みます。SQLスレーブスレッドは、プロセスの最後のステップを処理します。SQLスレッドは、リレーログからイベントを読み取り、その中のイベントを再生し、スレーブのデータを更新して、マスター内のデータと一致するようにします。スレッドがI / Oスレッドと一致している限り、リレーログは通常OSキャッシュに配置されるため、リレーログのオーバーヘッドは小さくなります。

マスター-マスター同期は、互いのマスターとしての2台のマシン間の関係であり、任意の1台のマシンでの書き込みが同期されます。mysqlホストでファイアウォールがオンになっている場合は、ファイアウォールをオフにするか、ルールを作成する必要があります。

1. MySQL構成ファイルを変更します。両方のMySQLでbinlogログ機能を有効にする必要があります。有効にする方法：MySQL構成ファイルの[MySQL]セクションにlog-bin = MySQL-binオプションを追加します。 2つのMySQLを同じにすることはできません。デフォルトこの場合、両方のMySQLサーバーのserverIDは1であり、そのうちの1つを2に変更する必要があります。

master1の関連する構成は次のとおりです。

log-bin = mysql-bin
binlog_format = mixed
server-id = 1
relay-log = relay-bin
relay-log-index = slave-relay-bin.index
auto-increment-increment = 2
auto-increment-offset = 1
!重启MySQL

master2の関連する構成は次のとおりです。

log-bin = mysql-bin
binlog_format = mixed
server-id = 2
relay-log = relay-bin
relay-log-index = slave-relay-bin.index
auto-increment-increment = 2
auto-increment-offset = 2
!重启MySQL

注：master1とmaster2は、server-idとauto-increment-offsetのみが異なります。

mysqlには自動インクリメントフィールドがあり、データベースのメイン同期を実行するときに、自動インクリメントの2つの関連する構成（
auto_increment_offset、auto_increment_increment）を設定する必要があります。auto-increment-incrementは、毎回の自己インクリメントフィールドのインクリメントを表し、デフォルト値は1です。その値は、構造全体のサーバーの総数に設定する必要があります。この場合、2つのサーバーが使用されるため、値は2に設定されます。auto-increment-offsetは、データベースの自動拡張の開始点（初期値）を設定するために使用されます。これは、2つのサーバーが自動拡張値2を設定しているため、2つのプライマリを回避するために開始点が異なる必要があるためです。サーバーデータの同期中にキーの競合が発生する

注：my.cnfファイルに「binlog_do_db = databasename」構成項目（複数追加できます）を追加して、同期するデータベースを指定できます。

2. master1
をmaster2のマスターサーバーとして設定します。master1ホストで許可されたアカウントを作成し、master2（192.168.1.67）ホストでの接続を許可します。

mysql> grant replication slave on *.* to rep@'192.168.1.67' identified by '123.com';
Query OK, 0 rows affected, 1 warning (0.01 sec)

mysql> flush privileges;
Query OK, 0 rows affected (0.00 sec)

// master1の現在のbinlogステータス情報を表示します

mysql> show master status;
+------------------+----------+--------------+------------------+-------------------+
| File             | Position | Binlog_Do_DB | Binlog_Ignore_DB | Executed_Gtid_Set |
+------------------+----------+--------------+------------------+-------------------+
| mysql-bin.000002 |      609 |              |                  |                   |
+------------------+----------+--------------+------------------+-------------------+
1 row in set (0.00 sec)

// master1をmaster2上の独自のマスターサーバーとして設定し、スレーブ機能を有効にします。

mysql> change master to
    -> master_host='192.168.1.65',
    -> master_user='rep',
    -> master_password='123.com',
    -> master_log_file='mysql-bin.000002',
    -> master_log_pos=609;
Query OK, 0 rows affected, 2 warnings (0.02 sec)

mysql> start slave;
Query OK, 0 rows affected (0.01 sec)

// master1はファイアウォール通信を設定します

[root@mysqld01 ~]# firewall-cmd --add-port=3306/tcp --permanent 
success
[root@mysqld01 ~]# firewall-cmd --reload 
success

//スレーブのステータスを表示します。次の2つの値はyesである必要があります。これは、スレーブサーバーがマスターサーバーに正常に接続できることを意味します。

mysql> show slave status\G
...
             Slave_IO_Running: Yes
            Slave_SQL_Running: Yes
   .....         

3. master2
をmaster1のマスターサーバーとして設定します。master2ホストで許可されたアカウントを作成し、master1（192.168.1.65）ホストでの接続を許可します。

mysql> grant replication slave on *.* to rep@'192.168.1.65' identified by '123.com';
Query OK, 0 rows affected, 1 warning (0.00 sec)

// master2のbinlogステータスを表示します

mysql> show master status;
+------------------+----------+--------------+------------------+-------------------+
| File             | Position | Binlog_Do_DB | Binlog_Ignore_DB | Executed_Gtid_Set |
+------------------+----------+--------------+------------------+-------------------+
| mysql-bin.000002 |      452 |              |                  |                   |
+------------------+----------+--------------+------------------+-------------------+
1 row in set (0.00 sec)

// master2をmaster1の独自のマスターサーバーとして設定し、スレーブ機能をオンにします

mysql> change master to
    -> master_host='192.168.1.67',
    -> master_user='rep',
    -> master_password='123.com',
    -> master_log_file='mysql-bin.000002',
    -> master_log_pos=452;
Query OK, 0 rows affected, 2 warnings (0.01 sec)

mysql> start slave;
Query OK, 0 rows affected (0.00 sec)

// master2はファイアウォール通信を設定します

[root@mysql02 ~]# firewall-cmd --add-port=3306/tcp --permanent 
success
[root@mysql02 ~]# firewall-cmd --reload 
success

//スレーブステータスを表示します

mysql> show slave status\G
....
             Slave_IO_Running: Yes
            Slave_SQL_Running: Yes
.....

4.テストこれ
までのところ、mysqlのデュアルマスター構成は
完了しています。//master1でziライブラリを作成し、master2で表示および削除します。

mysql> create database zi;

master2で表示および削除

mysql> show databases;
+--------------------+
| Database           |
+--------------------+
| information_schema |
| mysql              |
| mytest             |
| performance_schema |
| sys                |
| zi                 |
+--------------------+
6 rows in set (0.01 sec)

mysql> drop database zi;
Query OK, 0 rows affected (0.01 sec）

master1のライブラリをチェックすると、ziライブラリがなくなっていることがわかります。

mysql> show databases;
+--------------------+
| Database           |
+--------------------+
| information_schema |
| mysql              |
| mytest             |
| performance_schema |
| sys                |
+--------------------+
5 rows in set (0.00 sec)

簡単に理解すると、master1の操作はmaster2に同期され、同じmaster2の操作はmaster1に同期されます。

注：マスターMYSQLサーバーがすでに存在し、スレーブMYSQLサーバーが後でのみ構築される場合は、データ同期を構成する前に（データベースのバックアップなど）、同期するデータベースをマスターMYSQLサーバーからスレーブMYSQLサーバーにコピーする必要があります。最初にマスターMYSQLで、バックアップを再利用してMYSQLサーバーから復元します）

次に、keepalivedのインストールと構成

次に、keepalivedの高可用性を完成させます。Keepalivedは、クラスター管理におけるクラスターの高可用性を確保するためのソフトウェアソリューションです。その機能はハートビートに似ています。単一障害点を防ぐために使用されます。KeepalivedはVRRPプロトコルの実装に基づいています。VRRPはVirtualRouterの略です。冗長プロトコル、つまり仮想ルーター冗長プロトコル。

仮想ルーティング冗長プロトコルは、ルーターの高可用性を実現するためのプロトコルと見なすことができます。つまり、ルーターグループから同じ機能を提供するN個のルーターがあります。このグループには、マスターと複数のバックアップがあります。マスターには、サービスを提供するVIPがあります。マスターはマルチキャストを送信します（マルチキャストアドレスは224.0.0.18です）。バックアップがvrrpパケットの受信に失敗した場合、マスターはダウンしていると見なされます。このとき、バックアップを選択する必要があります。 VRRPの優先順位に従ってマスターになります。このようにして、ルーターの高可用性を保証できます。

Keepalivedには、主にコア、チェック、vrrpの3つのモジュールがあります。コアモジュールはkeepalivedのコアであり、メインプロセスの起動と保守、およびグローバル構成ファイルのロードと分析を担当します。チェックは、さまざまな一般的なチェック方法を含むヘルスチェックを担当します。vrrpモジュールは、VRRPプロトコルを実装するためのものです。

1.
keepalivedソフトウェアパッケージをmaster1とmaster2にインストールします。keepalivedソフトウェアパッケージとサービスコントロールをインストールします。Keepalivedをコンパイルしてインストールする前に、まずカーネル開発パッケージkernel-develをインストールし、openssl-develやpopt-develなどのライブラリをサポートする必要があります。 。

yum install kernel-devel openssl-devel popt-devel
yum -y install keepalived.x86_64 

キープアライブをインストールするソースパッケージに注意してください：キープアライブに必要な依存関係がわからない場合は、ダウンロードしたソースコード解凍ディレクトリに移動して、INSTALLファイルの内容を表示できます。makeinstall操作を実行した後、 /etc/init.d/keepalivedスクリプトファイルは自動的に生成されますが、サービスおよびchkconfigツールを使用してkeepalivedサービスプログラムを管理できるように、手動でシステムサービスとして追加する必要もあります。

Master2ホストも、master1と同じように、キープアライブインストールを完了します。インストールプロセスは省略されます。

//スプリットブレインを防ぐためにファイアウォールを設定します

firewall-cmd --direct --permanent --add-rule ipv4 filter INPUT 0  --destination 224.0.0.18 --protocol vrrp -j ACCEPT
firewall-cmd --reload

2. Keepalivedの構成ファイルの変更
Keepalivedには、keepalived.confが1つだけあります。これには、主に次の構成領域、つまりglobal_defs、vrrp_instance、およびvirtual_serverが含まれます。

global_defs：障害が発生したときに、主に通知オブジェクトとマシンIDを構成します。
vrrp_instance：外部サービスのVIPエリアとそれに関連する属性を定義するために使用されます。
virtual_server：仮想サーバーの定義

キープアライブ構成ファイルの説明は次のとおりです。

! Configuration File for keepalived   //!表示注释
global_defs {
    
    
 router_id MYSQL-1  //表示运行keepalived服务器的一个标识
}
vrrp_instance VI_1 {
    
    
 state BACKUP //指定keepalived的角色, 两台配置此处均是BACKUP,设为BACKUP将根据优先级决定主或从
 interface ens33//指定HA监测网络的接口
 virtual_router_id 51 //虚拟路由标识，这个标识是一个数字(取值在0-255之间,用来区分多个instance的VRRP组播)，同一个vrrp实例使用唯一的标识,确保和master2相同，同网内不同集群此项必须不同,否则发生冲突。
 priority 100 //用来选举master的，要成为master，该项取值范围是1-255（在此范围之外会被识别成默认值100）,此处master2上设置为50
 advert_int 1 //发VRRP包的时间间隔，即多久进行一次master选举（可以认为是健康查检时间间隔）
 nopreempt //不抢占，即允许一个priority比较低的节点作为master，即使有priority更

 authentication {
    
     //认证区域，认证类型有PASS和HA（IPSEC），推荐使用PASS（密码只识别前8位）
 auth_type PASS
 auth_pass 1111
 }
 virtual_ipaddress {
    
     //VIP区域，指定vip地址
 192.168.1.100
 }
}


virtual_server 192.168.1.100 3306 {
    
     //设置虚拟服务器，需要指定虚拟IP地址和服务端口，IP与端口之间用空格隔开
 delay_loop 2 //设置运行情况检查时间，单位是秒
 lb_algo rr //设置后端调度算法，这里设置为rr，即轮询算法
 lb_kind DR //设置LVS实现负载均衡的机制，有NAT、TUN、DR三个模式可选
 persistence_timeout 60 //会话保持时间，单位是秒。这个选项对动态网页是非常有用的，为集群系统中的session共享提供了一个很好的解决方案。有了这个会话保持功能，用户的请求会被一直分发到某个服务节点，直到超过这个会话的保持时间。
 protocol TCP //指定转发协议类型，有TCP和UDP两种
 
 real_server 192.168.1.65 3306 {
    
     //配置服务节点1，需要指定real server的真实IP地址和端口，IP与端口之间用空格隔开

 weight 3 //配置服务节点的权值，权值大小用数字表示，数字越大，权值越高，设置权值大小为了区分不同性能的服务器
 notify_down /etc/keepalived/bin/mysql.sh //检测到realserver的mysql服务down后执行的脚本
 TCP_CHECK {
    
    
 connect_timeout 3 //连接超时时间
 nb_get_retry 3 //重连次数
 delay_before_retry 3 //重连间隔时间
 connect_port 3306 //健康检查端口
 }
 }
}

// master1のキープアライブ構成

! Configuration File for keepalived

global_defs {
    
    
   router_id mysql02
}

vrrp_instance VI_1 {
    
    
    state BACKUP
    interface ens33
    virtual_router_id 51
    priority 99
    advert_int 1
    authentication {
    
    
        auth_type PASS
        auth_pass 1111
    }
    virtual_ipaddress {
    
    
        192.168.1.100
    }
}

virtual_server 192.168.1.100 3306 {
    
    
    delay_loop 6
    lb_algo rr
    lb_kind DR
    persistence_timeout 50
    protocol TCP

    real_server 192.168.1.67 3306 {
    
    
        weight 1
	notify_down /etc/keepalived/bin/mysql.sh
	TCP_CHECK {
    
    
		connect_port 3306
		connect_timeout 3
		retry 3
		delay_before_retry 3
}
}
}

// master2構成

! Configuration File for keepalived

global_defs {
    
    
   router_id mysql01
}

vrrp_instance VI_1 {
    
    
    state BACKUP
    interface ens33
    virtual_router_id 51
    priority 100
    advert_int 1
    authentication {
    
    
        auth_type PASS
        auth_pass 1111
    }
    virtual_ipaddress {
    
    
        192.168.1.100
    }
}

virtual_server 192.168.1.100 3306 {
    
    
    delay_loop 6
    lb_algo rr
    lb_kind DR
    persistence_timeout 50
    protocol TCP

    real_server 192.168.1.65 3306 {
    
    
        weight 1
	notify_down /etc/keepalived/bin/mysql.sh
	TCP_CHECK {
    
    
		connect_port 3306
		connect_timeout 3
		retry 3
		delay_before_retry 3
}
}
}

3.スクリプトを作成します（master1とmaster2は一緒に使用できます）

# mkdir /etc/keepalived/bin
vi /etc/keepalived/bin/mysql.sh，内容如下：
#!/bin/bash
pkill keepalived
chmod +x /etc/keepalived/bin/mysql.sh

4.master1とmaster2で実行されたipaddr show dev ens33コマンドをテストして、VIP（クラスター仮想IP）に対するmaster1とmaster2の制御権を確認します。

[root@mysqld01 ~]# ip a show dev ens33
2: ens33: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 qdisc pfifo_fast state UP qlen 1000
   link/ether 00:0c:29:57:8d:1c brd ff:ff:ff:ff:ff:ff
   inet 192.168.1.65/24 brd 192.168.1.255 scope global ens33
      valid_lft forever preferred_lft forever
   inet 192.168.1.100/32 scope global ens33
      valid_lft forever preferred_lft forever
   inet6 fe80::20c:29ff:fe57:8d1c/64 scope link 
      valid_lft forever preferred_lft forever

[root@mysql02 ~]# ip a show dev ens33
2: ens33: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 qdisc pfifo_fast state UP qlen 1000
   link/ether 00:0c:29:19:f2:8c brd ff:ff:ff:ff:ff:ff
   inet 192.168.1.67/24 brd 192.168.1.255 scope global ens33
      valid_lft forever preferred_lft forever
   inet6 fe80::65e6:f746:5344:e26a/64 scope link 
      valid_lft forever preferred_lft forever

master1がプライマリサーバーであり、master2がスタンバイサーバーであることがわかります。MySQLサービスを停止し、keepalivedヘルスチェックプログラムが作成したスクリプトをトリガーするかどうかを確認します

master1ホストのmysqlサービスを停止します

[root@mysqld01 ~]# systemctl stop mysqld.service 

[root@mysqld01 ~]# ip a show dev ens33
2: ens33: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 qdisc pfifo_fast state UP qlen 1000
   link/ether 00:0c:29:57:8d:1c brd ff:ff:ff:ff:ff:ff
   inet 192.168.1.65/24 brd 192.168.1.255 scope global ens33
      valid_lft forever preferred_lft forever
   inet6 fe80::20c:29ff:fe57:8d1c/64 scope link 
      valid_lft forever preferred_lft forever

// MySQLを停止した後、VIPがmaster1にないが、master2にドリフトしていることがわかります。これは、メインサービスでMySQLサービスを停止すると、自動フェイルオーバーを実行するために作成したスクリプトがトリガーされることを意味します。

概要：Keepalived + mysqlデュアルマスター一般的に、中小規模の場合、このアーキテクチャを採用するのが最も問題がありません。マスターノードに障害が発生した後、keepalived高可用性メカニズムを使用して、スタンバイノードにすばやく切り替えます。このスキームでは、注意すべき点がいくつかあります。

1.高可用性ソリューションとしてkeepalivedを使用する場合は、相互プリエンプションによる偶発的な状態（スプリットブレインなど）によって2つのノードに同じデータを書き込むことによって引き起こされる競合を回避するために、両方のノードをバックアップモードに設定するのが最善です。

2. 2つのノードのauto_increment_increment（自動インクリメントステップ）とauto_increment_offset（自動インクリメント初期値）を異なる値に設定します。目的は、マスターノードの予期しないダウンタイムを回避することです。一部のbinlogは、適用される時間内にスレーブにコピーされない場合があります。これにより、スレーブの新しく書き込まれたデータの自己インクリメントが元のマスターと競合する可能性があります。最初に使用するもちろん、マスターとスレーブ間のIDの競合を解決できる適切なフォールトトレラントメカニズムがある場合は、それを行うこともできません。

3.スレーブノードサーバーの構成はそれほど悪くないはずです。そうしないと、レプリケーションの遅延が発生する可能性が高くなります。ホットスタンバイノードのスレーブサーバーとして、ハードウェア構成をマスターノードの構成より低くすることはできません。

4.レイテンシーの問題に非常に敏感な場合は、MariaDBブランチバージョンの使用を検討するか、MySQL 5.7の最新バージョンを直接起動できます。マルチスレッドレプリケーションを使用すると、レプリケーションレイテンシーを大幅に削減できます。