备份和恢复数据库中的数据&实现数据库的高可用，避免宕机停服
如何更安全地做数据备份和恢复？
1，全量备份
在 MySQL 中，使用mysqldump命令来执行全量备份。比如我们要全量备份数据库 test：
$mysqldump -uroot -p test > test.sql
备份出来的文件就是一个 SQL 文件，就是创建数据库、表，写入数据等等这些 SQL，如果要恢复数据，直接执行这个备份的 SQL 文件就可以了：
$mysql -uroot test < test.sql
全量备份的代价非常高，首先，占用的磁盘空间非常大；其次，每次备份操作都要拷贝大量数据，占用服务器大量的 CPU、磁盘 IO 资源，并且为了保证数据一致性，还有可能会锁表，这些都会导致备份期间，数据库本身的性能严重下降。
2，增量备份
MySQL 自带了 Binlog，就是一种实时的增量备份。
Binlog 里面记录的就是 MySQL 数据的变更的操作日志，开启 Binlog 之后，我们对 MySQL 中的每次更新数据操作，都会被记录到 Binlog 中。Binlog 是可以回放的，回放 Binlog，就相当于把之前对数据库所有数据更新操作按照顺序重新执行了一遍，回放完成之后数据自然就恢复了。
例：
首先使用“show variables like ‘%log_bin%’”命令确认一下是否开启了 Binlog 功能：
mysql> show variables like '%log_bin%';
然后用“show master status”命令可查看当前 Binlog 的状态
mysql> show master status;
用 Binlog 把数据恢复到删库跑路之前的那个时刻：
$mysqlbinlog --start-datetime "2020-02-20 00:00:00" --stop-datetime "2020-02-20 15:09:00" /usr/local/var/mysql/binlog.000001 | mysql -uroot
通过定期的全量备份，配合 Binlog，我们就可以把数据恢复到任意一个时间点。
配置 MySQL HA 实现高可用
准备一台备用的数据库，把它的数据恢复成主库一样，然后实时地在主备数据库之间来同步 Binlog，主库做了一次数据变更，生成一条 Binlog，我们就把这一条 Binlog 复制到备用库并立即回放，这样就可以让备用库里面的数据和主库中的数据一直保持是一样的。
一旦主库宕机，就可以立即切换到备用库上继续提供服务。这就是 MySQL 的高可用方案，也叫 MySQL HA。MySQL 自身就提供了主从复制的功能，通过配置就可以让一主一备两台 MySQL 的数据库保持数据同步。
当我们对主库执行一次更新操作的时候，主从两个数据库更新数据实际的时序是这样的：
1.在主库的磁盘上写入 Binlog；
2.主库更新存储引擎中的数据；
3.给客户端返回成功响应；
4.主库把 Binlog 复制到从库；
5.从库回放 Binlog，更新存储引擎中的数据。
也就是说，存在“主从延迟”。正常情况下，主从延迟基本都是毫秒级别，你可以认为主从就是实时保持同步的。麻烦的是不正常的情况，一旦主库或者从库繁忙的时候，有可能会出现明显的主从延迟。
1，如果主库宕机并且主从存在延迟的情况下，切换到从库继续读写，可以保证业务的可用性，但是主从延迟这部分数据就丢失了。这时需要在“可用性”和“不丢数据”间做一个选择，要么直接切换，要么同步完成再切换。
2，那能不能既保证数据不丢，还能做到高可用呢？那就要牺牲一些性能。MySQL 也支持同步复制，开启同步复制时，MySQL 主库会等待数据成功复制到从库之后，再给客户端返回响应。
但新的问题又来了，这种情况下从库宕机了，因为现在主库要等待从库写入成功再返回，从库宕机，主库就会一直等待从库，主库也卡死了。
3，这个问题也有解决办法，那就是再加一个从库，把主库配置成：成功复制到任意一个从库就返回，只要有一个从库还活着，就不会影响主库写入数据，这样就解决了从库宕机阻塞主库的问题。如果主库发生宕机，在两个从库中，至少有一个从库中的数据是和主库完全一样的，可以把这个库作为新的主库，继续提供服务。为此你需要付出的代价是，你要至少用三台数据库服务器，并且这三台服务器提供的服务性能，还不如一台服务器高。
数据库的安全和可用性的实现原理其实是一样的，高可用依赖的是数据复制，数据复制的本质就是从一个库备份数据，然后恢复到另外一个库中去。
网友评论