怎么更好的去使用Mysql

高可用性就是保证尽量少的宕机时间。
尽量少的数据损坏。
一般会受到如下因素影响：

~环境因素， 比如磁盘耗尽
~性能问题， 可能是运行了超级慢的sql
~糟糕的schema和索引设计
~复制导致数据不一致。
提升平均失效时间 (MTBF)
就是连续运行的时间。 我们可以通过如下的注意点尽量避免：

~测试回复工具和流程
~最小权限
~用好的命名和组织约定避免混乱，比如测试开发库分离
~升级服务器前使用Percona Tookit检查系统
~确认服务器配置项
~通过skip_name_resolve禁止DNS
~除非证明有效，否则不使用查询缓存。
~避免使用复杂的特性,如触发器等
~监控重要组件
~尽量记录服务器状态和性能做成曲线查看走向
~定期检查复制完整性
~备库设置为只读，不要让复制自动启动
~对查询语句做检查
~归档并清理不需要的数据
~为文件系统保留空余空间，在linux中可以使用-m选项为系统本身保留空间。或者创建很大的空文件，在快满是删除
~养成习惯，评估和管理系统的改变，状态以及性能信息。
降低平均恢复时间（MTTR）
通过建立冗余来避免系统完全失效，比如避免单点。
能够提供冗余和故障转移能力的系统架构
熟悉业务的员工和详细的文档和流程
宕机事后反思

避免单点失效
单个磁盘，单台服务器，单台交换机路由器，单电力网。 任何不冗余的部分都可能是一个失败的单点。

用池加负载均衡，可以动态的切换及避免冗余
共享存储或者复制，做到数据的冗余。

共享存储就是在华为的时候的存储产品，比如NAS。

同步复制
mysql 普通的复制，主服务器挂掉之后会丢数据，使用同步复制保证至少在一条备机持久化之后才能持久化本地，所以减少了丢失。

通常可用的工具：
Mysql Cluster . 可以在任何节点上写入。这些节点拥有等同的读写能力，美羊羊都是冗余数据。
Percona XtraDB Cluster，可以基于已有的存储引擎增加同步复制和集群的特性。其有很多有死的特性：

~跨界点复制比没有集群快，因为网络写RAM比本地写磁盘块，可以通过降低单节点持久性获得更好的性能。
~行级并发。可以更好的利用多核CPU
故障转移和恢复
冗余只是一个基础，真正影响可用性的是如何利用这些冗余做转移和恢复。

转移是A出问题了切到B上，等A好了再切回去，这要比仅仅恢复A要好。
通常有如下的手段来做：
~提升备库。
~使用虚拟IP，如果服务器出问题，则让虚拟ip指向备库。但是这样可能会因为网络缓存，ip接管等引起错误
~中间件 可以使用代理，端口转发，LVS等等方法来作为中间件，屏蔽应用和数据库。比如最简单的http代理

总结：
两方面考虑增加可用性。 增加两次故障之间的运行时间MTBF，减少从故障恢复的时间。

MTBF要减少出错，尽量减少宕机

MTTR要尽早发现，可以使用监控。

MTTR还可以使用冗余，并提供故障注意能力。但是遮阳系统更复杂，变成了分布式的。 意味着协调、同步、CAP(一致可~用容错只能满足两个)、拜占庭将军问题等

如果需要很强的可用性保证不宕机，那么需要Mysql Cluster这样的集群产品。 如果可以容忍故障转移慢一点，标准mYSQL复制也可以

如果不是很在意故障转移时间，可以使用NAS等存储层的技术。