一、主从复制：架构一般是一主两从。
1.主从复制的模式：
mysql默认模式为异步模式：主库在更新完事务之后会立即把结果返回给从服务器，并不关心从库是否接收到以及从库是否处理成功。缺点：网络问题没有同步、防火墙的等因素导致同步失败。优点：快，效率高。
全同步模式：主库在更新完事务之后，立即把结果返回到从库，所有的从库执行完毕之后才能继续下一个同步。优点：安全。缺点：性能受到影响。
半同步模式：介乎于异步和全同步之间，主库更新完事务之后，也是同步到从库，同步完成之后有一个等待时间，等待时间是tcp/ip的往返时间，一般为5毫秒左右。即在一定程度上保证了效率，也在一定程度上保证了数据的完整性。
2.主从复制的特点：只能主复制到从，从不可以复制到主。都是主的情况下，可以相互复制。
3.主从复制的延迟问题及解决方案：
网络延迟
主从硬件设备（CPU主频、内存的读写性能IO、硬件IO）
同步复制而不是异步复制
解决方案：
硬件方面：主库一般来说不需要动的太多，从库的硬件配置要更好。提升随机写的性能。硬盘可以考虑缓存固态的、升级CPU的核数、扩展一下内存。尽量使用物理机（不要用云服务器）
网络层面：主从服务器都配置在一个局域网内，尽量避免跨网段和跨机房
架构方面：做读写分离，把写入控制在主，从库负责读，减轻从库的压力
配置MySQL方面：从配置文件的角度实现性能最大化
4.MySQL安全和性能配置：
追求安全性配置：数据库的存储引擎为innodb
双一配置：innodb_flush_log_at_trx_commit=1
每次事务提交时都会刷新事务日志。以确保持久性，最高级别的数据安全性，但是会影响性能，默认就是1
0就是事务提交时不会立刻刷新，而是每秒刷新一次，可以提高性能，但是发生故障会导致数据丢失。
2表示事务提交时，事务日志不会写入硬盘而是保存在系统缓存，同时也不会进行刷新。有一定的安全性和性能。但是对内存要求比较高。生成中一般都是默认1.
双一配置：sync binlog=1
#1也是默认值，每次提交事务之后，直接把二进制日志刷新到磁盘，以确保日志的持久性，占用性能比较高，但是安全性高
0表示二进制日志写入到缓存，也不会刷新日志，故障发生也会丢失数据，对内存的要求也提高了
自定义数字N：表示每N个事务才执行一次刷新到磁盘。提高性能，但是一旦崩溃数据也会大量丢失，一般设置为10。
5.追求性能化配置：
sync binlog=10：笔试题重点
innodb_flush_log_at_trx_commit=1
logs-slave-updates=0
#从库的更新不会写入二进制日志（不建议）
innodb buffer_pool_size 300M 500G
#控制innodb存储引擎缓冲池的大小，设置的数值越高，可以提高他的innodb的性能，更多的数据和索引都可以缓存在内存中。减少磁盘的访问次数。对系统内存要求比较高。
6.主从复制如何实现：基于mysql的二进制日志，根据主库的二进制文件的标志为，实现主和从的同步；主从服务器之间，服务器的时间要同步。
主从复制的实验：
主：192.168.127.10
从1：192.168.127.80
从2：192.168.127.90
1.关闭主、从服务器的防火墙及安全机制
2.给主、从安装ntp
3.查看主从服务器时间是否同步：
如果时间不同步的情况下命令行输入：ntpdate ntp.sliyun.com使主从时间一致。
4. 配置主服务器：vim /etc/my.cnf
- 配置完主服务器的文件后重启主的数据库，并进入数据库
- 创建从服务器的用户名并设置密码，给予从服务器连接主服务器的权限，最后查看主服务器的同步位置点（status），master-bin.000001为二进制同步文件，857为同步位置点。
6.配置两台从服务器vim /etc/my.cnf，从1的配置和从2的配置文件不同的地方就是server-id从1为2，从2为3。
从1服务器
从2服务器
- 重启两台从服务器的数据库，并进入数据库
8.进入到两台从服务器的数据库内，配置同步
9.实现
二、读写分离：主从架构基础上，主库负责写，从库只负责读。
1.读写分离的方式：靠代码完成，性能好，不需要额外的硬件设备。
中间层代理服务器，基于客户端和主从架构之间有一个代理服务器，代理服务器收到客户端的请求之后通过客户端的sql语句进行判断，读转到从，写转到主。
2.读写分离最常见的客户端代理软件，java代码开发的一个软件：Amoeba
三.读写实验：用Amoeba来实现读写分离
1.关闭防火墙及安全机制
2.代理服务器安装amoebe及jdk环境
vim /etc/profile
三台Mysql设置权限，允许Amoeba的访问
主服务器
回到代理服务器：修改vim amoeba.xml及vim dbServers.xml的配置文件，修改前先备份
30行、31行、115行、117和120取消注释
23行、26行以下几行、46行以下几行、66行以下几行
启动代理服务器 &后台运行
查看java启动没有
客户端服务器：
安装好了之后重启客户端，查看端口是否启动
回到数据库：三个都需要更改
回到客户端连接代理服务器
创建数据库xy105
回到客户端连接代理服务器，并且创建表及插入数据
四、总结+面试题
1、主从同步复制原理
（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线程将进入睡眠状态，等待下一次被唤xing
2、读写分离你们使用什么方式？
amoeba 代理 mycat 代码 sql_proxy
通过amoeba代理服务器，实现只在主服务器上写，只在从服务器上读；
主数据库处理事务性查询，从数据库处理select 查询；
数据库复制被用来把事务查询导致的变更同步的集群中的从数据库
3、如何查看主从同步状态是否成功
在从服务器上内输入 show slave status\G 查看主从信息查看里面有IO线程的状态信息，还有master服务器的IP地址、端口事务开始号。
当 Slave_IO_Running和Slave_SQL_Running都是YES时 ，表示主从同步状态成功
4、如果I/O不是yes呢，你如何排查？
首先排查网络问题，使用ping 命令查看从服务器是否能与主服务器通信
再查看防火墙和核心防护是否关闭（增强功能）
接着查看从服务slave是否开启
两个从服务器的server-id 是否相同导致只能连接一台
master_log_file master_log_pos的值跟master值是否一致
5、show slave status能看到哪些信息（比较重要）
IO线程的状态信息
master服务器的IP地址、端口、事务开始的位置
最近一次的错误信息和错误位置
最近一次的I/O报错信息和ID
最近一次的SQL报错信息和id
6、主从复制慢（延迟）会有哪些可能？怎么解决？
主服务器的负载过大，被多个睡眠或 僵尸线程占用 导致系统负载过大，从库硬件比主库差，导致复制延迟
主从复制单线程，如果主库写作并发太大，来不及传送到从库，就会到导致延迟
慢sql语句过多
网络延迟
mysql主从复制
若主从版本不一致，从的版本一定要高于主，保证可以向下兼容
因为若主的版本更新，低版本的从无法兼容的。