binlog、iptables防止nmap扫描、xtrabackup全量+增量备份以及redlog和binlog两者的关系

binlog 全量备份和增量备份

首先开启开启mysql-binlog日志

[mysqld]
log-bin = mysql-bin          #定义binlog日志名称
binlog-format = MIXED        #binlog复制的格式有三种STATEMENT模式（SBR），ROW模式（RBR）MIXED模式（MBR）
expire_logs_days = 7         #binlog过期清理时间

开启binglog日志后，mysql语句会记录到binlog日志中，所以，增量备份实际就是备份binlog日志。

由于之前的mysql没有配置binlog日志大下限制，max_binlog_size参数没有配置，所以本次备份使用每天刷新一次binglog日志来进行。

#!/bin/bash
##############################################
#desc: 周一凌晨做一次全量备份，其他时间做增量备份
#author: laiwanmifan
#version: 20210808
#############################################
source /etc/profile
binlogdir="/usr/local/mysql"
USE="root"
PWD='123456'
BAK_DIR="/data/mysql-backup"
TIME=$(date |awk  '{print $1}')
[ -d ${BAK_DIR} ] || mkdir -p ${BAK_DIR}
if [ "$TIME" ==  "Mon" ];then
  #取目前生效的binlog日志名称，在周一全备份数据前，会把周日到周一期间产生的binlog日志先进行备份，然后在备份全量数据
  binfile=$(tail -1 ${binlogdir}/mysql-bin.index |xargs basename)
  #产生新的binlog日志
  mysqladmin -u${USE} -p${PWD} flush-logs
  #将binlog日志备份
  cp ${binlogdir}/${binfile}  ${BAK_DIR}/${binfile}_`date +%F_%H:%M`
  DB_LIST=`mysql -u${USE} -p${PWD} -e "show databases;"|egrep -v "*_schema|mysql|sys|Database"`
  mysqladmin -u${USE} -p${PWD} flush-logs
  for i in  ${DB_LIST}
      do
           mysqldump -u${USE} -p${PWD} -B -R --single-transaction $i|gzip >${BAK_DIR}/${i}_`date +%F_%H:%M`.sql.gz
    done 
 else
    binfile=$(tail -1 ${binlogdir}/mysql-bin.index |xargs basename)
    mysqladmin -u${USE} -p${PWD} flush-logs
    cp ${binlogdir}/${binfile}  ${BAK_DIR}/${binfile}_`date +%F_%H:%M`
fi

全量备份： mysqldump -u root -p -B -F -R -x  test| gzip  > /backup/1.sql.gz 
        #mysqldump -u 用户 -p 数据库 [表1 表2 …… 表N] > 备份文件路径
        #-B：指定数据库
		#-F：刷新日志
		#-R：备份存储过程等
		#-x：锁表
		#--master-data：在备份语句里添加CHANGE MASTER语句以及binlog文件及位置点信息
		查看备份文件：cd  /backup
					gzip -d 1.sql.gz
					ls
					vim 1.sql
		恢复全备数据： mysql -u root -p < /backup/1.sql
		备份指定库： mysqlbinlog -d test mysql-bin.00000X >00Xbin.sql
		恢复指定库： mysql -uroot -p test<00Xbin.sql

iptables防止nmap扫描

在Iptables上配置这些命令可以有效阻止nmap扫描

[root@bogon goaccess-1.5.4]# iptables -t filter -I INPUT -p tcp --tcp-flags ALL FIN,URG,PSH -j REJECT
[root@bogon goaccess-1.5.4]# iptables -t filter -I INPUT -p tcp --tcp-flags SYN,RST SYN,RST -j REJECT
[root@bogon goaccess-1.5.4]# iptables -t filter -I INPUT -p tcp --tcp-flags SYN,FIN SYN,FIN -j REJECT
[root@bogon goaccess-1.5.4]# iptables -t filter -I INPUT -p tcp --tcp-flags ALL SYN -j REJECT
[root@bogon goaccess-1.5.4]# iptables -t filter -R INPUT 1 -s 192.168.80.138 -p tcp --dport 1: --tcp-flags ALL ACK -j REJECT 

xtrabackup全量+增量备份

Xtrabackup是由percona提供的mysql数据库备份工具，据官方介绍，这也是世界上惟一一款开源的能够对innodb和xtradb数据库进行热备的工具。特点：

(1)备份过程快速、可靠；

(2)备份过程不会打断正在执行的事务；

(3)能够基于压缩等功能节约磁盘空间和流量；

(4)自动实现备份检验；

(5)还原速度快；

增量备份仅能应用于InnoDB或XtraDB表，对于MyISAM表而言，执行增量备份时其实进行的是完全备份。

做增量备份前,首先要进行一次全量备份。
 
 
全量备份:
[root@localhost ~]# innobackupex --user=root --password=root --no-timestamp --bakcup /backup/full
 
