目录
一、不停库不锁表在线主从配置
二、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
网友评论