获取更多精彩
JavaEdge
0MySQLHA/Scalability
如何关上“删库跑路”的后门，维护我们的数据安全呢？
数据是当今Web，移动，社交，企业和云应用程序的流行货币。确保数据始终可用是任何组织的头等大事。几分钟的停机时间可能会导致收入和声誉严重损失。
没有提供高可用性（HA）的“一刀切”的方法。独特的应用程序属性，业务需求，运营能力和传统基础架构都可以影响HA技术的选择。技术只是提供HA的要素之一：人员和流程与技术本身一样关键。
MySQL已部署到许多要求可用性和可伸缩性的应用程序中。
可用性是指应对主机故障（包括MySQL，操作系统或硬件和维护活动的故障）的能力，并在必要时从主机故障中恢复，否则可能会导致停机可伸缩性是指能够在多个MySQL服务器上分布数据库和应用程序查询负载的能力。由于每个应用程序都有不同的操作和可用性要求，因此MySQL提供了一系列经过认证和受支持的解决方案，可提供适当级别的高可用性（HA）和可伸缩性，以满足服务级别的要求。此类解决方案从复制一直到虚拟化和地理冗余的多数据中心解决方案，可实现99.％的正常运行时间。
为应用程序选择正确的高可用性解决方案主要取决于：
所需的可用性级别部署的应用程序类型在自己的环境中接受的最佳实践MySQL支持的主要解决方案包括：
MySQL复制MySQL集群用于实现高可用性数据库服务的每种体系结构都通过其提供的正常运行时间级别来区分。这些体系结构可以分为三个主要类别：
数据复制集群和虚拟化系统无共享，地理位置复制的群集。如下图所示，这些体系结构中的每种体系结构都提供了越来越高的正常运行时间，必须将其与可能产生的更高水平的成本和复杂性进行权衡。仅部署高可用性体系结构并不能保证实际交付HA。实际上，与简单的数据复制解决方案相比，实施不当和维护不善的无共享群集可能很容易提供较低级别的可用性。
高可用依赖的是数据复制，数据复制的本质就是从一个库备份数据，然后恢复到另外一个库中去。
我们看向最简单的数据复制方案。
1数据备份
定期备份数据，这样即使数据丢失，也可以通过备份记录来恢复。
问题来了，如何备份？
1.1全量备份
最简单的备份方式。备份的时候，把所有的数据复制，存放到文件中，恢复的时候再把文件中的数据复制回去，这样可以保证恢复之后数据库中的数据和备份时是完全一样的。在MySQL中，可以使用mysqldump执行全量备份。
比如我们要全量备份数据库shop：
mysqldump-uroot-pshopshop.sql备份出来的文件就是一个SQL文件，就是创建数据库、表，写入数据等等这些SQL，如果要恢复数据，直接执行这个备份的SQL文件就可以了：
mysql-uroottesttest.sql不过，全量备份的代价非常高
备份文件包含数据库中的所有数据，占用的磁盘空间非常大每次备份操作都要拷贝大量数据，备份过程中会占用数据库服务器大量的CPU、磁盘IO资源为了保证数据一致性，还有可能会锁表，这些都会导致备份期间，数据库本身的性能严重下降。不能经常全量备份。
一般来说，每天执行一次全量备份已是非常频繁。如果数据库中的数据丢了，那只能恢复到最近一次全量备份的那个时间点，这个时间点之后的数据还是丢了。也就是说，全量备份不能做到完全无损地恢复。
有没更好方法，少丢甚至不丢数据?
1.2增量备份
每次只备份相对于上一次备份变化的那部分数据，所以每次增量备份速度更快。
1.2.1Binlog
MySQL自带的Binlog，就是实时的增量备份。
Binlog里面记录的就是MySQL数据的变更的操作日志，开启Binlog之后，我们对MySQL中的每次更新数据操作，都会被记录到Binlog。
1.2.1.1基本原理
Binlog可以回放，回放Binlog，就相当于把之前对数据库所有数据更新操作按照顺序重新执行了一遍，回放完成之后数据自然就恢复了。很多数据库都有类似于MySQLBinlog的日志，原理和Binlog是一样的，备份和恢复方法也类似。
1.2.1.2开启
showvariableslike‘%log_bin%’;
可以看到当前这个数据库已经开启了Binloglog_bin_basenameBinlog文件在服务器磁盘上的具体位置
1.2.1.3查看状态
showmasterstatus
显示正在写入的Binlog文件，及当前的位置。假设我们每天凌晨用mysqldump做一个全量备份，然后开启了Binlog，有了这些，就可以把数据恢复到全量备份之后的任一时刻。用Binlog把数据恢复到删库跑路之前的那个时刻：
mysqlbinlog--start-datetime-05-:00:00--stop-datetime-05-:00:00/usr/local/var/mysql/binlog.
mysql-uroot这时候，数据已经恢复到当天的18点了。
定期的全量备份+Binlog，就可以把数据恢复到任一历史时间点。
2最佳实践
无论全量备份还是Binlog，都不要和数据库存放在同一服务器在回放Binlog时，指定的起始时间可以比全量备份的时间稍微提前，确保全量备份之后的所有操作都在恢复的Binlog范围内，保证恢复的数据的完整性。因为回放Binlog操作是幂等的（需要设置Binlog为ROW格式)，所以重复回放的那部分Binlog并不会影响数据的准确性。
3打造高可用的MySQL
恢复数据时间很长，这期间系统一直不可用，怎么搞？不要等着数据库宕机，才开始做恢复，平时就要恢复。
3.1异步复制
一主一从，性能佳。
实时地在主备数据库之间来同步Binlog，主库做了一次数据变更，生成一条Binlog，我们就把这一条Binlog复制到备用库并立即回放，这样就可以让备用库里面的数据和主库中的数据一直保持是一样的。一旦主库宕机，就可以立即切换到备用库上继续提供服务。
MySQL本身提供了主从复制