安全最重要！MySQL配置主从复制，主主复制

为了保障数据的安全与稳定性，我们常用数据库的主从复制与主主复制来实现。主从复制为从机实时拷贝一份主机的数据，当主机有数据变化时，从机的数据会跟着变，当从机数据有变化时，主机数据不变；同样地，主主复制就是，多个主机之间，只要有一个主机的数据变化了，其它主机数据也会跟着变化。

添加以下内容

如果你是使用我之前那种方式启动的MySQL，那么你只需要去你相关联的宿主机的配置文件夹里面去建立一个 my.cnf 然后写入上面的类容就好了。

比如：我的启动命令如下（不应该换行的，这里为了方便查看，我给它分行了）

那么我只需要在 /docker/mysql_master/conf 这个目录下创建 my.cnf 文件就好了。

这个命令是需要在容器里面执行的

docker重启mysql会关闭容器，我们需要重启容器。

确保在主服务器上 skip_networking 选项处于 OFF 关闭状态, 这是默认值。 如果是启用的，则从站无法与主站通信，并且复制失败。

我的命令如下

在从服务器配置连接到主服务器的相关信息 （在容器里面的mysql执行）

上面代码的xxxxx你需要换成你的IP，docker 查看容器 IP 的命令如下：

启动的那个从服务器的线程

测试的话，你可以在主服务器里面，创建一个数据库，发现从服务器里面也有了，就成功了。

如果你还想要一个从服务器，那么你只需要按照上面配置从服务器再配置一个就行了，新建的从服务器，会自动保存主服务器之前的数据。（测试结果） 如果你上面的主从复制搞定了，那么这个主主复制就很简单了。我们把上面的从服务器也改成主服务器

1）、修改上面的从服务器的my.cnf文件，和主服务器的一样（注意这个server-id不能一样）然后重启服务器 2）、在从服务器里面创建一个复制用户创建命令一样（这里修改一下用户名可以改为 repl2） 3）、在之前的主服务器里面运行下面这个代码

上面主要是教你怎么搭建一个MySQL集群，但是这里面还有很多其它的问题。也是我在学习过程中思考的问题，可能有的小伙伴上来看到文章长篇大论的看不下去，只想去实现这样一直集群功能，所以我就把问题写在下面了。

1）、MySQL的replication和pxc MySQL的集群方案有replication和pxc两种，上面是基于replication实现的。

replication: 异步复制，速度快，无法保证数据的一致性。 pxc: 同步复制，速度慢，多个集群之间是事务提交的数据一致性强。

2）、MySQL的replication数据同步的原理 我们在配置的时候开启了它的二进制日志，每次 *** 作数据库的时候都会更新到这个日志里面去。主从通过同步这个日志来保证数据的一致性。

3）、可否不同步全部的数据 可以配置，同步哪些数据库，甚至是哪些表。

4）、怎么关闭和开始同步

5）、我就我的理解画出了，主从、主从从、主主、复制的图。

往期推荐：

利用Docker仅花1分钟时间安装好MySQL服务

Linux下MySQL 5.7的离线与在线安装（图文）

Linux下安装MySQL8.0（收藏！）

PXC简介

Percona XtraDB Cluster（简称PXC集群）提供了MySQL高可用的一种实现方法。

1.集群是有节点组成的，推荐配置至少3个节点，但是也可以运行在2个节点上。

2.每个节点都是普通的mysql/percona服务器，可以将现有的数据库服务器组成集群，反之，也可以将集群拆分成单独的服务器。

3.每个节点都包含完整的数据副本。

PXC集群主要由两部分组成：Percona Server with XtraDB和Write Set Replication patches（使用了Galera library，一个通用的用于事务型应用的同步、多主复制插件）。

PXC特性：

1，同步复制，事务要么在所有节点提交或不提交。

2，多主复制，可以在任意节点进行写 *** 作。

3，在从服务器上并行应用事件，真正意义上的并行复制。

4，节点自动配置，数据一致性，不再是异步复制。

PXC劣势：

1、 当前版本（5.6.20）的复制只支持InnoDB引擎，其他存储引擎的更改不复制。然而，DDL（Data Definition Language） 语句在statement级别被复制，并且，对mysql.*表的更改会基于此被复制。例如CREATE USER...语句会被复制，但是 INSERT INTO mysql.user...语句则不会。（也可以通过wsrep_replicate_myisam参数开启myisam引擎的复制，但这是一个实验性的参数）。

2、PXC集群一致性控制机制，事有可能被终止，原因如下：集群允许在两个节点上同时执行 *** 作同一行的两个事务，但是只有一个能执行成功，另一个会被终止，集群会给被终止的客户端返回死锁错误(Error: 1213 SQLSTATE: 40001 (ER_LOCK_DEADLOCK)).

