目录
一、不停库不锁表在线主从配置
二、MySQL主主复制
三、关于auto_increment
四、MySQL读写分离
一、不停库不锁表在线主从配置
mysqldump适合备份10G以下的数据量，比较方便快捷。当需要备份的数据量达到100G以上时，mysqldump对原库的压力太大，导出性能很差。此时Percona-Xtrabackup备份工具是更好的选择，Percona-Xtrabackup支持在线热备份(备份时不影响数据读写)，它有以下优势：
xtrabackup优势：
- 对InnoDB引擎的表做热备
- 增量备份
- 流压缩传输到另外的服务器上
- 在线移动表
- 更简单的创建主从同步
- 备份时不增加服务器负载
使用 Xtrabackup 在线对MySQL做主从复制具体操作步骤详见如下链接：http://seanlook.com/2015/12/14/mysql-replicas/
MYSQL主从同步因主键冲突导致的主从无法同步情况
解决方法参考如下两个链接：
http://www.rfyy.net/archives/2309.html
http://blog.51cto.com/storysky/259280
二、MySQL主主复制
原理：主主复制在两台MySQL互为主从，它们都可以变更数据，其中一台变更了数据另外一台也会同步相应的变更。
- 架构方案思路：
- 两台mysql都可读写，互为主备，默认只使用一台（masterA）负责数据的写入，另一台（masterB）备用。
- masterA是masterB的主库，masterB又是masterA的主库，它们互为主从。
- 两台主库之间做高可用,可以采用keepalived等方案（使用VIP对外提供服务）。
- 所有提供服务的从服务器与masterB进行主从同步（双主多从）。
- 建议采用高可用策略的时候，masterA或masterB均不因宕机恢复后而抢占VIP（非抢占模式）。
这样做可以在一定程度上保证主库的高可用,在一台主库down掉之后,可以在极短的时间内切换到另一台主库上（尽可能减少主库宕机对业务造成的影响），减少了主从同步给线上主库带来的压力。
- 不足：
- masterB可能会一直处于空闲状态（可以用它当从库，负责部分查询）。
- 主库后面提供服务的从库要等masterB先同步完了数据后才能去masterB上去同步数据，这样可能会造成一定程度的同步延时。
三、关于auto_increment
MySQL中对于表上ID自增列可以在创建表的时候指定列上的auto_increment属性和auto_increment_offset属性。
auto_increment_increment控制列中的值的增量值，也就是步长。
auto_increment_offset确定AUTO_INCREMENT列值的起点，也就是初始值。
四、MySQL读写分离
- 原理：
读写分离就是在主服务器上修改，数据会同步到从服务器，从服务器只能提供读取数据，不能写入，实现备份的同时也实现了数据库性能的优化，以及提升了服务器安全。
- 目前较为常见的Mysql读写分离分为以下两种：
- 基于程序代码内部实现
在代码中根据select 、insert进行路由分类，这类方法也是目前生产环境下应用最广泛的。优点是性能较好，因为程序在代码中实现，不需要增加额外的硬件开支，缺点是需要开发人员来实现，运维人员无从下手。- 基于中间代理层实现
代理一般介于应用服务器和数据库服务器之间，代理数据库服务器接收到应用服务器的请求后根据判断后转发到，后端数据库，有以下代表性的程序。
一些扩展
mysql-proxy 实现读写分离
http://blog.51cto.com/zzclinux/1980487
mysql-proxy类似的产品有：
mycat 基于阿里的开源软件cobar，官网 www.mycat.io
https://my.oschina.net/ruoli/blog/1789370
mycat实现分库分表
https://www.cnblogs.com/joylee/p/7513038.html
atlas 出自于360，不维护不更新了 https://blog.csdn.net/AnPHPer/article/details/80566385
mysql环形主从
http://ask.apelearn.com/question/11437
mysql架构演变 http://www.aminglinux.com/bbs/thread-8025-1-1.html
MHA架构
http://blog.51cto.com/xiaoshuaigege/2060768
比较复杂的mysql集群架构 http://ask.apelearn.com/question/17026
