MySQL学习足迹

一、为什么有了binlog还要redolog?

        binlog会记录所有与MySQL数据库有关的日志记录，包括InnoDB, MyISAM，Heap等其他存储引起的日志。而redo log只记录innodb引擎本身的日志。
binlog记录的是关于一个事务的具体操作内容，即该日志是逻辑日志。而redolog记录的是关于每个页的更改的物理情况。
写入时间不同。binlog仅在事务提交前提交，只写磁盘一次，不论这个事务有多大。而redolog在事务进行过程中会不停的写入。
它们分工是不同的。binlog用来做数据归档，但不具备崩溃恢复的能力，也就是说如果系统突然崩溃，重启后可能会有部分数据丢失。
innodb将所有对页面的修改操作写入一个专门的文件，并在数据库启动时从此文件进行恢复操作。

二、为什么redolog具有crash-safe的能力，是binlog无法替代的？

1.一个固定大小，“循环写”的日志文件，记录的是物理日志——“在某个数据页上做了某个修改”。
binlog 是什么？

一个无限大小，“追加写”的日志文件，记录的是逻辑日志——“给 ID=2 这一行的 c 字段加1”。

redo log 和 binlog 有一个很大的区别就是，一个是循环写，一个是追加写。也就是说 redo log 只会记录未刷盘的日志，已经刷入磁盘的数据都会从 redo log 这个有限大小的日志文件里删除。binlog 是追加日志，保存的是全量的日志。

当数据库 crash 后，想要恢复未刷盘但已经写入 redo log 和 binlog 的数据到内存时，binlog 是无法恢复的。虽然 binlog 拥有全量的日志，但没有一个标志让 innoDB 判断哪些数据已经刷盘，哪些数据还没有。

举个栗子，binlog 记录了两条日志：

给 ID=2 这一行的 c 字段加1
给 ID=2 这一行的 c 字段加1
在记录1刷盘后，记录2未刷盘时，数据库 crash。重启后，只通过 binlog 数据库无法判断这两条记录哪条已经写入磁盘，哪条没有写入磁盘，不管是两条都恢复至内存，还是都不恢复，对 ID=2 这行数据来说，都不对。

但 redo log 不一样，只要刷入磁盘的数据，都会从 redo log 中抹掉，数据库重启后，直接把 redo log 中的数据都恢复至内存就可以了。这就是为什么 redo log 具有 crash-safe 的能力，而 binlog 不具备。

2.当数据库 crash 后，如何恢复未刷盘的数据到内存中？

根据 redo log 和 binlog 的两阶段提交，未持久化的数据分为几种情况：

change buffer 写入，redo log 虽然做了 fsync 但未 commit，binlog 未 fsync 到磁盘，这部分数据丢失。
change buffer 写入，redo log fsync 未 commit，binlog 已经 fsync 到磁盘，先从 binlog 恢复 redo log，再从 redo log 恢复 change buffer。
change buffer 写入，redo log 和 binlog 都已经 fsync，直接从 redo log 里恢复。

三、用trabackkup实现mysql增量备份和全量备份

利用Xtrabackup进行mysql增量备份
现在xtrabackup版本升级到了8.0，但是只对mysql8.0才有支持, 我们这还是使用2.4, 但是2.4相比之前的2.1有了比较大的变化：innobackupex 功能全部集成到 xtrabackup 里面，只有一个 binary，另外为了使用上的兼容考虑，innobackupex 作为 xtrabackup 的一个软链，即 xtrabackup 现在支持非Innodb表备份，并且 Innobackupex 在下一版本中移除(8.0已经移除了)，建议通过xtrabackup替换innobackupex。还有其他的一些新特性，更多的说明可以看xtrabackup新版详细说明。

下载地址: https://www.percona.com/downloads/Percona-XtraBackup-LATEST/
文档地址: https://www.percona.com/doc/percona-xtrabackup/2.4/index.html

安装
如果安装需要依赖就把依赖安装一下

wget https://repo.percona.com/apt/percona-release_latest.$(lsb_release -sc)_all.deb
sudo dpkg -i percona-release_latest.$(lsb_release -sc)_all.deb
sudo apt-get update
sudo apt-get install percona-xtrabackup-24
设置数据库用于备份账户
mysql> CREATE USER 'bkpuser'@'localhost' IDENTIFIED BY '123456';
mysql> GRANT RELOAD, LOCK TABLES, PROCESS, REPLICATION CLIENT ON *.* TO 'bkpuser'@'localhost';
mysql> FLUSH PRIVILEGES;
全量备份
xtrabackup --user=bkpuser --password=123456 --backup --target-dir=/data/backups/mysql
 
