MySQL Cluster (iv) keepalived realizes MySQL dual master high Availability

In front of you introduced the master-slave, the main master copy and their middleware mysql-proxy use, this one to introduce you are keepalived building and use!

I. Keepalived INTRODUCTION 1.1, Keepalived Introduction

Keepalived was originally designed for LVS, specifically to monitor the status of each service node in the cluster system , it detects the state of each service node based on the third, fourth, and fifth switching mechanisms of the TCP/IP reference Model, and if a server node is abnormal,

or work failure, keepalived will detect, and the failure of the server node removed from the cluster system, all of these tasks are automatically completed, do not require manual intervention, it is necessary to manually complete the repair of the failed service node.

Later keepalived joined the VRRP function, VRRP (vritrual Router redundancy Protocol, Virtual Routing Redundancy Protocol) appeared to solve the static route of the single point of failure problem, Through the VRRP can realize the network uninterrupted and stable operation,

So keepalvied on the one hand has the server state detection and fault isolation function, on the other hand also has the HA cluster function, the following describes the VRRP protocol implementation process.

1.2. VRRP protocol and working principle

In a real-world network environment. the communication between the hosts is done by configuring a static route or (the default gateway), and if the router between the hosts fails, the communication fails, so the router becomes a single point bottleneck in this mode of communication, and the VRRP protocol is introduced to solve the problem.

Learners familiar with the network should not be unfamiliar with the VRRP protocol, it is a master and Standby mode of the protocol , through the VRRP can be transparent in the event of network failure of the device switching without affecting the data communication between the host, which involves two concepts: physical routers and virtual routers.

　　　　VRRP can be two or more physical router devices virtual into a virtual route , the virtual router through the virtual IP (one or more) to provide services, while the virtual router inside more than 10 physical routers work together, at the same time only one physical router to provide services,

This physical routing device is become: the primary router (master role), in general, Master is generated by the election algorithm, it has a virtual IP service, providing a variety of network functions, such as: ARP requests, ICMP data forwarding, and other physical routers do not have external virtual IP,

Also does not provide the external network function, only receives the master's VRRP status advertisement information, these routers are called "The role of the backup", when the primary router fails, the backup router that is in the backup role will re-elect,

Generate a new primary router into the master role, continue to provide external services, the entire switch is completely transparent to the user.

　　　　each virtual router has a unique identification number called Vrid, a Vrid and a set of IP addresses constitute a virtual router , in the VRRP protocol, all the messages are sent by IP multicast, and in a virtual router,

　　only routers that are in the master role will always send VRRP packets, and the router in the backup role will only accept messages sent by the master role to monitor the master running state , and no backup preemption will normally occur. Unless it has a higher priority,

when Master is not available, backup will not be able to receive the message from master, so it is determined that master has failed, and then more than one bakcup will be elected, the highest priority backup is called the new master, This kind of election role switching is very fast, thus guaranteeing the continuous availability of the service.

1.3, keepalived principle　

In a VRRP virtual router, there is a polymorphic physical VRRP router, but this many physical and not work at the same time, but there is a master of the responsible routing work, the other is backup,master is not a constant VRRP protocol let each VRRP route to participate in the campaign, The final claim is master.

Master has some privileges, such as owning the IP address of the virtual router, our host is using this IP address as a static route, the privileged master is responsible for forwarding the packet sent to the gateway address and responding to the app request

Simply put: Mysql master replication, master node automatically switch. Using keepalived software to monitor the state of the master node, when the primary node crashes, immediately eagerly swap the master node backup node for high availability.

Dual-machine hot standby means that two machines are running, but not both machines are serving at the same time. When one of the service providers fails, the other one will automatically take over and provide the service immediately, and the switch time is very short.

1.4. Problems existing in keepalived

1) In the event of a heartbeat failure, it is easy to have a brain fissure (split-brain).
2) (a common type of brain fissure can be described below) such as normal, NodeA and NodeB will pass heartbeat detection to confirm the presence of the other side, when the heartbeat detected that the other party exists, the corresponding (shared) resource taken over.
If suddenly, the heartbeat between NodeA and NodeB does not exist (such as network disconnection), and NodeA and NodeB in fact are in active state, at this time NodeA to take over NodeB resource, while NodeB to take over NodeA Resource, this is the brain fissure (split-brain).
3) Brain fissures (split-brain) can cause data incompleteness and can have a serious impact on the service.
4) The data is not the integrity of the main point is that the node in the cluster (during the Rift) simultaneously access the same shared resources, and at this time there is no lock mechanism to control access to the data (both brain crack, I control miles), then there is the possibility of incomplete data.
Have a serious impact on the service, for example, you might find NodeA and NodeB take over a virtual IP at the same time in the morning.

