MYSQL的发展背景和特性;
MYSQL的体系架构组成;
MYSQL的各种存储引擎及适用场景;
MYSQL主从复制的基本原理;
MYSQL常见的主从复制架构和高可用架构;
总结处理复制延迟和复制不一致的问题。
版本介绍:
Mysql GA(ORACLE)
Percon mysql
MariaDB
开源
开放源代码且无版权制约,自主性强、使用成本低可根据
历史悠久、社区及用户非常活跃,遇到问题,可以很快获取到帮助。
可移植:
支持多种操作系统,提供多种api几口,支持多种开发语言。
安全:
有着非常完善的用户和权限系统,当你建立连接时,可以通过加密的方式来保证他通信安全。
Mysql的体系架构:
常用的存储引擎和特性对比
MYSQL从5.5.5版本开始默认存储引擎为InnoDB(表级别)
基本概念
MYSQL从3.2.3版本开始提供复制的功能,复制是指将主库的DDL和DML(除select)操作通过二进制日志传到服务器上(从库),然后再从库上对这些日志重新执行(也叫重做),从而使得从库和主库的数据保持同步。
为什么要做主从复制:
z
辅助备份
分担负载
应用场景
应用场景1:从服务器作为主服务器的实时数据备份
应用场景2:主从服务器实现读写分离,服务器实现负载均衡
应用场景3:把多个从服务器根据业务重要性进行拆分访问
复制的原理
Master:binlog dump 线程。Slave: I/O线程,Slave: SQL线程
异步复制
主节点只需要把写入操作在本地完成,就响应用户。
半同步复制&增强半同步复制
为了保证主库上的每一个binlog事务都能够被可靠的复制到从库上,主库在每次事务提交成功时,并不是及时反馈给客户端用户,而是等待其中一个从库也接收到了binlog并成功将事务记录到了中继日志中,然后才反馈给用户。
rpl_semi_sync_master_timeout
set globalrpl_semi_sync_master_wait_point=AFTER_COMMIT;
半同步复制的配置:
半同步参数需要先注释掉,等初始化完成之后安装好半同步插件,再开启半同步参数
如果是双主架构则主备库都需要安装:
rpl_semi_sync_master_enabled= 1
rpl_semi_sync_slave_enabled= 1
maser
slave
结果:
完全同步的复制
当主库提交事务之后,所有的从库节点必须收到、APPLY并且提交这些事务,然后主库线程才能继续做后续操作。因为需要等待所有从库执行完该事务才能返回,所以全同步复制的性能必然会收到严重的影响。
一主一从
主主复制
一主多从---扩展系统读取的性能,因为读是在从库读取的;
多主一从---5.7开始支持
联级复制
MYSQL的主从复制-高可用架构对比
分类 | MM | MHA | MGR |
优势 | 主主模式能将读写请求分摊到两个主节点,有效提升服务器使用率。 | MHA除了支持日志点的复制还支持GTID的方式 | 基本无延迟,延迟比异步的小很多 |
主节点发生故障后,能快速进行主从切换。 | 同MMM相比,MHA会尝试从旧的Master中恢复旧的二进制日志,只是未必每次都能成功。如果希望更少的数据丢失场景,建议使用MHA架构。 | 支持多写模式,但是目前还不是很成熟 | |
当故障节点恢复后,故障节点能通过复制进行数据恢复(应用其他节点数据)和数据同步(将未同步数据发生给其他节点)。 | 数据的强一致性,可以保证数据事务不丢失 | ||
不足 | 当主节点上MySQL实例发生故障后,可能会存在部分数据(Binlog)未同步到另外的主节点,导致数据丢失(直到故障节点恢复)。 | MHA需要自行开发VIP转移脚本。 | 仅支持innodb |
主主模式下,很容易因数据访问控制不当导致数据冲突。 | MHA只监控Master的状态,未监控Slave的状态 | 只能用在GTID模式下,且日志格式为row格式 | |
为提高系统高可用性,双主架构会被扩展成双主多从结构,同样存在主节点发生故障后多个从库选主和恢复复制的问题。 | |||
适用场景 | 读写都需要高可用的场景 | 一主多从的环境下,MySQL的主从复制是异步或是半同步。 | 对主从延迟比较敏感 |
希望对对写服务提供高可用,又不想安装第三方软件 | |||
数据强一致的场景 |
如何处理同步延迟
1. 如果是机械盘:
set globalinnodb_flush_neighbors=2;
表示刷新在buffer pool 中位于磁盘上相同的extend 区的脏页,通过AIO可以将多个IO写入操作合并为一个IO操作,增大写入量,减少了物理写IO。
2.如果是IO的问题:
set globalinnodb_io_capacity=1200; (默认200)
即每秒的输入输出量(或读写次数)。
3.临时调整:
set globalinnodb_flush_log_at_trx_commit=2; (默认为1)
set globalsync_binlog=0;
同步之后需要调整回:
set globalinnodb_flush_log_at_trx_commit=1;
set globalsync_binlog=1;
错误信息
错误分析
mysqlbinlogmysql-bin.xxx -vv --base64-output=decode-rows --start-position=a--stop-position=b>/tmp/test.log
错误分析结论
200711 8.49 –9:42期间日志中断,原因是这段时间内,主机重启了,而二进制这部分日志传输到备库的时候丢失了。
解决方案
主库:
确定备库丢失的二进制日志的内容(根据时间或者位点信息)
经过排查确定丢失的日志为mysql-bin000333中的start-position=362945607 到 stop-position=363101485的内容。
备库:中端将
mysqlbinlog--skip-gtids --start-position=362945607 --stop-position=363101485mysql-bin000333 |mysql -utest -p -h ip
文章版权归作者所有,未经允许请勿转载,若此文章存在违规行为,您可以联系管理员删除。
转载请注明本文地址:https://www.ucloud.cn/yun/130164.html
摘要:肖鹏微博数据库那些事儿肖鹏,微博研发中心技术经理,主要负责微博数据库相关的业务保障性能优化架构设计,以及周边的自动化系统建设。经历了微博数据库各个阶段的架构改造,包括服务保障及体系建设微博多机房部署微博平台化改造等项目。 showImg(https://segmentfault.com/img/bV24Gs?w=900&h=385); 对于手握数据库的开发人员来说,没有误删过库的人生是...
摘要:编辑器编辑器背景编辑器前段时间遇到一个线上问题,后来排查好久发现是因为主从同步延迟导致的,所以今天写一篇文章总结一下这个问题希望对你有用。编辑器几句唠叨编辑器大家好,我是小饭,一枚后端工程师。背景前段时间遇到一个线上问题,后来排查好久发现是因为主从同步延迟导致的,所以今天写一篇文章总结一下这个问题希望对你有用。如果觉得还不错,记得加个关注点个赞哦思维导图思维导图常见的主从架构随着日益增长的访...
阅读 1249·2023-01-11 13:20
阅读 1557·2023-01-11 13:20
阅读 1011·2023-01-11 13:20
阅读 1680·2023-01-11 13:20
阅读 3971·2023-01-11 13:20
阅读 2519·2023-01-11 13:20
阅读 1310·2023-01-11 13:20
阅读 3486·2023-01-11 13:20