使用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示例放在同一台机器上，并定时对齐检测可用性，这样当机器挂掉的时候，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则是采用淘宝丁奇所相似的方法，以表来作多线程。

结论

关于MySQL，还有许多值得去深刻研究的问题。另外推荐一本书《深刻理解MySQL核心技术》，但愿你们可以一块儿成长、进步。