使用MySQL服务一般会遇到的疑惑

主题

本文首发公众号【一名打字员】

今天主要分享一下在服务端使用MySQL服务时，会遇到的几个经典问题以及对应的建议解决方案，如有雷同，绝对不是巧合。

MYSQL容灾快速切换方案

说到容灾，本猿公司以前就是自己买的服务器，然后找的机房托管，然而估计是一家不咋“靠谱”的机房，为啥这么说呢，谁家机房没事就迁移，然后临时性的断电就出现了不下于两次，由于公司的数据库都是自己维护，断电导致了几次数据异常，吃了几次苦头之后，公司就舍弃了地方机房，果断放在云上面。
当然，当时我们也没有做任何容灾措施，面对机房级灾难根本束手无措。接下来，本猿简单介绍一下自己所理解的MySQL中常用的容灾方案.

1. 复制

通常，我们的客户端进行读写操作是，往往是对主库进行写入，然后在从库中进行读操作，然后主从库之间会进行replication(复制)。

当主库宕机的时候，我们可以很快的将备库推出来，充当主库的角色，来保证业务的顺利进行。
这样的话对复制过程中延迟的时间要求比较高。假设，如果是执行单挑数据执行时间为T，则延迟为T，那么耗费的时间是2T。执行一个事务（N条操作）的话，会先缓存到cache中，等待全部执行写入操作结束，延迟的时间则为N*T。
当数据库吞吐量到达一定程度时，这个延迟会变的很大，这时候就会产生许多其它的维护成本。至于主备库如何解决延迟问题，请移步下面的问题。

2.利用zookeeper容灾切换

在上面我们介绍了MySQL复制的相关知识，而且MySQL的复制机制很强大，我们能够保证数据不丢失，但是如何保证主备如何在宕机时无缝切换并将相应的故障转移处理呢，怎么才会马上知道自己的主库挂掉了，而不是痴痴的等其他部门找上门来兴师问罪，这时候就需要一个好的监控工具了，在这里本猿推荐使用zookeeper，之前公司也是用zookeeper管理的dubbo的一个微服务集群，这样MySQL的监控和失效备援就能顺利的解决了，同时也能够协调多个服务之间进行事件处理。
通常，我们监控服务的时候，基本上是采用保持存活或者心跳的方式，就像之前对dubbo服务的管理，本猿更中意与发送心跳包来检测服务存活的方式。所以对于每一个MySQL实例，都会有一个AGENT程序，它与MySQL示例放在同一台机器上，97影院并定时对齐检测可用性，这样当机器挂掉的时候，agent与zookeeper断开连接，zookeeper则会马上感知。又或者是agent无法检测到MySQL的存活状态，则也会对zookeeper发出通知，另外agent挂掉的时候，失败事件也会进行重启或者其它的操作。

MYSQL哪种存储引擎好

在网络上有关于针对InnoDB引擎与MyISAM引擎进行了测试。
其结果大致为1W与10W的select、update与delete操作都很快，在1ms一下。insert操作受数据规模影响较少。在100w调数据以上InnoDB引擎有相对优势，在数据规模在10w条以下的，MyISAM引擎有相对优势，但是注意，使用InnoDB引擎要注意填写配置，在缺省参数配置下性能较差。

MYSQL的应用是否会造成数据的丢失

答案肯定是会的，正所谓常在河边走，哪能不湿鞋。无论是上面说的机房断电或者服务器异常还是硬盘坏掉都会造成数据的丢失，一般大厂在线上时，都会使用应用双写，也就是写两份来保证数据的准确。另外应用会记录log，发送同志消息来保证数据准确写入不丢失。

MYSQL主备库延迟解决方案基本思路

首先，造成主备库延迟，说明其中肯定会参杂有网络延迟、主库负载、备库负载的因素。
这个时候我们可以在从库里面选出一台专用的服务器，只来作为备份用，不进行其它操作，也就能最大限度的达到减少延迟的要求。当然这只是外部的粗浅解决方案，我们需要减少从库同步延时，就需要在架构上做优化，让主库的DDL快速的执行，另外从库对数据安全要求不高，sync_binlog与innodb_flush_log_at_trx_commit之类的完全可以去掉，同时也可以配备比主库更好或者相同配置的硬件设备。
MySQL5.6+已经支持多线程的主从复制，不像oracle那样以schema来做多线程，不同的库使用不同的复制线程，MySQL则是采用淘宝丁奇所类似的方法，以表来做多线程。