Second, keepalived installation and configuration MySQL dual master high Availability

Environment:

Server version of ubuntu17.04: Hostname=server1, ip=1.0.0.3

Desktop version of ubuntu17.04: Hostname=udzyh1, ip1.0.0.5

2.1. In two host computersConfigure MySQL cluster primary master replication

I'm not going to describe it here, because in front of the blog has been introduced

2.2. Install keepalived on both hosts

Use the sudo apt install keepalived

2.3, Configuration keepalived

First we go into the/etc/keepalived and create a keepalived.conf (remember that all two units are configured)

1) The configuration of the host UDZYH1

Global_defs {notification_email {[email protected]} Notification_email_from [email protected] Smtp_serve R127.0.0.1Smtp_connect_timeout - router_id mysql_ha01}vrrp_instance vi_1 {State MASTERInterface ens33 #配置哪个网卡去进行心跳包的传输 virtual_router_idWuyiPriority #成为主节点 nopreempt #不抢占资源advert_int1 #心跳包的频率 1 seconds onceAuthentication {#两台主机通信心跳包的加密 Auth_type PASS auth_pass1111} virtual_ipaddress {192.168.41.222/24 #虚拟ip (similar to--proxy-address)}}virtual_server  1.0.0.3 3306{Delay_loop2#每个2秒检查一次real_server状态 lb_algo wrr #LVS算法 lb_kind DR #LVS算法 persistence_timeout -#会话保持时间 Protocol TCP Real_server 192.168.41.201 3306{weight3notify_down/home/shell/closekeepalived . Sh #检测到服务down后执行的脚本 tcp_check {connect_timeoutTen#连接超时时间 nb_get_retry3#重连次数 delay_before_retry3#重连间隔时间 Connect_port3306#健康检查端口}}} 

We also need to create this script in/home/shell/closekeepalived.sh

" Zyh "|sudo-s killall keepalived

Add Execute permission to script: sudo chmod u+x closekeepalived.sh

When the configuration is complete, open the service:

　　　　　　

2) in the host Server1 configuration

Global_defs {notification_email {[email protected]} Notification_email_from [email protected] Smtp_serve R127.0.0.1Smtp_connect_timeout - router_id mysql_ha02 (unlike udzyh1)}vrrp_instance vi_1 {State BACKUPInterfaceEns33 virtual_router_idWuyiPriority #成为备份节点 Advert_int 1Authentication {auth_type PASS auth_pass1111} virtual_ipaddress {1.0.0.122}}virtual_server  1.0.0.122 3306{Delay_loop3Lb_algo wrr lb_kind DR persistence_timeout -protocol TCP Real_server1.0.0.3 3306{weight3notify_down/home/shell/closekeepalived . Sh tcp_check{connect_timeoutTenNb_get_retry3Delay_before_retry3Connect_port3306        }    }} 　 

We also need to create this script in/home/shell/closekeepalived.sh

echo "Zyh" |sudo-s killall keepalived

Add Execute permission to script: sudo chmod u+x closekeepalived.sh

When the configuration is complete, open the service:

　　　　

2.4. See if the configuration is successful

Performed separately in host Server1 and host udzyh1:IP a view

　　　　

In Server1, the virtual IP is not being monitored because we set the UDZYH1 host's keepalived in the configuration file with a high priority. So when the two hosts

When they are open, they compete for this virtual IP, but because the UDZYH1 has a high priority, it is owned.

　　　　

2.5. Test using keepalived to get the MySQL server connection

Note: I tested it in my udzyh2.

Here we use the virtual IP to log on to the MySQL server in udzyh1 (because it is the master node: competes to the virtual IP)

　　

2.6. mysql Service outage

After we said that the MySQL service in our udzyh1 was down, keepalived detected that it was down and executed the configuration file script, which made keepalived stop,

The keepalived of the backup node accepts no packets, so the backup node immediately eagerly changes the primary node backup node for high availability and virtual IP.

But when I was testing it, it didn't execute the script, so even though I forcibly used sudo killall mysqld to shut down the MySQL service, it would not execute the script, causing it not to close

Keepalived.

So here I directly close the keepalived to simulate hot switching.

　　

We are looking at Server1: IP A, we can see that the switchover was successful.

　　

MySQL Cluster (iv) keepalived for MySQL dual master high availability