[root@localhost full]# cat xtrabackup_binlog_info
mysql-bin.000002	411
[root@localhost full]# cat xtrabackup_checkpoints
backup_type = full-backuped
from_lsn = 0
to_lsn = 2635485
last_lsn = 2635494
 
 
全量备份之后，在次期间业务数据变化了，打个比方如下
mysql> insert into mytest values(1);
mysql> commit;
 
--------------------------------------------------------------------------------------
 
第一次增量备份 基于full的基础上在做增量备份
[root@localhost ~]#  innobackupex --user=root --password=root --no-timestamp --incremental-basedir=/backup/full --incremental /backup/inc1
 
[root@localhost backup]# cd inc1/
[root@localhost inc1]# cat xtrabackup_binlog_info
mysql-bin.000002	668
[root@localhost inc1]# cat xtrabackup_checkpoints
backup_type = incremental
from_lsn = 2635485
to_lsn = 2635839
last_lsn = 2635848
 
 
 
第一次增量备份之后，在次期间业务数据变化了，打个比方如下
mysql> insert into mytest values(2);
mysql> commit;
 
------------------------------------------------------------------------------------
 
第二次增量备份，第二次增量备份的是基于第一次增量备份的，所以目录需要修改为第一次增量备份的目录，这样相当于在第一次增量备份的基础上做了第二次增量备份
[root@localhost ~]#  innobackupex --user=root --password=root --no-timestamp --incremental-basedir=/backup/inc1 --incremental /backup/inc2
 
 
[root@localhost inc2]# cat xtrabackup_binlog_info
mysql-bin.000002	925
[root@localhost inc2]# cat xtrabackup_checkpoints
backup_type = incremental
from_lsn = 2635839
to_lsn = 2636177
last_lsn = 2636186
 
 
 
下面还会产生业务数据，这些数据就写在binlog里面了(binlog不能丢，丢了就恢复不到最近的状态了)，恢复全量备份+两次增量备份+binlog恢复  这样就是完整的数据恢复
[root@localhost ~]# mkdir /binlog
[root@localhost ~]# cd /var/lib/mysql
[root@localhost mysql]# mv mysql-bin.* /binlog/
[root@localhost mysql]# ll /binlog/
total 12
-rw-r----- 1 mysql mysql 177 Jun 30 15:45 mysql-bin.000001
-rw-r----- 1 mysql mysql 925 Jun 30 15:49 mysql-bin.000002
-rw-r----- 1 mysql mysql  38 Jun 30 15:45 mysql-bin.index
 
 
删除数据库，这个时候不能跑路，应该对数据库进行恢复了，利用全备+2次增量备份+binlog
[root@localhost mysql]# rm -rf *
 
-----------------------------------------------------------------------------------------
全备
from_lsn = 0
to_lsn = 2635485
 
第一次增量备份
from_lsn = 2635485
to_lsn = 2635839
 
第二次增量备份
from_lsn = 2635839
to_lsn = 2636177
 
0----->2635485----->2635839----->2636177 你有没有发现一个规律，每次备份起始点是基于上一次备份的to_lsn的位置
 
mysql-bin.000002 411 全量--->mysql-bin.000002 668 第一次增量--->mysql-bin.000002	925 第二次增量

使用全量备份和增量备份进行恢复

[root@localhost mysql]# systemctl stop mysqld
 
基于全量的恢复  合并全备数据目录，确保数据的一致性
--redo-only只应用redo日志,不执行undo回滚未提交的数据，等最后一次增量备份合并完成后再进行应用undo日志回滚数据。
[root@localhost ~]# innobackupex --apply-log --use-memory=32m --redo-only /backup/full
[root@localhost ~]# ls /var/lib/mysql
ib_buffer_pool
 
 
[root@localhost backup]# cd full/
[root@localhost full]# cat xtrabackup_binlog_info
mysql-bin.000002	411
[root@localhost full]# cat xtrabackup_checkpoints
backup_type = log-applied   #可以看到全量恢复之后状态由full-backuped--> log-applied
from_lsn = 0
to_lsn = 2635485
last_lsn = 2635494
 
 
全量恢复0---->2635485
前面的全量备份和两次增量备份0----->2635485----->2635839----->2636177
 
-----------------------------------------------------------------------------------
 
第一次增量恢复  将增量备份数据合并到全备数据目录当中
[root@localhost ~]# innobackupex --apply-log --use-memory=32m --redo-only --incremental-dir=/backup/full/inc1 /backup/full
[root@localhost full]# cat xtrabackup_binlog_info
mysql-bin.000002	668
[root@localhost full]# cat xtrabackup_checkpoints
backup_type = log-applied
from_lsn = 0
to_lsn = 2635839
last_lsn = 2635848
全量恢复+第一次增量恢复0---->2635839
前面的全量备份和两次次增量备份 0----->2635485----->2635839----->2636177
 
----------------------------------------------------------------------------------------
 
