MySQL备份与Binlog恢复
一、MySQL全量备份 =》数据快照
mysqldump -uroot -p testdb > test.sql
mysql -uroot -p testdb < test.sql
二、增量备份 =》Binlog，操作日志
show variables like '%log_bin%';
show master status;
问题1：mysql如何开启binlog？
vim /etc/mysql/mysql.conf.d/mysqld.cnf
log_bin = /var/log/mysql/mysql-bin.log
/etc/init.d/mysql stop /etc/init.d/mysql start
show variables like '%log_bin%';
show master status;
binlog恢复
mysqlbinlog --start-datetime "2022-05-13 15:00:00" --stop-datetime "2022-05-13 15:10:00" /var/log/mysql/mysql-bin.000001 | mysql -uroot
三、MySQL HA高可用
MySQL HA：主库Binlog，立刻复制到备机上重放；旦主库宕机，立即切换到备机上继续提供服务
主从数据库更新数据时序
- 在主库的磁盘上写入 Binlog；
- 主库更新存储引擎中的数据；
- 给客户端返回成功响应；
- 主库把 Binlog 复制到从库；
- 从库回放 Binlog，更新存储引擎中的数据
主从延迟
正常情况：主从延迟基本是毫秒级别，实时同步
异常情况： 主或从库繁忙，出现明显主从延迟
问题：主库宕机并且主从存在延迟的情况下，切换到从库继续读写，可以保证业务的可用性，但是主从延迟这部分数据就丢失了？
方案1：不丢数据，牺牲可用性 =》 停止主机服务，将Binlog全部同步到备机，再切换到备机后提供服务
方案2：保证可用性，允许丢失部分数据 =》 第一时间切换到备机
方案3：保证可用和不丢数据 ，牺牲性能 =》 MySQL同步复制机制，开启同步复制后，MySQL主库等待数据成功复制到从库后，再给客户端返回相应
https://dev.mysql.com/doc/refman/8.0/en/replication-semisync.html
新的问题：从库宕机，主库一直等待主库，主库被卡死
方案4：1主2从
主库配置成功复制任意从库就返回，不影响主库写入数据，解决从库宕机阻塞主库的问题
主库宕机，至少有1个备机数据和主库数据完全一样，将该从库切换成新的主库，继续提供服务
异步复制与同步复制
默认情况：MySQL采用异步复制技术，写入Binlog，提交事务更新存储引擎的数据，即给客户端返回成功响应。
同步复制时，主库在提交事务的时候，会等待数据复制到所有从库之后，再给客户端返回响应
半同步机制： MySQL5.7版本+，事务线程不用等待所有复制成功响应，只要部分复制相应回来即可
rpl_semi_sync_master_wait_slave_count：至少等待数据复制到几个从节点再返回（默认配置1），数量配置的越大，丢数据的风险越小，但是集群的性能和可用性就越差
rpl_semi_sync_master_wait_point：这个参数控制主库执行事务的线程，是在提交事务之前（AFTER_SYNC）等待复制，还是在提交事务之后（AFTER_COMMIT）等待复制。默认是 AFTER_SYNC，也就是先等待复制，再提交事务，这样完全不会丢数据。AFTER_COMMIT 具有更好的性能，不会长时间锁表，但还是存在宕机丢数据的风险
主库超时降级策略
主库提交事务的线程等待复制的时间超时了，这种情况下事务仍然会被正常提交，MySQL 会自动降级为异步复制模式，直到有足够多（rpl_semi_sync_master_wait_no_slave）的从库追上主库，才能恢复成半同步复制
四、复制状态机技术
https://en.wikipedia.org/wiki/State_machine_replication
快照：MySQL全量备份某一刻数据；Redis Snapshot;
操作日志：MySQL Binlog记载每次数据更新变化；Reids backlog；
复制数据时：基于某个快照，按照顺序执行快照后的所有操作日志，可以得到完全一样的状态。
事件朔源的应用程序：state + action = next state
异步复制（性能最好）：主节点上先记录操作日志，再更新状态数据，然后异步把操作日志复制到所有从节点上，并在从节点执行操作日志，得到和主节点相同的状态数据
缺点：存在主从延迟，主节点宕机，可能会丢数据
半同步复制：等待操作日志最少成功复制到N个从节点后，并更新状态。性能、高可用和数据可靠性最佳，分布式存储系统默认采取该策略
