数据库主从复制和读写分离

主从数据库和数据库集群的一些问题
数据库集群和主从数据库最本质的区别，其实也就是data-sharing和nothing-sharing的区别。集群是共享存储的。主从复制中没有任何共享。每台机器都是独立且完整的系统。

什么是主从复制?
主从复制，是用来建立一个和主数据库完全一样的数据库环境，称为从数据库；主数据库一般是准实时的业务数据库
主从复制的作用（好处，或者说为什么要做主从）
1、做数据的热备，作为后备数据库，主数据库服务器故障后，可切换到从数据库继续工作，避免数据丢失。
2、架构的扩展。业务量越来越大，I/O访问频率过高，单机无法满足，此时做多库的存储，降低磁盘I/O访问的频率，提高单个机器的I/O性能。
3、读写分离，使数据库能支撑更大的并发，写耗时太长了，会影响读的速度。在报表中尤其重要。由于部分报表sql语句非常的慢，导致锁表，影响前台服务。如果前台使用master，报表使用slave，那么报表sql将不会造成前台锁，保证了前台速度。读数据时不能加写锁写数据（只在主数据库写，写完同步到从数据库；只在从数据库读） 在数据库读多写少时可以用，多个slave可以减轻读的压力，且写操作在主数据库不影响读。
读写分离的实现方法
基于程序代码内部实现
在代码中根据 select、insert 进行路由分类，这类方法也是目前生产环境应用最广泛的
优点是性能较好，因为在程序代码中实现，不需要增加额外的设备为硬件开支；缺点是需要开发人员来实现，运维人员无从下手
但是并不是所有的应用都适合在程序代码中实现读写分离，像一些大型复杂的Java应用，如果在程序代码中实现读写分离对代码改动就较大
②基于中间代理层实现
代理一般位于客户端和服务器之间，代理服务器接到客户端请求后通过判断后转发到后端数据库，有以下代表性程序。MySQL-Proxy，MySQL-Proxy 为 MySQL 开源项目，通过其自带的 lua 脚本进行SQL 判断。

主从复制的原理（重中之重，面试必问）：
主要是基于日志：master二进制日志，slave中继日志
1、Master节点将数据的改变记录成二进制日志（bin log），当Master上的数据发生改变时，则将其改变写入二进制日志中
2.Slave节点会在一定时间间隔内对Master的二进制日志进行探测其是否发生改变，如果发生改变，则开始一个I/O线程请求 Master的二进制事件。同时Master节点为每个I/O线程启动一个dump线程，用于向其发送二进制事件，并保存至Slave节点本地的中继日志（Relay log）中
3、Slave节点将启动SQL线程从中继日志中读取二进制日志，在本地重放，即解析成 sql 语句逐一执行，使得其数据和 Master节点的保持一致，最后I/O线程和SQL线程将进入睡眠状态，等待下一次被唤醒

主从复制慢(延迟)有哪些可能？
主服务器的负载过大，被多个睡眠或者僵尸线程占用，导致系统负载过大
从库硬件比主库差，导致复制延迟
主从复制单线程，如果主库写并发太大，来不及传送到从库，就会导致延迟
慢SQL语句过多

主从复制慢(延迟)解决方案
1、主库同步写到从库再返回，牺牲了写的效率，不推荐；
2、对于强一致性的场景，读请求强制读主数据库，这样从库没意义了；
3、中间件选择路由。这种方案需要使用一个中间件，所有数据库操作都先发到中间件，由中间件再分发到相应的数据库。写请求多记录一个key（可以加主键）,读请求，如果此时 key 存在，将会路由到主库,一定时间后（经验值），中间件认为主从同步完成，删除这个 key，后续读将会读从库.
4/ Redis缓存路由大法(推荐)这种方案与中间件的方案流程比较类似，不过改造成本相对较低，不需要增加任何中间件。写请求发往主库，同时缓存记录操作的 key，缓存的失效时间至少设置为主从的延时的时间

主服务器宕机了如何处理，从服务器宕机如何处理？
主库宕机：
(1)确保所有的relay log全部更新完毕，在每个从库上执行show processlist可以查看更新是否完成
(2)更新完毕后，登录所有从库查看master.info文件，对比选择pos最大的作为新的主库，
(3)后登录这个新的主库，执行stop slave；进入主目录，删除master.Info和relay-log.info配置my.cnf文件开启log-bin文件
(4)创建用于同步的用户并授权slave
(5)登录另外一台从库，执行stop slave停止同步
(6)执行start slave
(7)修改新的master数据，测试slave是否同步更新

从库宕机：
(1)查看从库上mysql的错误日志，里面有记录主从挂掉时的binlog信息。
(2)有了binlog和postion信息后，只需要重新在从库上进行change master to配置即可。配置后开启slave状态，没有报错
(3)查看slave状态，发现slave已经正常了，开始进行延时数据恢复。

主从复制读写分离的实际操作案例
准备工作
除了客户端，都需要先源码编译安装好MySQL
都需关闭防火墙及控制访问机制
systemctl stop firewalld
systemctl disable firewalld
#关闭防火墙（及开机禁用）
setenforce 0
#关闭安全访问控制机制
主从时钟同步
主服务器设置
#安装 NTP
yum -y install ntp
#配置 NTP
vim /etc/ntp.conf
#末行添加以下内容
server 127.127.126.0
fudge 127.127.126.0 stratum 8
#设置本地是时钟源，注意修改网段
#设置时间层级为8（限制在15内）

#重启服务
service ntpd restart
从服务器设置
yum -y install ntp ntpdate
#安装服务，ntpdate用于同步时间
service ntpd start
#开启服务
/usr/sbin/ntpdate 192.168.126.11
#进行时间同步，指向Master服务器IP
crontab -e
#写入计划性任务，每半小时进行一次时间同步
*/30 * * * * /usr/sbin/ntpdate 192.168.126.11
配置主服务器
vim /etc/my.cnf
#配置以下内容
server-id = 1
log-bin=master-bin
#添加，主服务器开启二进制日志
log-slave-updates=true
#添加，允许从服务器更新二进制日志
systemctl restart mysqld
#重启服务使配置生效
mysql -uroot -p123123
#登录数据库程序，给从服务器授权
GRANT REPLICATION SLAVE ON . TO ‘myslave’@‘192.168.126.%’ IDENTIFIED BY ‘123123’;
FLUSH PRIVILEGES;
show master status;
quit

从服务器配置
vim /etc/my.cnf
server-id = 2
#修改，注意id与Master的不同，两个Slave的id也要不同
relay-log=relay-log-bin
#添加，开启中继日志，从主服务器上同步日志文件记录到本地
relay-log-index=slave-relay-bin.index
#添加，定义中继日志文件的位置和名称
systemctl restart mysqld
mysql -uroot -p123123
change master to master_host=‘192.168.126.11’ , master_user=‘myslave’,master_password=‘123123’,master_log_file=‘master-bin.000001’,master_log_pos=604;
#配置同步，注意 master_log_file 和 master_log_pos 的值要与Master的一致

start slave;
#启动同步，如有报错执行 reset slave;
show slave status\G
#查看 Slave 状态
//确保 IO 和 SQL 线程都是 Yes，代表同步正常

Slave_IO_Running: Yes
#负责与主机的io通信
Slave_SQL_Running: Yes
#负责自己的slave mysql进程