集群：

高可用；

负载均衡；

高性能

1、MySQL主库在事务提交时把数据变更（insert、delet、update）作为事件日志记录在二进制日志表（binlog）里面。

2、主库上有一个工作线程 binlog dump thread，把binlog的内容发送到从库的中继日志relay log中。

3、从库根据中继日志relay log重做数据变更操作，通过逻辑复制来达到主库和从库的数据一致性。

4、MySQL通过三个线程来完成主从库间的数据复制，其中binlog dump线程跑在主库上，I/O线程和SQL线程跑在从库上。拥有多个从库的主库会为每一个连接到主库的从库创建一个binlog dump线程。  

主从复制；采用三台机器；

101 102 103

首先第一步关闭防火墙；

这里采用脚本加二进制包的方式进行安装；

文件太大就不上传了，有需要的通过私信找我获得；

首先主服务器应该具备生成二进制事物记录日志的功能；

打开主配置文件进行添加相关的语句；

vim /etc/my.cnf

以及指定不需要复制的库不记录日志；

binlog-ignore-db=test

重启服务后生效；

语句翻译：这些MySQL配置文件（通常是my.cnf或my.ini，取决于操作系统）中的语句用于配置MySQL服务器的二进制日志（binlog）相关的行为，以及复制（replication）和日志缓存的大小等。下面是对每个语句的解释和翻译：

1. server-id=11

• • 解释：设置MySQL服务器的唯一ID为11。在MySQL复制配置中，每个服务器（无论是主服务器还是从服务器）都需要有一个唯一的server-id，以区分它们。

  • 翻译：服务器ID设置为11。

1. log-bin=master-bin

• • 解释：启用二进制日志，并将日志文件的前缀设置为master-bin。二进制日志记录了所有更改数据库内容的语句（如DML语句和DDL语句的某些部分），这对于数据复制和数据恢复至关重要。

  • 翻译：启用二进制日志，并将日志文件名前缀设置为master-bin。

1. binlog-format=MIXED

• • 解释：设置二进制日志的格式为MIXED。MySQL有三种二进制日志格式：STATEMENT（基于SQL语句的复制）、ROW（基于行的复制）和MIXED（混合模式，默认情况下使用STATEMENT，但在某些情况下自动切换到ROW以确保数据一致性）。

  • 翻译：二进制日志格式设置为混合模式。

1. replicate-ignore-db=test

• • 解释：在从服务器（slave）上配置时，此选项指定了不需要从主服务器（master）复制过来的数据库名称。在这个例子中，test数据库将被忽略，即它的更改不会被复制到从服务器上。

  • 翻译：在从服务器复制时忽略test数据库。

1. binlog-cache-size=1M

• • 解释：设置每个会话的二进制日志缓存大小为1MB。这个缓存用于存储当前会话中即将写入二进制日志的语句。如果语句的大小超过了缓存大小，缓存将自动增长，但达到max_binlog_cache_size时停止。

  • 翻译：二进制日志缓存大小设置为1MB。

1. expire-logs-days=3

• • 解释：设置二进制日志文件的过期天数。在这个例子中，MySQL将自动删除3天前的二进制日志文件。这有助于管理磁盘空间，因为随着时间的推移，这些日志文件可能会占用大量空间。

  • 翻译：二进制日志文件过期天数设置为3天。

1. log-slave-updates=true

• • 解释：在从服务器上，这个选项设置为true时，从服务器上的更新（例如，由复制过程引起的更新）也会被记录到从服务器的二进制日志中。这对于链式复制（即一个从服务器可以作为另一个从服务器的主服务器）特别有用。

  • 翻译：在从服务器上启用更新日志记录。

然后登录到主服务器，进行从服务器的复制授权；

grant replication slave on *.* to 'myslave'@'192.168.10.%' identified by '123456';

然后更新配置；

flush privileges;

然后查看master状态；

show master status;

此时将master主机放置不动；打开102and103；

如果使用的是xshell可以打开同步会话功能；然后将101关闭同步功能；进行102and103之间的管理；

打开mysql的配置文件添加语句；

vim /etc/my.cnf

再把会话同步功能关闭掉；进到103修改server-id的值；

改成33

然后重启两个主机的服务；

然后再打开两个主机的同步会话功能；

登录到mysql里面开始建立连接；

change master to master_host='192.168.10.101',master_user='myslave',master_password='123456',master_log_file='master-bin.000001',master_log_pos=603;

然后启用slave功能；

start slave;

再查看slave的状态；

show slave status\G

