- 实现在不同服务器上的分布:
- 利用二进制日志增量进行;
- 不需要太多的带宽,但是使用基于行的复制在进行大批量的更改时,会对带宽带来一定的压力,特别是跨IDC环境下进行的复制;
- 应该分批进行
- 实现数据读取的负载均衡,需要其他组件配合使用
- 增加数据的安全性
- 实现数据库高可用和故障切换
- 实现数据库在线升级
建议使用binlog_format=MIXED 或者 binlog_format=ROW并设置binlog_row_image=MINIMAL
- 基于段的日志格式: binlog_format=STATEMENT
- 基于行的日志格式: binlog_format=ROW
- binlog_row_image=[FULL|MINIMAL|NOBLOB]
- mysqlbinlog -vv 日志文件名称;
- 混合日志格式:binlog_format=MIXED
- 根据sql语句由系统决定使用基于段还是基于行的日志格式;
- 数据量的大小由所执行的sql语句决定
缺点:
- 生成的日志量少,节约网络传输IO
- 并不强制要求主从数据库的表定义完全相同
- 相比于基于行的复制方式更为灵活
- 对于非确定性事件,无法保证主从数据的一致性
- 对于存储过程,触发器,自定义函数进行的修改也可以造成数据不一致
- 相对于基于行的复制方式在从上执行时需要更多的行锁
缺点:
- 可以应用于任何SQL的复制包括非确定确定函数,存储过程等;
- 可以减少数据库锁的使用
- 要求主从数据库的表的结构相同,负责可能会中断复制;
- 无法在从服务器上单独执行触发器
- 1.在主DB服务器上建立复制账号
- create user 'repl' @ 'IP段' identified by 'password';
- grant replication slave on *.* to 'repl' @ 'IP段';//授权
- 2.配置主库服务器
- bin_log=mysql-bin
- server_id = 100
- 3.配置数据库从服务器
- bin_log = mysql-bin
- server_id = 101
- relay_log = mysql-relay-bin
- log_slave_update = on[可选]
- read_only = on[可选]
- 4.初始化从服务器数据
- mysqldump --master-data=2 -single-transaction
- xtrabackup --slave-info[对innodb性能不进行锁表]
- 5.启动复制链路
- change master to master_host = '主服务器的ip地址' ,
- master_user = 'repl',
- master_password = 'password',
- master_log_file = 'mysql_log_file_name',
- master_log_pos = 4;
- 实际的配置:
- 1.配置主库:
- create user repl@'192.168.25.%' identified by '123456';
- grant replication slave on *.* to repl@'192.168.25.%';
- 2.修改主从配置文件
- 3.主数据库备份:mysqldump --single-transcation --master-data --triggers -- routines --all-databases >> all.sql
- 4.将主库的生成的备份文件传递到从服务器上:scp all.sql root@192.168.15.130:/root
- 5.在从服务器上执行该sql文件: mysql -uroot -p < all.sql
- 6.在从服务器上配置数据链路:change master to master_host='192.168.25.33',
- master_user='repl',
- master_password='123456',
- master_log_file='mysql-bin.0000003',
- mater_log_pos=1829;
- 7.在从服务器上启动复制链路:start slave;
- 基于日志点的复制优点:
- 是mysql最早的复制技术,bug较少
- 对于sql查询没有任何限制
- 故障处理比较容易
- 基于日志点的复制缺点:
- 故障转移时重新获取新主的日志点的信息比较困难
- 1.在主DB服务器上简历复制账号
- create user 'repl' @ 'IP段' identified by 'password';
- grant replication slave on *.* to 'repl' @ 'IP段';//授权
- 2.配置主库服务器
- bin_log=mysql-bin
- server_id = 100
- gtid_mode = on
- enforce-gtid-constistency
- 不支持以下操作:create table ... select
- 在事务中使用create temporary建立临时表
- 使用关联更新事务表和非事务表
- log-slave-updates = on[5.7版本之前加]
- 3.配置数据库从服务器
- server_id = 101
- relay_log = mysql-relay-bin
- gtid_mode=on
- enforce-gtid-constistency
- read_only = on[可选]
- master_info_repository=table
- relay_log_info_repository=table
- 4.初始化从服务器数据
- mysqldump --master-data=2 -single-transaction
- xtrabackup --slave-info
- 5.启动复制链路
- change master to master_host = '主服务器的ip地址' ,
- master_user = 'repl',
- master_password = 'password',
- master_auto_position=1;
- 基于gtid的复制的优点:
- 可以很方便的进行故障的转移
- 从库不会丢失主库上的任何修改
- 基于gtid的复制的缺点:
- 故障处理比较复杂
- 对执行的SQL有一定的限制
- 优点:配置简单
- 可以用多个从库分担读负载
- 用途:为不同业务使用不同的从库
- 将一台从库放到远程的IDC中,用作灾备恢复
- 分担主库的读负载
- 缺点:
- 产生数据冲突而造成复制链路的中断
- 耗费大量的时间
- 造成数据的丢失
- 主主模式下的主主复制的配置的注意事项:
- 两个主中所操作的表最好能够分开
- 使用下面两个参数自增ID的生成
- auto_increment_increment = 2
- auto_increment_offset = 1|2
- 特点:
- 只有一台主服务器对外提供服务
- 一台服务器处于只读状态并且只作为热备使用
- 在对外提供的主库出现故障或是计划性的维护时才会进行切换,使原来的备库成为主库,而原来的主库会成为新的备库并处理只读或下线状态,待维护完成后重新上线
- 主备模式下的主主复制的配置的注意事项:
- 确保两台服务器上的初始化的初始数据相同
- 确保两台服务器上已经启动binlog并且有不同的server_id
- 在两台服务器上启用log_slave_updates参数
- 在初始的备库上启用read_only
- 利用sun共享存储或者drdb磁盘复制解决MySQL单点故障
- 利用多写集群或者NDB集群来解决MySQL单点的故障
- 利用MySQL的复制来解决MySQL的单点登录的问题
在主库出现宕机时进行故障转移并自动配置其他从对新主的复制
提供了主,写虚拟ip,在主从服务器出现问题时可以自动迁移虚拟ip
名称资源 | 数量 | 说明 |
---|---|---|
主DB服务器 | 2 | 用于主备模式的主主复制配置 |
从DB服务器 | 0-N | 可以配置0台或多台从服务器,但建议不要太多 |
监控服务器 | 1 | 用于监控mysql监控集群 |
IP地址 | 2*(n+1) | n为MySQL服务器的数量 |
监控用户 | 1 | 用于监控数据库状态的MySQL用户(replication client) |
代理用户 | 1 | 用于MMM代理的MySQL用户(super,replication client,process) |
复制用户 | 1 | 用于配置MySQL复制的MySQL用户(replication slave) |
MySQL高可用架构之MMM架构的详细配置
》MMM集群的优点:
》MMM集群的缺点:
监控主数据库服务器是否可用
当主DB不可用时,从多个从服务器中选举出新的主数据库服务器
提供了主从切换和故障转移功能(MHA可以半同步功能结合起来使用)
- ssh -keygen
- ssh-copy-id -i /root/.ssh/id_rsa '-p 22 root@192.168.3.100
- ssh-copy-id -i /root/.ssh/id_rsa '-p 22 root@192.168.3.101
- ssh-copy-id -i /root/.ssh/id_rsa '-p 22 root@192.168.3.102
- perl-Parallel-ForkManager perl-Log-Dispatch-Perl.noarch
- per-DB-MySQL ncftp`
- 数据节点:yum -y install perl -DBD-MySQL ncftp perl-DBI.X86
MySQL高可用架构之MHA介绍及配置
》MHA集群的优点:
》MMM集群的缺点:
程序实现的读写分离
- 优点:由开发人员控制什么样的查询再从库上来执行,因此比较灵活
- 由程序直接连接诶数据库,所以性能损耗比较少
- 缺点:增加了开发的工作量,使得程序代码更为复杂人为控制,
- 容易出现错误
中间件的读写分离(mysql-proxy、maxScale)
- 优点:中间件根据查询语法的分析,自动完成读写分离;
- 对程序透明,对已有的程序不用做任何的调整。
- 缺点:增加了中间层,所以对查询效率有损耗;
- 对于延迟敏感业务无法在主库上执行
软件:LVS、Haproxy、MaxScale
硬件:F5
maxScale实现读写分离及负载均衡
来源: https://juejin.im/post/5a040cfef265da432c234d2d