一、什么是高可用维基百科定义高可用性high availability缩写 HA指系统无中断地执行其功能的能力代表系统的可用性程度。高可用性通常通过提高系统的容错能力来实现。MySQL 的高可用是如何实现的呢首先我们来看张图过程开始时处理流程主要是场景一客户端读、写访问的是主库主库通过某种机制将数据实时同步给备库当主库突然发生故障如磁盘损坏等无法正常响应客户端的请求。此时会自动主备切换进入场景二客户端读写访问的是备库此时备库升级为新主库看似天衣无缝那是不是可以高枕无忧了呢兄弟想多了主备切换确实能满足高可用。但有个前提主备库的数据要同步。不过数据同步是个异步操作不可能做到实时所以说主备延迟是一定存在的二、什么是主备延迟主库完成一个事务写入binlog。binlog 中有一个时间字段用于记录主库写入的时间【时刻 t1】binlog 同步给备库备库接收并存储到中继日志 【时刻 t2】备库SQL执行线程执行binlog数据写入到备库表中 【时刻 t3】主备延迟时间计算公式t3 - t1有没有简单命令直接查看。在备库执行show slave status命令seconds_behind_master表示当前备库延迟了多少秒心细的同学会有疑问了 t3 和 t1 分属于两台机器如果时钟不一致怎么办初始化时备库连接到主库会执行SELECT UNIX_TIMESTAMP()来获得当前主库的系统时间。如果发现主库的系统时间与备库不一致备库在计算seconds_behind_master会自动减掉这个差值。注意binlog 数据传输的时间t2 - t1非常短可以忽略。主要延迟花费在备库执行binlog日志三、主备延迟常见原因1、备库机器配置差这个不难理解“门当户对”、“志同道合”如果主备机器的性能差别大直接导致备库的同步速度跟不上主库的生产节奏。就像跑步一样落后差距会越来越大。解决方案1、升级备库的机器配置2、备库干私活备库除了服务于正常的读业务外是否有被其他特殊业务征用如运营数据统计等这类操作非常消耗系统资源也会影响数据同步速度。解决方案可以借助大数据平台数据异构满足各种这些特殊的统计类查询。3、大事务我们知道 binglog 是在事务提交时才生成的。如果是处理大事务执行时间比较长比如 5分钟。虽然备库很快拿到 binlog但是在备库回放执行也要花费差不多的时间也要 5分钟 备库中只有这个事务执行完提交备库才真正对外可见从而导致主备延迟很大。比如 delete 操作慎用delete from 表名建议采用分批删除减少大事务。四、主库不可用主备切换有哪些策略1、可靠优先当主库A 发生故障不可用时开始进入主备切换首先判断 B库seconds_behind_master是否小于设定的阈值比如 4 秒如果满足条件将 A库 改为只读状态将 readonly 设置为 true。断掉 A 库的写入操作保证不会有新的写流量进来判断 B库的seconds_behind_master直到为 0修改 B库 为读、写状态客户端的请求打到 B库此时主备切换完成。优点数据不会丢失所以我们称为可靠性高缺点中间有个阶段A库和B库都是只读状态此时系统对外不能提供写服务。2、可用优先当然我们也可以不用等主备数据同步完成在一开始时就直接将流量切到备库。这样备库的流量就可能有两个来源主库之前的剩余流量 binlog客户端新请求进来的流量两部分流量冲击会对数据一致性造成一些影响。我们来做个实验首次创建一个用户表CREATE TABLE person ( id bigint(20) unsigned NOT NULL AUTO_INCREMENT, name varchar(32) , PRIMARY KEY (id) ) ENGINEInnoDB;插入2条记录insert into person(name) values (tom); insert into person(name) values (jerry);实验一将 binlog 的格式设为 binlog_formatrow说明row 模式写 binlog 时会记录所有字段的值库A 、库B 在做数据同步时都会报主键冲突最后只有一行数据不一致但是会丢数据。优点同步过程中出现问题能够及时发现。实验二将 binlog 格式设置为statement或者mixed按照 SQL 原始语句同步 binlog可以看到数据条数不会少但是主键id会出现混乱。3、结论本着 攘外必先安内 保证内部的数据的正确性是我们的首选。所以一般建议大家选择可靠优先。但是可靠优先可能会导致一定时间内数据库不可用。这个时间值取决于主备延迟的时间大小。所以我们应尽可能缩短主备库的延迟时间大小这样一旦主库发生故障备库才会更快的同步完数据主备切换才能完成服务才能更快恢复。