修改数据库配置文件dbServers.xml

后台启动Amoeba软件，并查看端口是否已开启：

7.2 客户端安装mariadb数据库

客户端：192.168.72.40

[root@yuji ~]# yum install -y mariadb-server mariadb   #安装mariadb数据库
 [root@yuji ~]# systemctl start mariadb.service         #启动mariadb
 #客户端通过amoeba服务器登录数据库，之后向库中写入数据：
 mysql -u amoeba -p123456 -h 192.168.72.30 -P8066        
 use yuji666;
 create table class(id int,name char(10));
 #通过amoeba服务器代理访问mysql ，再通过客户端连接mysql后写入的数据只有主服务会记录，然后同步给从--从服务器
复制代码

查看master服务器：

查看slave服务器：

7.3 测试读写分离

//在两台slave服务器上，关闭同步：
 stop slave;                 #关闭同步
 use yuji666;
 //在slave1上写入数据：
 insert into class values('1','zhangsan');
 //在slave2上写入数据：
 insert into class values('2','lisi');
 //在master服务器上写入数据：
 insert into class values('3','wangwu');
 //在客户端上查看数据：
 use yuji666;
 select * from class;        
 #客户端会分别向slave1和slave2读取数据（轮询），显示的只有在两个从服务器上添加的数据，没有在主服务器上添加的数据。说明读写是分离的，只从slave中读取数据。
 insert into class values('4','qianqi',);    //客户端插入数据，只有主服务器上有此数据
 //在两个从服务器上执行 start slave; 即可实现同步主服务器中添加的数据
 start slave;             #开启同步
 select * from class;    
复制代码

slave1关闭同步，之后向class表中插入数据：

在master服务器上写入数据：

在客户端上查看数据：

slave服务器开启同步，即可同步主服务器中添加的数据：

重点总结：

1、主从复制的工作过程

Master节点需要开启二进制日志，Slave节点需要开启中继日志。

（1）Master 节点将数据的改变记录成二进制日志（bin log） ，当Master上的数据发生改变时（增删改），则将其改变写入二进制日志中。

（2）Slave节点会在一定时间间隔内对Master的二进制日志进行探测其是否发生改变，如果发生改变，则开始一个I/O线程请求Master的二进制事件。（请求二进制数据）

（3）同时Master 节点为每个I/O线程启动一个dump线程，用于向其发送二进制事件，并保存至slave节点本地的中继日志（Relay log）中，，Slave节点将启动SQL线程从中继日志中读取二进制事件，在本地重放，即解析成sql 语句逐一执行，使得其数据和Master节点的保持一致。最后I/O线程和SQL线程将进入睡眠状态，等待下一次被唤醒。

注意：

• 中继日志通常会位于 OS 缓存中，所以中继日志的开销很小。
• 复制过程有一个很重要的限制，即复制在 Slave上是串行化的，也就是说 Master上的并行更新操作不能在 Slave上并行操作。
• 半同步复制，会多一个ack确认线程（ack collector thread），专门用于接收slave 的反馈信息（收集slave节点返回的ack信息）。

2、数据库主从数据不一致解决方案

方法一：忽略错误后，继续同步

• 该方法适用于主从库数据相差不大，或者要求数据可以不完全统一的情况，数据要求不严格的情况。

方式二：重新做主从，完全同步

• 该方法适用于主从库数据相差较大，或者要求数据完全统一的情况。

3、mysql从服务器挂了 恢复后怎么保证数据同步？

• 物理方法： rsync 磁盘文件同步。 使用文件恢复，主节点需要停服务。
• 主从复制： 将从节点原有库删除，通过偏移量，重新做一次主从复制。

4、半同步复制什么情况下会降为异步复制？什么时候又会恢复同步复制？

• 当半同步复制发生超时（由rpl_semi_sync_master_timeout 参数控制，默认为10000ms， 即10s），会暂时关闭半同步复制，转而使用异步复制，也就是会自动降为异步工作。
• 当malster dump 线程发送完一个事务的所有事件之后，如果在rpl_ semi_sync_master_ timeout 内，收到了从库的响应，则主从又重新恢复为半同步复制。

5、MySQL主从复制延迟原因和优化方法

主从复制延迟原因：

1. master服务器高并发，形成大量事务。
2. 网络延迟。
3. 主从硬件设备导致（cpu主频、内存IO、硬盘IO）。
4. 是同步复制，而不是异步复制。

优化方法：

• 从库优化Mysql参数。比如增大innodb_buffer_pool_size，让更多操作在Mysql内存中完成，减少磁盘操作。
• 从库使用高性能主机。包括cpu强悍、内存加大。避免使用虚拟云主机，使用物理主机，这样提升了I/O方面性。
• 从库使用SSD磁盘。
• 网络优化，避免跨机房实现同步。

6、注意事项

1. 每个master可以有多个slave。
2. 每个slave只能有一个master。
3. 每个slave只能有一个唯一的服务器ID（server-id）。
   
4. master一定要开启binlog二进制日志功能；通常为了数据安全，slave也开启binlog功能。