服务在运行过程中存在很多意外情况，如：如服务器宕机、磁盘损坏、RAID卡损坏等。如何保证数据库在服务发生意外的情况下数据不丢失呢？服务还能继续提供服务呢？

我们一般通过备份的方式来解决数据丢失问题，通过复制来解决MySQL的高可用问题。

备份

备份的方法不同可以将备份分为：

• Hot Backup（热备，在线备份）：在数据运行过程中进行备份，对数据库操作没有影响。
• Cold Backup（冷备，离线备份）：在数据停止情况下，直接拷贝数据库物理文件。
• Warm Backup（温备）：在数据运行过程中进行，但是会对当前数据库的操作有所影响，如加一个全局读锁以保证备份数据的一致性。

按照备份后文件的内容，备份又可以分为：

• 逻辑备份：是指备份出的文件内容是可读的，一般是文本文件。内容一般是由一条条SQL语句，或者是表内实际数据组成。一般适用于数据库的升级、迁移等工作。但其缺点是恢复所需要的时间往往较长。
• 裸文件备份：是指复制数据库的物理文件，既可以是在数据库运行中的复制（如ibbackup、xtrabackup这类工具），也可以是在数据库停止运行时直接的数据文件复制。这类备份的恢复时间往往较逻辑备份短很多。

若按照备份数据库的内容来分，备份又可以分为：

• 完全备份：完全备份是指对数据库进行一个完整的备份。
• 增量备份：增量备份是指在上次完全备份的基础上，对于更改的数据进行备份。
• 日志备份：日志备份主要是指对MySQL数据库二进制日志的备份，通过对一个完全备份进行二进制日志的重做（replay）来完成数据库的point-in-time的恢复工作。

复制

复制（replication）是MySQL数据库提供的一种高可用高性能的解决方案，一般用来建立大型的应用，原理如下：

1. 主服务器（master）把数据更改记录到二进制日志（binlog）中，然后通过binary log dump线程将二进制文件推送到从服务器。
2. 从服务器（slave）通过I/O线程，把主服务器的二进制日志复制到自己的中继日志（relay log）中，中继日志通常会位于os缓存中，所以中继日志的开销很小。
3. 从服务器通过SQL线程重做中继日志中的日志，把更改应用到自己的数据库上，以达到数据的最终一致性。

从服务器有2个线程，一个是I/O线程，负责读取主服务器的二进制日志，并将其保存为中继日志；另一个是SQL线程，复制执行中继日志。这里需要特别注意的是，复制是一个异步过程，从服务器数据存在延迟。

MySQL二进制日志文件Binlog有三种格式，Statement、Row和Mixed，所以MySQL的复制也对应有三种方式。

异步复制

主库执行完Commit后，在主库写入Binlog日志后即可成功返回客户端，无需等Binlog日志传送给从库。

半同步复制

在 MySQL5.5之前，MySQL的复制是异步操作，主库和从库的数据之间存在一定的延迟，这样存在一个隐患：当在主库上写人一个事务并提交成功，而从库尚未得到主库推送的Binlog日志时，主库宕机了，例如主库可能因磁盘损坏、内存故障等造成主库上该事务 Binlog丢失，此时从库就可能损失这个事务，从而造成主从不一致。

而半同步复制，是等待其中一个从库也接收到Binlog事务并成功写入Relay Log之后，才返回Commit操作成功给客户端；如此半同步就保证了事务成功提交后至少有两份日志记录，一份在主库Binlog上，另一份在从库的Relay Log上，从而进一步保证数据完整性；半同步复制很大程度取决于主从网络RTT（往返时延），以插件 semisync_master/semisync_slave 形式存在。

集群

使用集群可以提高MySQL服务器的可用性和性能，MySQL服务支持多种集群方案。

MySQL Cluster

由Mysql本身提供，优势：可用性非常高，性能非常好。每份数据至少可在不同主机存一份拷贝，且冗余数据拷贝实时同步。但它的维护非常复杂，存在部分Bug，目前还不适合比较核心的线上系统，所以不推荐。

DRBD磁盘网络镜像

Distributed Replicated Block Device，其实现方式是通过网络来镜像整个设备(磁盘)。它允许用户在远程机器上建立一个本地块设备的实时镜像，与心跳链接结合使用，也可看做一种网络RAID。

优势：软件功能强大，数据可在底层快设备级别跨物理主机镜像，且可根据性能和可靠性要求配置不同级别的同步。IO操作保持顺序，可满足数据库对数据一致性的苛刻要求。

但非分布式文件系统环境无法支持镜像数据同时可见，性能和可靠性两者相互矛盾，无法适用于性能和可靠性要求都比较苛刻的环境，维护成本高于MySQL Replication。另外，DRBD也是官方推荐的可用于MySQL高可用方案之一，所以这个大家可根据实际环境来考虑是否部署。

MySQL Replication

MySQL的复制上在实际应用场景中使用最多的一种方案，主要优势是成本低，实现起来比较简单，缺点是从服务器存在一定的延迟。

常用架构

一主多从，提高系统的读性能

一主一从和一主多从是最常见的主从架构，实施起来简单并且有效，主要用来实现读写分离，提升度的性能，降低主库压力，在主库出现异常宕机的情况下，可以把一个从库切换为主库继续提供服务。

多级复制

MySQL的复制是主库推送Binlog到从库，在上面一主多从的情况下，主库的I/O和网络压力都会随着从库的增加而增大。多级而使用多级复制可以很好的解决这个问题，但是随着从库的链路的增加从库的数据延迟也会随着增大。

双主复制/Dual Master

其实就是master1和master2互为主从关系，这样任何一方所做的变更，都会通过复制应用到另外一方的数据库中。client客户端的写请求都访问主库 Master1，而读请求可以选择访问主库Master1或 Master2。

双主多级复制架构

双主复制还能和主从复制联合起来使用，在 Master2库下配置从库 Slave1、 Slave2等，这样即可通过从库Slave等来分担读取压力。