未加星标

MariaDB High Availability: Replication Manager

字体大小 | |
[数据库(mysql) 所属分类 数据库(mysql) | 发布者 店小二04 | 时间 2016 | 作者 红领巾 ] 0人收藏点击收藏

This is a follow-up blog post that expands on the subject of highly available cluster, discussed in MariaDB MaxScale High Availability: Active-Standby Cluster .

MariaDB Replication Manager is a tool that manages MariaDB 10 clusters. It supports both interactive and automated failover of the master server. It verifies the integrity of the slave servers before promoting one of them as the replacementmaster and it also protects the slaves by automatically setting them into read-only mode.You can find more information on the replication-manager from the replication-manager GitHub repository .

Using the MariaDB Replication Manager allows us to automate the replication failover. This reduces the amount of manual work required to adapt to changes in the cluster topology and makes for a more highly available database cluster.

In this blog post,we'll cover the topic ofbackend database HA andwe’ll use the MariaDB Replication Manager to create a complete HA solution. We build on the setup described in the earlier blog post and integrate the MariaDB Replication Manager (MRM) into it. We're using Centos 7 as our OS and we'll use the 0.7.0-rc2 version of the replication-manager.

Setting Up MariaDB Replication Manager

The Replication Manager allows us to manage the replication topology of the cluster without having to manually change it. The easiest way to integrate it to our Corosync setup is to build it from source and use the Systemd service file it provides.

sudo yum install go git export GOPATH=~/gocode && mkdir ~/gocode && cd ~/gocode go get github.com/tanji/replication-manager go install github.com/tanji/replication-manager sudo cp src/github.com/tanji/replication-manager/service/replication-manager.service /lib/systemd/system/replication-manager.service sudo ln -s $GOPATH/bin/replication-manager /usr/bin/replication-manager

Now, we should have a working replication-manager installation. The next step is to configure the servers that it manages. The replication-manager reads its configuration file from /etc/replication-manager/config.toml. Create the file and add the following lines to it.

logfile = "/var/log/replication-manager.log" verbose = true hosts = "192.168.56.1:3000,192.168.56.1:3001,192.168.56.1:3002,192.168.56.1:3003" user = "maxuser:maxpwd" rpluser = "maxuser:maxpwd" interactive = false failover-limit = 0

Once the configuration file is in place, we can add it as a resource and colocate it with the clusterip resource we created in the previous blog post.

sudo pcs resource create replication-manager systemd:replication-manager op monitor interval=1s sudo pcs constraint colocation add replication-manager with clusterip INFINITY

After the resource is added and configured, we see that it was added and stared on node1.

[[email protected] ~]$ sudo pcs resource Clone Set: maxscale-clone [maxscale] Started: [ node1 node2 ] clusterip (ocf::heartbeat:IPaddr2): Started node1 replication-manager (systemd:replication-manager): Started node1

Looking at the maxadmin output on the server where the active MaxScale is running,we see that the server at 192.168.56.1:3000 is currently the master.

[[email protected] ~]$ sudo maxadmin list servers Servers. ---------+-----------------+-------+-------------+-------------- Server | Address | Port | Connections | Status ---------+-----------------+-------+-------------+-------------- server1 | 192.168.56.1 | 3000 | 0 | Master, Running server2 | 192.168.56.1 | 3001 | 0 | Slave, Running server3 | 192.168.56.1 | 3002 | 0 | Slave, Running server4 | 192.168.56.1 | 3003 | 0 | Slave, Running ---------+-----------------+-------+-------------+--------------

Now if we kill the master, replication-manager should pick that up and perform a master failover. But first we need to insert some data to make sure the failover is performed correctly and to make it a bit of a challenge, we’ll do those inserts continuously. First, we create an extremely simple table.

CREATE TABLE test.t1 (id INT);

For this, a mysql client in a loop has been started on a remove server.

i=0; while true; do mysql -ss -u maxuser -pmaxpwd -h 192.168.56.220 -P 4006 -e "INSERT INTO test.t1 VALUES (1);SELECT NOW()"; sleep 1; done

Now, we’ll have a constant stream of inserts going to our cluster and we can see what happens when we kill the current master at 192.168.56.1:3000.