其中I/O线程和SQL线程必须要处于连接状态；

然后进行验证；

在master主机创建数据库；

然后在slave进行查看；

然后再创建表并添加输入进行实验；

master；

slave；

最后创建test库进行试验；因为master的配置文件中指定了不同步的库；

在master创建test库；

然后创建表；及添加数据进行实验；

此时会发现指定了不同步的库还是被同步了过去；

开始排错；

发现不想同步某些库的话，要在slave的配置文件中进行添加相应的语句；

然后重启服务

再在master主机的test库中的任意表进行添加内容测试；

此时发现slave的状态中也有不被同步的库了；

也不会把test库中的数据同步了；

这种主从复制的架构弊端就是只有在master主机添加内容才会被同步，而在slave中添加数据不会被同步；slave添加数据，另外slave也不会同步过来；

以及主节点重启mysqld服务也不会造成影响；重启后从节点的状接中I/O线程的状态可能会处于连接状态，但是不会保持很长时间就会变成正常状态；

这是依托于从节点上的I/O线程会寻找主节点的二进制日志然后回立即获取到；（其中主要信息包括，主节点的日志文件，和位置；）

如果从节点的I/O线程一直处于连接状态；首先检查防火墙；关闭或者添加相应的允许策略；

或者连接参数有问题；先关闭从的I/O节点；stop slave；然后查看master的状态中的位置及文件；再书写连接的语句；然后启动该服务；start slave；

然后再去查看从节点的状态就可以了；

如果是运行了一段时间的服务器想做主从服务；那么以前的数据是能够被同步过来的；需要将以前的二进制事件日志文件导出再导入即可；

接着以上的主从复制然后开始部署读写分离；

实验环境紧接着以上的环境再打开两个主机；

一个作为客户机，一个作为代理服务器；

然后进入到104；即代理服务器安装amoeba；以及java的二进制环境包；

文件太大，上传不上去，需要私信；

给JDK文件一个执行权；因为这个文件是二进制的；

chmod +x jdk-6u14-linux-x64.bin

然后执行该文件；

./jdk-6u14-linux-x64.bin 回车至末尾；输入yes；回车结束；

然后默认就会把文件放到家目录；移动到方便管理的地方；

mv jdk1.6.0_14/ /usr/local/jdk1.6

然后对jdk命令进行优化；这里推荐使用变量的方法；

vim /etc/profile

写完后重载该文件；

source /etc/profile

然后测试一下；

然后开始安装amoeba;

先解压该tar包；

tar zxvf amoeba-mysql-binary-2.2.0.tar.gz

先创建解压后放置的目录；

然后在解压的过程中指定放置的目录；

然后登录到主服务器上给代理服务；amoeba授权；

grant all on *.* to 'test'@'192.168.10.%' identified by '123.com';

然后进入代理服务器的配置文件目录下对配置文件进行修改；

先修改前端的配置文件；

先指定终端用户连接amoeba时用到的账号与密码；

再往下翻；

指定默认连接的主机是谁；以及读写池的信息；

注释去掉；注意注释符是成对出现的；

再修改连接后端数据库的配置文件；

此时先进入到主服务器创建一个库；（因为代理服务器的配置中要指定一个默认连接的库）

然后再回到代理服务器的配置文件中指定默认访问的库；

注意去掉注释；

再往下翻；

然后指定上个配置文件中的值；master;slave;slaves;

注意：slave2的语句直接复制粘贴slave1的语句，修改即可；

然后保存退出；退回到上一级目录在/bin下启动该程序；

bin/amoeba start& （在后台运行）

然后去查询该进程；java是以容器的方式运行的；

netstat -anpt | grep java

开始测试；进入到105客户机；

需要使用mysql进行验证；这里使用yum的方式进行安装；

此时先把把代理服务器的防火墙关闭掉；

尝试连接；

mysql -uamoeba -p123456 -h 192.168.10.104 -P 8066

在客户机创建库及表；去其他主从服务器查看应该能看到库及表的存在；

弊端就是；如果slave服务器发生故障导致宕机，那么在客户端能写入数据，但是查询不到；

因为写入的时候是写到了master主机上，但是slave以及宕机，不能同步master上的数据；

代理服务器会以轮询的方式进行查询；如果两个从服务器的数据不一样，那么每次查询的数据也会不一样。

补充：如果主从复制架构已经运行了一段时间，突然出现故障的话，是不影响数据的正常同步的，但是如果是运行了一段时间的数据库，想搭建主从复制架构的话，那么之前的数据是不会被同步过来的。