假设系统一直能够提供服服务器租用 . mysql高可用
1， 2.实现数据备份
3， 异地容灾
1.1 主从复制流程
不同的复制协议
MySQL本身没有提供replication failover的解决方案，通过MMM方案能实现服务器的故障转移，从而实现mysql的高可用。
此方案特点：
1、安全、稳定性较高，可扩展性好
2、 对服务器数量要求至少三台及以上
3、 对双主(主从复制性要求较高)
4、 同样可实现读写分离
1.3.3 MySQL+MHA架构
MHA目前在Mysql高可用方案中应该也是比较成熟和常见的方案，它由日本人开发出来，在mysql故障切换过程中，MHA能做到快速自动切换操作，而且还能最大限度保持数据的一致性
此架构特点：
1、安装布署简单，不影响现有架构
2、自动监控和故障转移
3、保障数据一致性
4、故障切换方式可使用手动或自动多向选择
5、适应范围大(适用任何存储引擎)
2.MySQL高可用带给我们对高可用架构设计的思考
为了保证数据的一致性，mysql提出了复制的概念。
为了满足acid，mysql提供了两种日志redo和undo日志，
undo log不是redo log的逆向过程，其实它们都算是用来恢复的日志：
undo用来回滚行记录到某个版本。undo log一般是逻辑日志，根据每行记录进行记录。
为了高可用的保证，有了多主或者主从切换。
数据库的高可用架构一般在系统的底层，这方面的技术要求比较高，整个高可用系统大致如下：
3.总结
我们都知道，单点是系统高可用的大敌，单点往往是系统高可用最大的风险和敌人，应该尽量在系统设计的过程中避免单点。
方法论上，高可用保证的原则是“集群化”，或者叫“冗余”：只有一个单点，挂了服务会受影响;如果有冗余备份，挂了还有其他backup能够顶上。冗余的最大难道是一致性即复制技术，mysql提供了一个思路。
有了冗余之后，还不够，每次出现故障需要人工介入恢复势必会增加系统的不可服务实践。所以，又往往是通过“自动故障转移”来实现系统的高可用。灾备的恢复一般通过日志来做，日志的设计也是难点，mysql提供了一个思路。