2016/10/01 19:56:05 WARN : Master Failure detected! Retry 1/5 2016/10/01 19:56:05 INFO : INF00001 Server 192.168.56.1:3000 is down 2016/10/01 19:56:07 WARN : Master Failure detected! Retry 2/5 2016/10/01 19:56:09 WARN : Master Failure detected! Retry 3/5 2016/10/01 19:56:11 WARN : Master Failure detected! Retry 4/5 2016/10/01 19:56:13 WARN : Master Failure detected! Retry 5/5 2016/10/01 19:56:13 WARN : Declaring master as failed 2016/10/01 19:56:13 INFO : Starting master switch 2016/10/01 19:56:13 INFO : Electing a new master 2016/10/01 19:56:13 INFO : Slave 192.168.56.1:3001 [0] has been elected as a new master 2016/10/01 19:56:13 INFO : Reading all relay logs on 192.168.56.1:3001 2016/10/01 19:56:13 INFO : Stopping slave thread on new master 2016/10/01 19:56:14 INFO : Resetting slave on new master and set read/write mode on 2016/10/01 19:56:14 INFO : Switching other slaves to the new master 2016/10/01 19:56:14 INFO : Change master on slave 192.168.56.1:3003 2016/10/01 19:56:14 INFO : Change master on slave 192.168.56.1:3002 2016/10/01 19:56:15 INFO : Master switch on 192.168.56.1:3001 complete

The replication-manager successfully detected the failure of the master and performed a failover. MaxScale will detect this and adapt accordingly.

[[email protected] ~]$ sudo maxadmin list servers Servers. ---------+---------------+-------+-------------+-------------- Server | Address | Port | Connections | Status ---------+---------------+-------+-------------+-------------- server1 | 192.168.56.1 | 3000 | 0 | Down server2 | 192.168.56.1 | 3001 | 0 | Master, Running server3 | 192.168.56.1 | 3002 | 0 | Slave, Running server4 | 192.168.56.1 | 3003 | 0 | Slave, Running ---------+---------------+-------+-------------+--------------

From the remote server’s terminal, we can see that there was a small window where writes weren’t possible.

2016-10-01 19:56:01 2016-10-01 19:56:02 2016-10-01 19:56:03 2016-10-01 19:56:04 ERROR 2013 (HY000) at line 1: Lost connection to MySQL server during query ERROR 1045 (28000): failed to create new session ERROR 1045 (28000): failed to create new session ERROR 1045 (28000): failed to create new session ERROR 1045 (28000): failed to create new session ERROR 1045 (28000): failed to create new session ERROR 1045 (28000): failed to create new session ERROR 1045 (28000): failed to create new session ERROR 1045 (28000): failed to create new session ERROR 1045 (28000): failed to create new session ERROR 1045 (28000): failed to create new session 2016-10-01 19:56:17 2016-10-01 19:56:18 2016-10-01 19:56:19

Now our whole cluster is highly available and ready for all kinds of disasters.

Summary

After integrating the replication-manager into our Corosync/Pacemaker setup, our cluster is highly available. If the server where the replication-manager is running were to go down, it would be started up on another node. Database server outages will be mana

本文数据库(mysql)相关术语:navicat for mysql mysql workbench mysql数据库 mysql 存储过程 mysql安装图解 mysql教程 mysql 管理工具

主题: SQLGitMySQLGitHub
分页:12
转载请注明
本文标题:MariaDB High Availability: Replication Manager
本站链接:http://www.codesec.net/view/480190.html
分享请点击:


1.凡CodeSecTeam转载的文章,均出自其它媒体或其他官网介绍,目的在于传递更多的信息,并不代表本站赞同其观点和其真实性负责;
2.转载的文章仅代表原创作者观点,与本站无关。其原创性以及文中陈述文字和内容未经本站证实,本站对该文以及其中全部或者部分内容、文字的真实性、完整性、及时性,不作出任何保证或承若;
3.如本站转载稿涉及版权等问题,请作者及时联系本站,我们会及时处理。
登录后可拥有收藏文章、关注作者等权限...
技术大类 技术大类 | 数据库(mysql) | 评论(0) | 阅读(36)