复制功用：
数据分布
负载均衡：读操作，适用于读密集型的应用
备份
高可用和故障切换
MySQL升级测试
在从服务器上有两个线程：
I/O线程：从master请求二进制日志信息，并保存至中继日志
SQL线程：从relay log中读取日志信息，在本地完成重放
在主服务器上为每个从服务器的I/O线程启动一个dump线程，向其发送binary log events
过程图：
补充：对数据库修改的操作首先得应用到磁盘文件才能被写入磁盘二进制日志，因此不可避免从服务器上的数据是会落后于主服务器的
随着网站的发展，当主节点拥有过多从服务器，会给主节点带来过大压力，可以专门使用一台从服务器从主节点上复制二进制日志，再使此从节点变为其他从节点的主节点
过程图：
补充：第一台从服务器不需要存储数据，它只负责传递二进制日志，因此此从服务器的数据库引擎使用BLACKHOLE 当重放中继日志时，它会把所有的数据都放入/dev/null（这相当于一个宇宙黑洞）
二进制日志的格式：建议使用mixed模式，如果可以使用row模式
主从配置过程：
主：1.启用二进制日志，2.设置一个在当前集群中惟一的server-id(以上两步在配置文件中修改）:
3.创建一个有复制权限(REPLICATION SLAVE, REPLICATION CLIENT)账号：
grant replication slave,replication client on *.* to 'repl'@'%' identified by 'replpass';
flush privileges;
从：1.启用中继日志，2.设置一个在当前集群中惟一的server-id(以上两步在配置文件中修改）:
3.使用有复制权限用户账号连接至主服务器，并启动复制线程:
change master to master_host='192.168.238.224',master_user='repl',master_password='replpass',master_log_file='ON.000003',master_log_pos=4;
使用help change master to查看命令帮助
start slave; 开启I/O和SQL线程
show slave status; 查看同步状态，其中的Seconds_Behind_Master可以查看是否落后主节点，以及落后多少
查看从节点是否只读show global variables like 'read_only';
log_slave_updates = 1 （允许备库将其重放的事件也记录到自身的二进制日志，这样自己既可是从节点也可是主节点）
sync_binlog =1 mysql每次在提交内存中的事物会将内存中的二进制日志同步到磁盘上，保证在服务器崩溃的时候不会丢失事件
innodb_support_xa 默认为true，如果关闭则binlog记录事务的顺序可能与实际不符，造成slave不一致
如果有一台新的从服务器加入，该怎么融入架构中：
1.在主节点做一个完全备份，并记录二进制日志文件及位置
2.在从节点恢复此完全备份，并在启动复制时从记录的二进制日志文件和位置开始
问题：如何提供主节点的高可用？