# 会看到输出
200603 09:55:37 Executing UNLOCK TABLES
200603 09:55:37 All tables unlocked
200603 09:55:37 [00] Copying ib_buffer_pool to /data/backups/mysql/ib_buffer_pool
200603 09:55:37 [00]        ...done
200603 09:55:37 Backup created in directory '/data/backups/mysql/'
200603 09:55:37 [00] Writing /data/backups/mysql/backup-my.cnf
200603 09:55:37 [00]        ...done
200603 09:55:37 [00] Writing /data/backups/mysql/xtrabackup_info
200603 09:55:37 [00]        ...done
xtrabackup: Transaction log of lsn (837940114) to (837940123) was copied.
200603 09:55:37 completed OK!
准备备份
xtrabackup --prepare --target-dir=/data/backups/mysql
复制备份
我这里为了演示全量备份就直接将我博客 mysql 存储的数据目录给移动一下

mv /var/lib/mysql /var/lib/mysql_bak
mkdir /var/lib/mysql
 
xtrabackup --copy-back --target-dir=/data/backups/mysql  # 这样会保留原始备份 他会将当时读到my.cnf的datadir设置为恢复路径
 
200603 10:47:42 [01]        ...done
200603 10:47:42 [01] Copying ./performance_schema/mutex_instances.frm to /var/lib/mysql/performance_schema/mutex_instances.frm
200603 10:47:42 [01]        ...done
200603 10:47:42 [01] Copying ./performance_schema/events_transactions_history_long.frm to /var/lib/mysql/performance_schema/events_transactions_history_long.frm
200603 10:47:42 [01]        ...done
200603 10:47:42 [01] Copying ./xtrabackup_info to /var/lib/mysql/xtrabackup_info
200603 10:47:42 [01]        ...done
200603 10:47:42 [01] Copying ./ibtmp1 to /var/lib/mysql/ibtmp1
200603 10:47:42 [01]        ...done
200603 10:47:42 completed OK!
备份成功 重新启动 博客还能正常访问 哈哈哈哈
# 将恢复目录的属主更改一下
chown -R mysql:mysql mysql
/etc/init.d/mysql start
如果恢复玩不想要备份数据可以使用 xtrabackup --move-back 命令

增量备份
增量是基于已有数据进行备份的,也就行需要先创建一次全量备份,然后记录当时的记录点

创建备份
xtrabackup --user=bkpuser --password=123456 --backup --target-dir=/data/backups/base
 
# 基于全量备份进行增量
xtrabackup --user=bkpuser --password=123456 --backup --target-dir=/data/backups/inc1 --incremental-basedir=/data/backups/base
查看备份类型 确认是增量备份了
root@longing:/data/backups/inc1# cat xtrabackup_checkpoints 
backup_type = incremental
from_lsn = 837943393
to_lsn = 837943393
last_lsn = 837943402
compact = 0
recover_binlog_info = 0
flushed_lsn = 837943402
from_lsn 是备份的起始 LSN，对于增量备份，它必须to_lsn与先前 base 备份的相同。

在这种情况下，您可以看到to_lsn （最后一个检查点LSN）和last_lsn（最后一个复制的LSN）之间存在差异，这意味着在备份过程中服务器上有一些流量。

我们可以测试一下 对第一个增加继续创建增量 创建增量之前先创建几条数据
xtrabackup --user=bkpuser --password=123456 --backup --target-dir=/data/backups/inc2 --incremental-basedir=/data/backups/inc1
准备恢复
已经有3个备份了,我们要先对基础数据进行准备,然后对两个增量进行准备

xtrabackup --user=bkpuser --password=123456 --prepare --apply-log-only --target-dir=/data/backups/base
 
xtrabackup --user=bkpuser --password=123456 --prepare --apply-log-only --target-dir=/data/backups/base --incremental-dir=/data/backups/inc1
 
xtrabackup --user=bkpuser --password=123456 --prepare --target-dir=/data/backups/base --incremental-dir=/data/backups/inc2
xtrabackup --apply-log-only 合并除最后一个以外的所有增量时应使用, 一旦准备好，增量备份就与完整备份相同，可以用相同的方式还原它们。

恢复
xtrabackup --copy-back --target-dir=/data/backups/base
中间插入的数据就能看见了,真棒!

提问总结
增量备份步骤
创建基础备份
一定条件进行增量备份创建
对所有备份进行准备 所有增量基于基础备份 相当于合并操作
最后和全量备份一样 直接恢复即可
原理
在InnoDB内部会维护一个redo日志文件，我们也可以叫做事务日志文件.事务日志会存储每一个InnoDB表数据的记录修改。当InnoDB启动时，InnoDB会检查数据文件和事务日志，并执行两个步骤：它应用（前滚）已经提交的
事务日志到数据文件，并将修改过但没有提交的数据进行回滚操作。