3、写入效率取决于节点中最弱的一台，因为PXC集群采用的是强一致性原则，一个更改 *** 作在所有节点都成功才算执行成功。

原理描述

分布式系统的CAP理论：

C 一致性，所有的节点数据一致

A 可用性，一个或者多个节点失效，不影响服务请求P 分区容忍性，节点间的连接失效，仍然可以处理请求任何一个分布式系统，需要满足这三个中的两个安装部署

环境描述

三个node节点

node #1

hostname: percona1

IP: 192.168.100.7

node #2

hostname: percona2

IP: 192.168.100.8

node #3

hostname: percona3

IP: 192.168.100.9

基础环境包

可以选择源码或者yum，在此使用yum安装。

三个node节点都要执行以下 *** 作。

基础环境

yum -y groupinstall Base Compatibility libraries Debugging Tools Dial-up Networking suppport Hardware monitoring utilities Performance Tools Development tools组件安装

yum install http://www.percona.com/downloads/percona-release/redhat/0.1-3/percona-release-0.1-3.noarch.rpm -yyum install Percona-XtraDB-Cluster-55 -y

数据库配置

选择一个node作为名义上的master，咱们以node1为master，以下 *** 作只在node1上执行。

只需要修改mysql的配置文件－－/etc/my.cnf

说明：这里的IP地址是内网地址。

[root@i-kysyolko ~]# cat /etc/my.cnf

# Template my.cnf for PXC

# Edit to your requirements.

[mysqld]

datadir=/var/lib/mysql

user=mysql

# Path to Galera library

wsrep_provider=/usr/lib64/libgalera_smm.so# Cluster connection URL contains the IPs of node#1, node#2 and node#3wsrep_cluster_address=gcomm://192.168.100.7,192.168.100.8,192.168.100.9# In order for Galera to work correctly binlog format should be ROWbinlog_format=ROW

# MyISAM storage engine has only experimental supportdefault_storage_engine=InnoDB

# This changes how InnoDB autoincrement locks are managed and is a requirement for Galerainnodb_autoinc_lock_mode=2

# Node #1 address

wsrep_node_address=192.168.100.7

# SST method

wsrep_sst_method=xtrabackup-v2

# Cluster name

wsrep_cluster_name=my_centos_cluster

# Authentication for SST method

wsrep_sst_auth="sstuser:s3cret"

[mysqld_safe]

pid-file = /run/mysqld/mysql.pid

syslog

!includedir /etc/my.cnf.d

启动数据库

CentOS6：/etc/init.d/mysql bootstrap-pxc

CentOS7：systemctl start mysql@bootstrap.service配置数据库

mysql>show status like 'wsrep%'

+----------------------------+--------------------------------------+| Variable_name | Value |

+----------------------------+--------------------------------------+| wsrep_local_state_uuid | c2883338-834d-11e2-0800-03c9c68e41ec |...

| wsrep_local_state | 4 |

| wsrep_local_state_comment | Synced |

...

| wsrep_cluster_size | 1 ＃主要看这里 |

| wsrep_cluster_status | Primary |

| wsrep_connected | ON |

...

| wsrep_ready | ON |

+----------------------------+--------------------------------------+40 rows in set (0.01 sec)

＃ 数据库用户名密码的设置

mysql@percona1>UPDATE mysql.user SET password=PASSWORD("Passw0rd") where user='root'# 创建、授权、同步账号

mysql@percona1>CREATE USER 'sstuser'@'localhost' IDENTIFIED BY 's3cret'mysql@percona1>GRANT RELOAD, LOCK TABLES, REPLICATION CLIENT ON *.* TO 'sstuser'@'localhost'mysql@percona1>FLUSH PRIVILEGES

node2、node3节点配置

接下来进行其它节点的配置，上面的组件都已经安装完成。现在直接进行数据库的配置。

只需要修改第26行，当前node的IP地址。两个node都是只是修改这个地址即可。

wsrep_node_address=192.168.100.8

[root@i-kysyolko ~]# cat /etc/my.cnf

# Template my.cnf for PXC

# Edit to your requirements.

[mysqld]

datadir=/var/lib/mysql

user=mysql

# Path to Galera library

wsrep_provider=/usr/lib64/libgalera_smm.so# Cluster connection URL contains the IPs of node#1, node#2 and node#3wsrep_cluster_address=gcomm://192.168.100.7,192.168.100.8,192.168.100.9# In order for Galera to work correctly binlog format should be ROWbinlog_format=ROW

# MyISAM storage engine has only experimental supportdefault_storage_engine=InnoDB

# This changes how InnoDB autoincrement locks are managed and is a requirement for Galerainnodb_autoinc_lock_mode=2

# Node #1 address

wsrep_node_address=192.168.100.8

# SST method

wsrep_sst_method=xtrabackup-v2

