7-15 operation

xtrabackup Realization mysql Incremental backup

 Incremental backup is based on existing data , That's all. You need to create a full backup first , Then record the recording point at that time 

1. Create a backup

xtrabackup --user=bkpuser --password=123456 --backup --target-dir=/data/backups/base
 
#  Incremental backup based on full backup 
xtrabackup --user=bkpuser --password=123456 --backup --target-dir=/data/backups/inc1 --incremental-basedir=/data/backups/base

2. View Backup types Confirm that it is an incremental backup

    [email protected]:/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  It's the beginning of the backup  LSN, For incremental backup , It has to to_lsn As before  base  The backup is the same .

under these circumstances , You can see to_lsn （ The last checkpoint LSN） and last_lsn（ The last copy of LSN） There are differences between , This means that there is some traffic on the server during the backup . We can test it Continue to create increment for the first increment Create several pieces of data before creating an increment

xtrabackup --user=bkpuser --password=123456 --backup
–target-dir=/data/backups/inc2 --incremental-basedir=/data/backups/inc1

3. Prepare to recover

There has been a 3 A backup , We need to prepare the basic data first , Then prepare for two increments

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 Use... When merging all increments except the last one , Once you're ready , Incremental backups are the same as full backups , You can restore them in the same way .

4. recovery

xtrabackup --copy-back --target-dir=/data/backups/base

principle

stay InnoDB The interior will maintain a redo Log files , We can also call it a transaction log file . The transaction log stores every one of them InnoDB Record modification of table data . When InnoDB Startup time ,InnoDB Data files and transaction logs are checked , And perform two steps ： It applies （ Roll forward ） Submitted
Transaction log to data file , And the data that has been modified but not submitted will be rolled back .

Xtrabackup Remember when you start log sequence number（LSN）, And copy all data files . The replication process takes some time , So if the data file changes during this period , This will put the database at a different point in time . At this time ,xtrabackup Will run a background process , Used to monitor transaction logs , And copy the latest changes from the transaction log .Xtrabackup This must be done continuously , It is because the transaction log will rotate the repeated writes , And transaction logs can be reused . therefore xtrabackup Since startup , The modification of each data file in the transaction log is continuously recorded . Above is xtrabackup The backup process of

Can we only use redolog Or just binlog?
Do not introduce two logs , There is no need for two-stage submission . Only binlog To support crash recovery , It also supports archiving , Not on it ？ Only keep binlog, Then you can change the submission process to this ：… -> “ Data update to memory ” -> “ Write binlog” -> “ Commit transaction ”, Can it also provide the ability of crash recovery ？

The answer is no .

If there are historical reasons , That's it InnoDB Not at all MySQL The native storage engine of .MySQL The native engine of is MyISAM, There is no support for crash recovery at the beginning of the design .

InnoDB As a MySQL Add plug-in for MySQL Before the engine family , It's already an engine that provides crash recovery and transaction support .

InnoDB Access MySQL after , I found that since binlog No ability to recover from a crash , Then use InnoDB The original redo log Okay .

Can that be reversed , Only redo log, Don't binlog？

If it's only from the point of view of crash recovery . You can take binlog Turn off the , So there's no two-phase commit , But the system is still crash-safe Of .

binlog with redo log Irreplaceable function . One is filing .redo log It's circular , To write at the end is to go back to the beginning . In this way, the historical log cannot be kept ,redo log It doesn't work as an archive .

One is MySQL The system depends on binlog.binlog As MySQL It has a function from the beginning , It's used in a lot of places . among ,MySQL The foundation of high system availability , Namely binlog Copy .

And a lot of companies have heterogeneous systems （ For example, some data analysis systems ）, These systems depend on consumption MySQL Of binlog To update your data . Turn off the binlog Words , These downstream systems will not be able to input .

All in all , Because now it includes MySQL Many system mechanisms, including high availability, depend on binlog.

utilize iptbles prevent kali Of nmap scanning ？
Nmap You can complete the following tasks ：

     Host detection 
     Port scanning 
     Version checking 
     System detection 
     Support the writing of detection script 

Nmap In practice, the applications are as follows ：
Audit the security of a device or firewall by detecting it
Detect the open port of the target host
Audit network security by identifying new servers
Detect hosts on the network

stay Iptables Configuring these commands on can effectively prevent nmap scanning
[[email protected] goaccess-1.5.4]# iptables -t filter -I INPUT -p tcp --tcp-flags ALL FIN,URG,PSH -j REJECT
[[email protected] goaccess-1.5.4]# iptables -t filter -I INPUT -p tcp --tcp-flags SYN,RST SYN,RST -j REJECT
[[email protected] goaccess-1.5.4]# iptables -t filter -I INPUT -p tcp --tcp-flags SYN,FIN SYN,FIN -j REJECT
[[email protected] goaccess-1.5.4]# iptables -t filter -I INPUT -p tcp --tcp-flags ALL SYN -j REJECT
[[email protected] 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

We use kali Tool execution nmap Function scan , Check whether effective defense is achieved


From the above phenomena, we can see that it can effectively prevent nmap Scan .