分布式系统，高可用是一个很重要的指标。
当选择 mysql 作为分布式系统的数据库，高可用也是必须要考虑的。
那么，mysql是如何保证高可用的呢？
有的同学可能听过一个词，叫做：mysql主备。
对，mysql就是通过主备来保证高可用。
搭建mysql主备，需要那些组件呢？
见名思义，首先需要一个主库，一个备库。
接着问题又来了，客户端如何知道主库是哪个，备库是哪个？
这里，就需要一个HA系统，客户端的业务sql，直接发到HA系统，由HA系统来负责透传到主库。当然，HA系统也必须保证高可用。
另外，主备切换，也由HA系统来主导。
好了，又来了一个问题，主备，如何保证备库的数据和主库一致呢？
这里，需要通过主备数据复制来实现。
主库写binlog后，有一个专门的线程，负责将数据传输给备库，备库写入relay log，接着sql_thread负责执行binlog日志。
还有一个问题，为了保证数据的准确性，建议bin_log的日志格式设置为row，如此，可以保证主备库类似时间字段、系统递增主键的一致性。
那么，是不是有了主备架构，高可用就完全保证了呢？
并不是如此。
一般，为了数据的准确性，主备切换时，从主库不可用，到备库数据追上主库的的时间段，整个数据库是不可用的。所以，主备延迟，就成了mysql高可用指标的一个关键因素。
影响主备延迟的因素有哪些呢？大致有如下几个原因：
1. 备库性能远不如主库。 一般，备库是当主库不可用时，临时顶一顶流量，所以很多时候硬件性能配置的不如主库。
2. 备库承担压力大，CPU彪高。 比如有的公司将备库作为管理系统的查询数据源，使用不当，就会导致CPU彪高，加大主备延迟。
3. 大事务。由于主库事务执行完后，才会写binlog，这样就会导致备库延迟。
4. 大表DDL。
5. 备库并行复制能力。由于sql_thread执行binlog日志效率问题，可能导致备库数据追不上主库。所以mysql5.6后，陆续出了很多sql_thread并行执行策略。