第二次增量恢复  将增量备份数据合并到全备数据目录当中
[root@localhost ~]# innobackupex --apply-log --use-memory=32m  --incremental-dir=/backup/inc2 /backup/full
 
[root@localhost full]# cat xtrabackup_binlog_info
mysql-bin.000002	925
[root@localhost full]# cat xtrabackup_checkpoints
backup_type = full-prepared
from_lsn = 0
to_lsn = 2636177
last_lsn = 2636186
全量恢复+第一次增量恢复+第二次增量恢复 0------>2636177
前面的全量备份和两次增量备份 0----->2635485----->2635839----->2636177

恢复数据文件

[root@localhost ~]# rm -rf * /var/lib/mysql
[root@localhost ~]# innobackupex --copy-back /backup/full
[root@localhost ~]# ll /var/lib/mysql
total 122924
-rw-r----- 1 root root      302 Jun 30 16:03 ib_buffer_pool
-rw-r----- 1 root root 12582912 Jun 30 16:03 ibdata1
-rw-r----- 1 root root 50331648 Jun 30 16:03 ib_logfile0
-rw-r----- 1 root root 50331648 Jun 30 16:03 ib_logfile1
-rw-r----- 1 root root 12582912 Jun 30 16:03 ibtmp1
drwxr-x--- 2 root root     4096 Jun 30 16:03 mysql
drwxr-x--- 2 root root     8192 Jun 30 16:03 performance_schema
drwxr-x--- 2 root root     8192 Jun 30 16:03 sys
drwxr-x--- 2 root root       56 Jun 30 16:03 test
-rw-r----- 1 root root       21 Jun 30 16:03 xtrabackup_binlog_pos_innodb
-rw-r----- 1 root root      540 Jun 30 16:03 xtrabackup_info
-rw-r----- 1 root root        1 Jun 30 16:03 xtrabackup_master_key_id
 
[root@localhost ~]# chown -R mysql. /var/lib/mysql
[root@localhost ~]# systemctl start mysqld
 
 
这个时候恢复只是恢复到最后一次备份时候状态，还需要借助Binlog来恢复备份之后产生的数据

利用binlog恢复到数据库崩溃前状态

借助binlog进行恢复到最近的状态，从925位置开始恢复
[root@localhost backup]# cd inc2
[root@localhost inc2]# cat xtrabackup_binlog_info 
mysql-bin.000002	925
 
 
[root@localhost ~]# mysqlbinlog --start-position=925 /binlog/mysql-bin.000002 > inc.sql
[root@localhost ~]# mysql -uroot -p
Enter password: 
Welcome to the MySQL monitor.  Commands end with ; or \g.
Your MySQL connection id is 2
Server version: 5.7.30-log MySQL Community Server (GPL)
 
Copyright (c) 2000, 2020, Oracle and/or its affiliates. All rights reserved.
 
Oracle is a registered trademark of Oracle Corporation and/or its
affiliates. Other names may be trademarks of their respective
owners.
 
Type 'help;' or '\h' for help. Type '\c' to clear the current input statement.
 
mysql> source inc.sql;
Query OK, 0 rows affected (0.00 sec)
 
Query OK, 0 rows affected (0.01 sec)
 
Query OK, 0 rows affected (0.00 sec)
 
Query OK, 0 rows affected (0.00 sec)
 
Query OK, 0 rows affected (0.00 sec)
 
Query OK, 0 rows affected (0.00 sec)
 
Query OK, 0 rows affected (0.01 sec)
 
至此数据库恢复完毕到数据库崩溃前状态

redlog和binlog两者的关系

两者都不可以单独使用。

先写read log 而不写bin log 回导致回复不到原来数据

先写bin log 不写read log 会导致还没真正写入就回复了

redo log 和 binlog 都可以用于表示事务的提交状态，而两阶段提交就是让这两个状态保持逻辑上的一致。

redo log 是先 prepare 状态，等 binlog 写完之后，才是 commit 状态，这种方式就叫"两阶段提交"。
redo log 和 binlog 都可以用于表示事务的提交状态，而两阶段提交就是让这两个状态保持逻辑上的一致。
如果不采用这种方式，而是就先写 redo log ，再写 binlog ，会怎样？如果在写 binlog 时，发生了异常，更新操作已经到 redo log 中了，但是此时 binlog 并没有进行更新，就出现了数据不一致，先写 binlog 再写 redo log 也是一样的道理。所以，在写时，先让 redo log 处于 prepare 状态，等 binlog 写完之后，再让 redo log 处于 commit 状态，这样就保持了逻辑上的一致。

由binlog和redo log的概念和区别可知：binlog日志只用于归档，只依靠binlog是没有crash-safe能力的。但只有redo log也不行，因为redo log是InnoDB特有的，且日志上的记录落盘后会被覆盖掉。因此需要binlog和redo log二者同时记录，才能保证当数据库发生宕机重启时，数据不会丢失