马老师 生产环境mysql主从复制、架构优化方案

Binlog日志(主服务器) => 中继日志(从服务器 运行一遍,保持一致)。从服务器是否要二进制日志取决于架构设计。如果二进制保存足够稳定，从性能上来说，从服务器不需要二进制日志。默认情况下，mysql主从复制是异步的。

异步：命令写操作是在内存中完成的。同步：在磁盘完成才认定写操作是完成的。

异步：主服务器执行10条命令，主服务器不等待从服务器，从服务器才复制3条命令道中继日志。这叫做从服务器的延迟delay。异步延迟是难免的。

Mysql是多用户的，多个用户进来并发 发起 写操作，同时进行的，写到写到二进制语句是一条一条的，从服务器一次执行一条，是单线程的。比主服务器慢是难免的。

整个复制架构：3个线程，主服务器dump线程，发送到从服务器上。从服务器上IO线程，接受主服务器上dump线程发送过来的数据，写入到中继日志中去。而后一旦中继日志有心内容，SQL线程一句一句执行内容。

以上，所以配置就是：主服务器启用bin log日志，从服务器启用relay log，建立身份标示server id，每台服务器需要唯一的server id。

负载均衡集群

高可用集群:冗余

高性能集群：完成复杂运算

AXFR：AXFR请求，是从DNS服务器请求在主DNS服务器上更新信息的一类域名系统的请求。AXFR请求经常导致全区域传输。如果区域文件很大的话，它需要花费很多的时间并消耗可观的带宽。

IXFR：增量区域传输，增量区域传输协议。

权限：

主服务器建立账户，从服务器使用账户。mysql有一些特殊的权限允许复制进程运行，运行在从服务器上的I/O线程创建了到master的连接，这就意味着必须在主服务器上创建一个用户并且需要授予特殊的权限。

这样I/O线程就会一特定的身份连接到主服务器上并且读取二进制日志。但是需要说明的一点是，复制用户在主服务器上实际只需要 replication client 权限就可以运行的，这里授予replication slave的原因是用于监视和管理复制账号需要这个权限，并且这两个功能（复制需要的权限，监视和管理复制账号权限）通常是一个账号在管理，而不是为了达 到这两个目标而分别设置2个账号。

replication slave

replication client

主服务器和从服务器双双互相认证，SSL认证。

基于逻辑，Mysql Dump从主服务器复制到从服务器。Mysql有一个选项master data，从什么地方读取二进制数据。主服务器放在逻辑卷上，从服务器基于备份也可以放逻辑卷上。

CHANGE MASTER TO master_def[,master_def] ...

可以更改从属服务器用于与主服务器进行连接和通讯的参数。

mysql>CHANGE MASTER TO
->    MASTER_HOST='master2.mycompany.com',
->    MASTER_USER='replication',
->    MASTER_PASSWORD='bigs3cret',
->    MASTER_PORT=3306,
->    MASTER_LOG_FILE='master2-bin.001',
->    MASTER_LOG_POS=4,
->    MASTER_CONNECT_RETRY=10;

show slave status,检查以下两项是否启动：

Slave_IO_Running: Yes

Slave_SQL_Running: Yes

如何让从服务器的mysql服务在启动时候不要自动启动从服务线程？
在从服务器上
[mysqld]
skip-slave-start=1

数据库复制过滤：
主服务器：
binlog_do_db
binlog_ignore_db

无论怎么过滤，都不在主服务器上做过滤。任何不涉及到的数据库相关的写操作都不会记录到二进制中。

从服务器：
replicate_do_db
replicate_ignore_db
replicate_do_table
replicate_ignore_db
基于通配符的匹配
replicate_wild_ignore_db = mysql.%
replicate_wild_do_db = magedu.%

浪费额外的网络带宽，复制过来的数据没用。

主服务器崩溃：事务已经提交-->写入二进制日志：
在主从架构上建议使用的配置：
主服务器：
sync_binlog=1
innodb_flush_logs_at_trx_commit=1

从服务器
skip_slave_start=1
read_only=1

使用mysql的sharding，多台服务器写操作。切分主要有两种方式：水平切分（Horizental Sharding）和垂直切分（Vertical Sharding）。水平切分所指的是通过一系列的切分规则将数据水平分布到不同的DB或table中，在通过相应的DB路由 或者table路由规则找到需要查询的具体的DB或者table以进行Query操作，比如根据用户ID将用户表切分到多台数据库上。垂直切分指的是按业务、产品切分，将不同类型的数据且分到不同的服务器上，通过数据库代理疏通程序与多个数据库的通讯、降低应用的复杂度。

读写分离简单的说是把对数据库读和写的操作分开对应不同的数据库服务器，这样能有效地减轻数据库压力，也能减轻io压力。主数据库提供写操作，从数据库提供读操作，这样既避免了主数据库服务器（Master）的过载，也有效地利用了从数据库服务器（Slave）的资源。

主主(互为主从)架构
1、双方都要建立有复制权限的用户；2、不同的server id；3、双方都要开启二进制日志和中继日志；4、在启动之前必须知道左服务器的二进制日志文件名和位置、右服务器的二进制日志文件名和位置。

主从分离(实现分层)



读写分离（代理），常用的由mysql官方提供的mysql proxy 和阿里巴巴开源的Amoeba。

已经听完第八讲。。。