# Cluster name

wsrep_cluster_name=my_centos_cluster

# Authentication for SST method

wsrep_sst_auth="sstuser:s3cret"

[mysqld_safe]

pid-file = /run/mysqld/mysql.pid

syslog

!includedir /etc/my.cnf.d

启动数据库

CentOS6：/etc/init.d/mysql start

CentOS7：systemctl start mysql.service

说明：

1、除了名义上的master之外，其它的node节点只需要启动mysql即可。

2、节点的数据库的登陆和master节点的用户名密码一致，自动同步。所以其它的节点数据库用户名密码无须重新设置。

测试

在任意一个node上，进行 *** 作，然后去其它的节点上看是否取得相同的结果

MySQL主从复制

现在常用的MySQL高可用方案，十有八九是基于 MySQL的主从复制（replication）来设计的，包括常规的一主一从、双主模式，或者半同步复制（semi-sync replication）。

我们常常把MySQL replication说成是MySQL同步（sync），但事实上这个过程是异步（async）的。大概过程是这样的：

在master上提交事务后，并且写入binlog，返回事务成功标记；

将binlog发送到slave，转储成relay log；

在slave上再将relay log读取出来应用。

步骤1和步骤3之间是异步进行的，无需等待确认各自的状态，所以说MySQL replication是异步的。

MySQL semi-sync replication在之前的基础上做了加强完善，整个流程变成了下面这样：

首先，master和至少一个slave都要启用semi-sync replication模式；

某个slave连接到master时，会主动告知当前自己是否处于semi-sync模式；

在master上提交事务后，写入binlog后，还需要通知至少一个slave收到该事务，等待写入relay log并成功刷新到磁盘后，向master发送“slave节点已完成该事务”确认通知；

master收到上述通知后，才可以真正完成该事务提交，返回事务成功标记；

在上述步骤中，当slave向master发送通知时间超过rpl_semi_sync_master_timeout设定值时，主从关系会从semi-sync模式自动调整成为传统的异步复制模式。

半同步复制看起来很美好有木有，但如果网络质量不高，是不是出现抖动，触发上述第5条的情况，会从半同步复制降级为普通复制；此外，采用半同步复制，会导致master上的tps性能下降非常严重，最严重的情况下可能会损失50%以上。

这样来看，除非需要非常严格保证数据一致性等迫不得已的场景，就不太建议使用半同步复制了。当然了，事实上我们也可以通过加强程序端的逻辑控制，来避免主从数据不一致时发生逻辑错误，比如说如果在从上读取到的数据和主不一致的话，那么就触发主从间的一次数据修复工作。或者，我们也可以用 pt-table-checksum &pt-table-sync 两个工具来校验并修复数据，只要运行频率适当，是可行的。

真想要提高多节点间的数据一致性，可以考虑采用PXC方案。现在已知用PXC规模较大的有qunar、sohu，如果团队里初期没有人能比较专注PXC的话，还是要谨慎些，毕竟和传统的主从复制差异很大，出现问题时需要花费更多精力去排查解决。

如何保证主从复制数据一致性

上面说完了异步复制、半同步复制、PXC，我们回到主题：在常规的主从复制场景里，如何能保证主从数据的一致性，不要出现数据丢失等问题呢？

在MySQL中，一次事务提交后，需要写undo、写redo、写binlog，写数据文件等等。在这个过程中，可能在某个步骤发生crash，就有可能导致主从数据的不一致。为了避免这种情况，我们需要调整主从上面相关选项配置，确保即便发生crash了，也不能发生主从复制的数据丢失。

1. 在master上修改配置

innodb_flush_log_at_trx_commit = 1

sync_binlog = 1

上述两个选项的作用是：保证每次事务提交后，都能实时刷新到磁盘中，尤其是确保每次事务对应的binlog都能及时刷新到磁盘中，只要有了binlog，InnoDB就有办法做数据恢复，不至于导致主从复制的数据丢失。

2. 在slave上修改配置

master_info_repository = "TABLE"

relay_log_info_repository = "TABLE"

relay_log_recovery = 1

上述前两个选项的作用是：确保在slave上和复制相关的元数据表也采用InnoDB引擎，受到InnoDB事务安全的保护，而后一个选项的作用是开启relay log自动修复机制，发生crash时，会自动判断哪些relay log需要重新从master上抓取回来再次应用，以此避免部分数据丢失的可能性。

通过上面几个选项的调整，就可以确保主从复制数据不会发生丢失了。但是，这并不能保证主从数据的绝对一致性，因为，有可能设置了ignore\do\rewrite等replication规则，或者某些SQL本身存在不确定因素，或者人为在slave上修改数据，最终导致主从数据不一致。这种情况下，可以采用pt-table-checksum 和 pt-table-sync 工具来进行数据的校验和修复。

---