Xtrabackup 在启动时会记住log sequence number（LSN）, 并且复制所有的数据文件。复制过程需要一些时间，所以这期间如果数据文件有改动，那么将会使数据库处于一个不同的时间点。这时，xtrabackup 会运行一个后台进程，用于监视事务日志，并从事务日志复制最新的修改。Xtrabackup 必须持续的做这个操作，是因为事务日志是会轮转重复的写入，并且事务日志可以被重用。所以 xtrabackup 自启动开始，就不停的将事务日志中每个数据文件的修改都记录下来。上面就是 xtrabackup 的备份过程。

为什么最后一次增量备份不用 "--apply-log-only"
最后一次"准备"操作可以不用跳过回滚操作，这样用来恢复的数据文件本地就处理好了，当服务启动后就不会再进入到回滚阶段，如果最后一次使用了这个参数，服务器启动后将进入回滚阶段。所以这个--apply-log-only 只是用来合并增量用的避免下一个增量不可用。 可以参见 参见 man xtrabackup

为什么备份完后要准备备份 "prepare"
一般情况下,在备份完成后，数据尚且不能用于恢复操作，因为备份的数据中可能会包含尚未提交的事务或已经提交但尚未同步至数据文件中的事务。因此，此时数据文件仍处理不一致状态。他作用是通过回滚未提交的事务及同步已经提交的事务至数据文件使数据文件处于一致性状态。

为什么选择这个做备份?
mysqldump 备份缺点
效率较低,备份和还原速度慢,份过程中,数据插入和更新操作会被挂起

MySQL 备份工具
跨平台性差,备份时间长,冗余备份,浪费存储空间

XtraBackup
备份过程中不锁库表,适合生产环境,由专业组织Percona提供( 改进MySQL分支 )

XtraBackup能对表 库进行备份吗?
当然了,只不过博主太懒了,写起来太麻烦了,不过原理都是差不多,操作也差不多,大家自己搞搞!

xtrabackup --user=bkpuser --password=123456 --backup --databases="u_test" --no-timestamp --target-dir=/data/backups/u
xtrabackup --prepare --target-dir=/data/backups/u
还原

先prepare，利用--apply-log的作用是通过回滚未提交的事务及同步已经提交的事务至数据文件使数据文件处于一致性状态
copy，因为是部分备份，不能直接用--copy-back，只能手动来复制需要的库，也要复制ibdata(数据字典）
cp /data/backups/u/ibdata1 /var/lib/mysql/
cp -r u/u_test /var/lib/mysql/
————————————————
版权声明：本文为CSDN博主「憧憬blog」的原创文章，遵循CC 4.0 BY-SA版权协议，转载请附上原文出处链接及本声明。
原文链接：https://blog.csdn.net/qq_24694139/article/details/107539850

四、iptables防止nmap扫描以及binlog

nmap的应用：

主机探测
端口扫描
版本检测
系统检测
支持探测脚本的编写
我们可以通过设置让Linux对nmap扫描无回应，利用iptables工具来过滤网络信息，从而让系统无法回应扫描请求的信息

配置命令如下：

 #iptables -F

  #iptables -A INPUT -p tcp --tcp-flags ALL FIN,URG,PSH -j Drop

  #iptables -A INPUT -p tcp --tcp-flags SYN,RST SYN,RST -j Drop

  #iptables -A INPUT -p tcp --tcp-flags SYN,FIN SYN,FIN -j Drop

  #iptables -A INPUT -p tcp --tcp-flags SYN,SYN --dport 80 -j Drop
 

binlog增量备份的实现步骤：

1.开启二进制日志
log_bin(log-bin也可以)                            #启用日志
server_id=50                                    #id只能是1-255
#max_binlog_size=数值                            #默认是1G,超了1G就创建新的binlog日志

2.重启MySQL服务
systemctl restart mysqld

3.检查是否启用日志
        1)进入数据库,show master status;                    #查看本机的binlog日志文件
position ---> 偏移量 ---> 记录命令的编号
        2)查看/var/lib/mysql 可以看到binlog日志文件和日志的索引文件

配置命令：
        1.手动生成新的日志文件                            #每个binlog日志的偏移量从154开始
    -flush logs 或　mysql -uroot -p123456 -e ‘flush logs’
    -systemctl restart mysqld
    -mysqldump

        2.清理日志
            1.删除指定日志文件前的所有日志 purge master logs to “binlog文件名”
            2.删除所有    reset master;

        3.自定义存储名称
            1.在配置文件中配置,
            bin_log=/mylog/rzc
            2.重启服务即可
————————————————
版权声明：本文为CSDN博主「好不快活呀~」的原创文章，遵循CC 4.0 BY-SA版权协议，转载请附上原文出处链接及本声明。
原文链接：https://blog.csdn.net/cjh12340/article/details/125832809