公司规模已经形成，用户数据已成为公司的核心命脉，一次老王一不小心把数据库文件删除，通过mysqldump备份策略恢复用了两个小时，在这两小时中，公司业务中断，损失100万，老王做出深刻反省，公司也因此对于数据库的性能和可靠性提出更高要求。要求对数据库进行改造，使其承载力进行提升，故障修复时间减少，有没有能实现的方案呢？
数据库常遇到的问题 一、性能问题
1、向上拓展 scale up ：针对单台服务器，提高服务器的硬件性能，比如：内存，cpu等，个体本身 容易达到极限
2、向外拓展 scale out ：多台服务器形成集群，共同完成一件事情
二、可用性问题1、数据库服务中断
2、误操作数据损坏
3、硬件故障
4、数据库升级测试遭遇bug
5、黑客攻击
数据库高可用技术说明
高可用架构对于互联网服务基本是标配，无论是应用服务还是数据库服务都需要做到高可用。虽然互联网服务号称7*24小时不间断服务，但多多少少有一些时候服务不可用，比如某些时候网页打不开，百度不能搜索或者无法发微博，发微信等。一般而言，衡量高可用做到什么程度可以通过一年内服务不可用时间作为参考，要做到3个9的可用性，一年内只能累计有8个小时不可服务，而如果要做到5个9的可用性，则一年内只能累计5分钟服务中断。所以虽说每个公司都说自己的服务是7*24不间断的，但实际上能做到5个9的屈指可数，甚至根本做不到，国内互联网巨头BAT(百度，阿里巴巴，腾讯)都有因为故障导致的停服问题。对于一个系统而言，可能包含很多模块，比如前端应用，缓存，数据库，搜索，消息队列等，每个模块都需要做到高可用，才能保证整个系统的高可用。对于数据库服务而言，高可用可能更复杂，对用户的服务可用，不仅仅是能访问，还需要有正确性保证，因此，对于实现数据库高可用，对互联网公司来说极其重要！
企业级数据库高可用架构图Mysql主从架构技术说明
Mysql内建的复制功能是构建大型，高性能应用程序的基础。将Mysql的数据分布到多个系统上去，这种分布的机制，是通过将Mysql的某一台主机（Master）的数据复制到其它主机（slaves）上，并重新执行一遍来实现的。复制过程中一个服务器充当主服务器，而一个或多个其它服务器充当从服务器。主服务器将更新写入二进制日志文件，这些日志可以记录发送到从服务器的更新。当一个从服务器连接主服务器时，它通知主服务器从服务器在日志中读取的最后一次成功更新的位置。从服务器接收从那时起发生的任何更新，然后封锁并等待主服务器通知新的更新。
主从复制架构图
数据库复制特性 Mysql复制解决的问题
MySQL复制技术有以下一些特点：
(1) 数据分布 (Data distribution )
(2) 负载平衡(load balancing)
(3) 备份(Backups)
(4) 高可用性和容错性 High availabilityand failover
Mysql复制如何工作 Mysql的复制功能主要有3个步骤：
(1) 主服务器（master）将改变记录到二进制日志(binarylog)中（这些记录叫做二进制日志事件，binary log events）
(2) 从服务器（slave）将主服务器master的binary logevents拷贝到它的中继日志(relay log)
(3) slave重做中继日志中的事件，将改变反映它自己的数据。