【一】MySQL 备份命令 和 binlog 解析命令 和 gtid 和 表复制 和 登录 和 环境变量

备份命令：

逻辑备份命令 mysqldump:
mysqldump  --single-transaction --master-data=2 --hex-blob --set-gtid-purged=OFF  -uinception -p -h172.25.206.228   xdbamp api   > /tmp/api.sql 
	--master-data
	该选项将当前服务器的binlog的位置和文件名追加到输出文件中(show master status)。
	如果为1，将会输出CHANGE MASTER 命令；
	如果为2，输出的CHANGE  MASTER命令前添加注释信息。
	该选项将打开 --lock-all-tables 选项，除非 --single-transaction也被指定（在这种情况下，全局读锁在开始导出时获得很短的时间；其他内容参考下面的--single-transaction选项）。该选项自动关闭--lock-tables选项。
	
	--single-transaction
	该选项在导出数据之前提交一个BEGIN SQL语句，BEGIN 不会阻塞任何应用程序且能保证导出时数据库的一致性状态。它只适用于多版本存储引擎，仅InnoDB。本选项和--lock-tables 选项是互斥的，因为LOCK  TABLES 会使任何挂起的事务隐含提交。要想导出大表的话，应结合使用--quick 选项。
	mysqldump  -uroot -p --host=localhost --all-databases --single-transaction
	
	--lock-all-tables,  -x
	提交请求锁定所有数据库中的所有表，以保证数据的一致性。这是一个全局读锁，并且自动关闭--single-transaction 和--lock-tables 选项。
	mysqldump  -uroot -p --host=localhost --all-databases --lock-all-tables
	
	--lock-tables,  -l
	开始导出前，锁定所有表。用READ  LOCAL锁定表以允许MyISAM表并行插入。对于支持事务的表例如InnoDB和BDB，--single-transaction是一个更好的选择，因为它根本不需要锁定表。
	请注意当导出多个数据库时，--lock-tables分别为每个数据库锁定表。因此，该选项不能保证导出文件中的表在数据库之间的逻辑一致性。不同数据库表的导出状态可以完全不同。
	mysqldump -uroot -p --host=localhost --all-databases --lock-tables
    
    demo:
    指定表带数据(单库多表，但是导出的 sql 中没有建库语句):
    	mysqldump -h1.1.1.1 db_name tabble1 tabble2 --single-transaction --master-data=2 --hex-blob --set-gtid-purged=OFF > dbt1t2.sql
    	mysqldump -h1.1.1.1 --databases db_name  --tables tabble1 tabble2 --single-transaction --master-data=2 --hex-blob --set-gtid-purged=OFF > dbt1t2.sql
    指定库不带数据只有表结构: 
    	mysqldump -h1.1.1.1 db_name --single-transaction --master-data=2 --hex-blob --set-gtid-purged=OFF --no-data > db.sql
    多库所有表：
    	mysqldump -h1.1.1.1 --databases db_name1 db_name2 --set-gtid-purged=OFF > dbt1t2.sql
    多库多表(需要配合 --ignore-table)：
    mysqldump -h1.1.1.1 --databases db_name1 db_name2 --ignore-table=db_name1.student --ignore-table=db_name2.cbaplayer > dbt1t2.sql
   
逻辑备份：
mysqldump -uroot  -h127.0.0.1 --opt --single-transaction --skip-add-locks --skip-lock-tables --default-character-set=utf8mb4 --hex-blob --flush-logs --set-gtid-purged=OFF --master-data=2 --triggers --routines --events -v --databases dbsv1  robdb > /tmp/dbsv1.sql

物理备份命令 xtrabackup（如果配置文件中没有指定端口，下面的备份命令就需要指定端口，默认是3306） ：
xtrabackup --defaults-file=/etc/my.cnf --backup  -uroot -pxxxxxx -S/var/run/mysqld/mysqld.sock --slave-info --target-dir=/tmp/robertbackup 
xtrabackup --defaults-file=/etc/my.cnf --backup  -uroot -pxxxxxx --host=127.0.0.1              --slave-info --target-dir=/tmp/robertbackup  2>bakup.log

Binlog 解析：
mysqlbinlog --database  archiver  -vv --start-datetime='2021-09-01 12:42:10' --stop-datetime='2021-09-01 12:42:19'  mysql-bin.059841 >/tmp/binlog059841.sql 	

远程下载binglog：
mysqlbinlog --read-from-remote-server --raw --host mysql-internet-cn-north-1-4d1248acd4794d9a.rds.jdcloud.com --port 3306 --user dbs_poc --password=password  mysql-bin.000463

开启binlog:

控制台提供的binlog 文件根据1G大小来切分，如果不满1G就切分为下一个binlog文件，
一般是以下三种情况导致：
a. 重启了实例
b. 在实例上执行了flush logs
c. mysqldump 备份时指定了 --flush-logs 参数

5.7版本，直接在配置文件中指定
	[mysqld]
	log-bin=mysql-bin
	server-id=1
	binlog_format=ROW
重启 mysqld 服务 systemctl start  mysqld ， 查看环境变量
mysql> show variables like 'log_bin%';
+---------------------------------+--------------------------------+
| Variable_name                   | Value                          |
+---------------------------------+--------------------------------+
| log_bin                         | ON                             |
| log_bin_basename                | /var/lib/mysql/mysql-bin       |
| log_bin_index                   | /var/lib/mysql/mysql-bin.index |
| log_bin_trust_function_creators | OFF                            |
| log_bin_use_v1_row_events       | OFF                            |
+---------------------------------+--------------------------------+
5 rows in set (0.01 sec)
mysql> 
mysql> show binlog events; // 查看binlog
mysql> show binlog events [IN 'log_name'] [FROM pos] [LIMIT [offset,] row_count]; //
       选项解析：
       IN 'log_name' 指定要查询的binlog文件名(不指定就是第一个binlog文件)
       FROM pos 指定从哪个pos起始点开始查起(不指定就是从整个文件首个pos点开始算)
       LIMIT [offset,] 偏移量(不指定就是0)
       row_count 查询总条数(不指定就是所有行)
       

Binlog 解析：
mysqlbinlog --database  archiver  -vv --start-datetime='2021-09-01 12:42:10' --stop-datetime='2021-09-01 12:42:19'  mysql-bin.059841 >/tmp/binlog059841.sql 	

远程下载binglog：
mysqlbinlog --read-from-remote-server --raw --host mysql-internet-cn-north-1-4d1248acd4794d9a.rds.jdcloud.com --port 3306 --user dbs_poc --password=password  mysql-bin.000463

开启 gtid

关闭和打开 gtid 的区别是：
在时间点恢复（全量+binlog,全备文件的结束点一定对应着某个 binlog 的位点）如果
没有传入 --start-position 即从文件头开始执行指定的 binlog 文件时：
gtid 开启的话不会报错，因为会跳过已经执行过的事务;
gtid 关闭的话可能会报主键冲突啥的，因为是从头老老实实执行指定的 binlog,
     为了解决冲突就需要加上 --start-position  或者 --start-datetime;
推而广之打开 gtid 话， mysqldump 恢复命令可以多次执行。

Case1: 源数据库没有开 gtid, 目标库开启了 gtid, 则是不能增量恢复的。
如果源数据库没有开启 gtid 的话：源数据库生产的binlog文件中记录的 GTID_NEXT类似 SET @@SESSION.GTID_NEXT= 'ANONYMOUS'。
用这些binlog 去恢复时，如果目标数据库打开了 gtid,则会报： ERROR 1782 (HY000) at line 17: @@SESSION.GTID_NEXT cannot be set to ANONYMOUS when @@GLOBAL.GTID_MODE = ON.

Case2: 源数据库开启 gtid, 目标库关闭了 gtid, 则是不能增量恢复的。
如果源数据库开启 gtid 的话，源数据库生产的binlog文件中记录的 GTID_NEXT类似 SET @@SESSION.GTID_NEXT= '153f7dd4-107e-11ec-8a59-fa163e771f31:339'
用这些binlog 去恢复时，如果目标数据库关闭了 gtid, 则会报：ERROR 1781 (HY000) at line 17: @@SESSION.GTID_NEXT cannot be set to UUID:NUMBER when @@GLOBAL.GTID_MODE = OFF.

Case3: 源、目标数据库同开或者同关闭都是可以增量恢复的

[mysqld]
gtid_mode=on  //开启gtid模式
enforce_gtid_consistency=on   // 强制gtid一直性，用于保证启动gitd后事务的安全

[root@dbs-recover-dest ~]#
[root@dbs-recover-dest ~]# mysqlbinlog  /tmp/dbs/mybackup/mysql3306/mysql-bin.000028 | mysql -h127.0.0.1 -uroot -p  -P3306
mysql: [Warning] Using a password on the command line interface can be insecure.
ERROR 1062 (23000) at line 36: Duplicate entry 'cf0e1cdd326b11ec839afa163e771f31' for key 'PRIMARY' 
[root@dbs-recover-dest ~]#   虽然打开了 gtid, 但是在用 binlog 恢复前需要
[root@dbs-recover-dest ~]#   执行  SET GLOBAL gtid_purged=xxx 否则可能会报主键冲突
[root@dbs-recover-dest ~]#   这是因为当你用全备恢复完后，show variables 得到的 gtid_purged 153f7dd4-107e-11ec-8a59-fa163e771f31:1-130
[root@dbs-recover-dest ~]#   和 全备对应gtid  153f7dd4-107e-11ec-8a59-fa163e771f31:1-226 不一样                                                                          
[root@dbs-recover-dest ~]#   即 130 和 226 之间的事务已经在数据库里了。
[root@dbs-recover-dest ~]#                                                                        
mysql>               
mysql> SET GLOBAL gtid_purged='153f7dd4-107e-11ec-8a59-fa163e771f31:1-226';      ------这一步很关键
ERROR 1840 (HY000): @@GLOBAL.GTID_PURGED can only be set when @@GLOBAL.GTID_EXECUTED is empty.
mysql> 
mysql> show global variables like '%gtid%';
+----------------------------------+--------------------------------------------+
| Variable_name                    | Value                                      |
+----------------------------------+--------------------------------------------+
| binlog_gtid_simple_recovery      | ON                                         |
| enforce_gtid_consistency         | ON                                         |
| gtid_executed                    | 153f7dd4-107e-11ec-8a59-fa163e771f31:1-130 |
| gtid_executed_compression_period | 1000                                       |
| gtid_mode                        | ON                                         |
| gtid_owned                       |                                            |
| gtid_purged                      | 153f7dd4-107e-11ec-8a59-fa163e771f31:1-130 |
| session_track_gtids              | OFF                                        |
+----------------------------------+--------------------------------------------+
8 rows in set (0.00 sec)
mysql> 
mysql> reset master;
Query OK, 0 rows affected (0.01 sec)
mysql> 
mysql> show global variables like '%gtid%';
+----------------------------------+-------+
| Variable_name                    | Value |
+----------------------------------+-------+
| binlog_gtid_simple_recovery      | ON    |
| enforce_gtid_consistency         | ON    |
| gtid_executed                    |       |
| gtid_executed_compression_period | 1000  |
| gtid_mode                        | ON    |
| gtid_owned                       |       |
| gtid_purged                      |       |
| session_track_gtids              | OFF   |
+----------------------------------+-------+
8 rows in set (0.00 sec)
mysql>
mysql> SET GLOBAL gtid_purged='153f7dd4-107e-11ec-8a59-fa163e771f31:1-226';
Query OK, 0 rows affected (0.01 sec)
mysql> 
mysql> show global variables like '%gtid%';
+----------------------------------+--------------------------------------------+
| Variable_name                    | Value                                      |
+----------------------------------+--------------------------------------------+
| binlog_gtid_simple_recovery      | ON                                         |
| enforce_gtid_consistency         | ON                                         |
| gtid_executed                    | 153f7dd4-107e-11ec-8a59-fa163e771f31:1-272 |
| gtid_executed_compression_period | 1000                                       |
| gtid_mode                        | ON                                         |
| gtid_owned                       |                                            |
| gtid_purged                      | 153f7dd4-107e-11ec-8a59-fa163e771f31:1-226 |
| session_track_gtids              | OFF                                        |
+----------------------------------+--------------------------------------------+
8 rows in set (0.00 sec)
mysql> 
扩展：
	purge binary logs to 'mysql-bin.000042';   // 这样也可以设置 gtid_purged； 因为解析binlog文件可以看到其中有  Previous-GTIDs
	MySQL [yjy]>
	MySQL [yjy]> show master logs;
	+------------------+------------+
	| Log_name         | File_size  |
	+------------------+------------+
	| mysql-bin.000041 | 1073741899 |
	| mysql-bin.000042 | 1073744635 |
	| mysql-bin.000043 | 1073743780 |
	| mysql-bin.000044 | 1073743108 |
	| mysql-bin.000045 |   80997402 |
	+------------------+------------+
	5 rows in set (0.00 sec)
	MySQL [yjy]> purge binary logs to 'mysql-bin.000042';
	Query OK, 0 rows affected (0.02 sec)
	MySQL [yjy]> 
	MySQL [yjy]> show global variables like "%gtid%";
	+----------------------------------+-------------------------------------------------+
	| Variable_name                    | Value                                           |
	+----------------------------------+-------------------------------------------------+
	| binlog_gtid_simple_recovery      | ON                                              |
	| enforce_gtid_consistency         | ON                                              |
	| gtid_executed                    | 0a76d736-c142-11ec-b119-6ad7f7d3a9a2:1-10588133 |
	| gtid_executed_compression_period | 1000                                            |
	| gtid_mode                        | ON                                              |
	| gtid_owned                       |                                                 |
	| gtid_purged                      | 0a76d736-c142-11ec-b119-6ad7f7d3a9a2:1-9492883  |
	| session_track_gtids              | OFF                                             |
	+----------------------------------+-------------------------------------------------+
	8 rows in set (0.00 sec)
	MySQL [yjy]>
	下面是解析 binlog 文件来验证，
	解析binlog文件可以看到其中有  Previous-GTIDs：0a76d736-c142-11ec-b119-6ad7f7d3a9a2:1-9492883
 	[root@jdos-db-dev-e1b38e02 binlog]# mysqlbinlog mysql-bin.000042 > a.sql
	[root@jdos-db-dev-e1b38e02 binlog]# head -30 a.sql 
	/*!50530 SET @@SESSION.PSEUDO_SLAVE_MODE=1*/;
	/*!50003 SET @OLD_COMPLETION_TYPE=@@COMPLETION_TYPE,COMPLETION_TYPE=0*/;
	DELIMITER /*!*/;
	# at 4
	#230203 10:28:31 server id 1700183306  end_log_pos 123 CRC32 0x67520732 	Start: binlog v 4, server v 5.7.32-log created 230203 10:28:31
	BINLOG '
	T3HcYw8KvVZldwAAAHsAAAAAAAQANS43LjMyLWxvZwAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
	AAAAAAAAAAAAAAAAAAAAAAAAEzgNAAgAEgAEBAQEEgAAXwAEGggAAAAICAgCAAAACgoKKioAEjQA
	ATIHUmc=
	'/*!*/;
	# at 123
	#230203 10:28:31 server id 1700183306  end_log_pos 194 CRC32 0xbd7ee803 	Previous-GTIDs
	# 0a76d736-c142-11ec-b119-6ad7f7d3a9a2:1-9492883
	# at 194
	#230203 10:28:31 server id 1700183306  end_log_pos 259 CRC32 0x32701170 	GTID	last_committed=0	sequence_number=1	rbr_only=yes
	/*!50718 SET TRANSACTION ISOLATION LEVEL READ COMMITTED*//*!*/;
	SET @@SESSION.GTID_NEXT= '0a76d736-c142-11ec-b119-6ad7f7d3a9a2:9492884'/*!*/;
	# at 259
	#230203 10:28:31 server id 1700183306  end_log_pos 357 CRC32 0x6eaa5fba 	Query	thread_id=61279354	exec_time=0	error_code=0
	SET TIMESTAMP=1675391311/*!*/;
	SET @@session.pseudo_thread_id=61279354/*!*/;
	SET @@session.foreign_key_checks=1, @@session.sql_auto_is_null=0, @@session.unique_checks=1, @@session.autocommit=1/*!*/;
	SET @@session.sql_mode=1075838976/*!*/;
	SET @@session.auto_increment_increment=1, @@session.auto_increment_offset=1/*!*/;
	/*!\C utf8 *//*!*/;
	SET @@session.character_set_client=33,@@session.collation_connection=33,@@session.collation_server=83/*!*/;
	SET @@session.time_zone='SYSTEM'/*!*/;
	SET @@session.lc_time_names=0/*!*/;
	SET @@session.collation_database=DEFAULT/*!*/;
	BEGIN
	[root@jdos-db-dev-e1b38e02 binlog]#

show master /slave status :

show master logs:  等于 show binary logs；  Lists the binary log files on the serve

show master status： 在主库和从库是执行，返回的内容 格式 是一样的；This statement provides status information about the binary log files of the source. 
show slave  status： 在主库上执行返回空，在从库上执行才有返回,
show slave  hosts： 在主库上执行返回从库的信息, 在从库上执行返回空


mysql> show maser logs;
+---------------+-----------+
| Log_name      | File_size |
+---------------+-----------+
| binlog.000015 |    724935 |
| binlog.000016 |    733481 |
+---------------+-----------+
mysql>
mysql> show master status \G
*************************** 1. row ***************************
             File: mysql-bin.000205
         Position: 967511450
     Binlog_Do_DB:
 Binlog_Ignore_DB:
Executed_Gtid_Set: 73fa0896-e6ef-11e7-9eee-90e2baef9a6c:1-210633782,
9d28e9d4-1fc2-11e9-b7fa-90e2baef92f0:1-2339
1 row in set (0.00 sec)

mysql>
mysql>
mysql> show slave status  \G
*************************** 1. row ***************************
               Slave_IO_State: Waiting for master to send event
                  Master_Host: 1.1.1.1
                  Master_User: repl
                  Master_Port: 3306
                Connect_Retry: 60
              Master_Log_File: mysql-bin.000263
          Read_Master_Log_Pos: 399336513
               Relay_Log_File: mysqld-relay-bin.16951759
                Relay_Log_Pos: 454
        Relay_Master_Log_File: mysql-bin.000263
             Slave_IO_Running: Yes
            Slave_SQL_Running: Yes
              Replicate_Do_DB:
          Replicate_Ignore_DB:
           Replicate_Do_Table:
       Replicate_Ignore_Table:
      Replicate_Wild_Do_Table:
  Replicate_Wild_Ignore_Table:
                   Last_Errno: 0
                   Last_Error:
                 Skip_Counter: 0
          Exec_Master_Log_Pos: 399333105
              Relay_Log_Space: 40716424
              Until_Condition: None
               Until_Log_File:
                Until_Log_Pos: 0
           Master_SSL_Allowed: No
           Master_SSL_CA_File:
           Master_SSL_CA_Path:
              Master_SSL_Cert:
            Master_SSL_Cipher:
               Master_SSL_Key:
        Seconds_Behind_Master: 0
Master_SSL_Verify_Server_Cert: No
                Last_IO_Errno: 0
                Last_IO_Error:
               Last_SQL_Errno: 0
               Last_SQL_Error:
  Replicate_Ignore_Server_Ids:
             Master_Server_Id: 2072283306
                  Master_UUID: 73fa0896-e6ef-11e7-9eee-90e2baef9a6c
             Master_Info_File: mysql.slave_master_info
                    SQL_Delay: 0
          SQL_Remaining_Delay: NULL
      Slave_SQL_Running_State: Slave has read all relay log; waiting for more updates
           Master_Retry_Count: 86400
                  Master_Bind:
      Last_IO_Error_Timestamp:
     Last_SQL_Error_Timestamp:
               Master_SSL_Crl:
           Master_SSL_Crlpath:
           Retrieved_Gtid_Set: 73fa0896-e6ef-11e7-9eee-90e2baef9a6c:70175637-210633752
            Executed_Gtid_Set: 73fa0896-e6ef-11e7-9eee-90e2baef9a6c:1-210633752,
9d28e9d4-1fc2-11e9-b7fa-90e2baef92f0:1-2339
                Auto_Position: 1
         Replicate_Rewrite_DB:
                 Channel_Name:
           Master_TLS_Version:
1 row in set (0.01 sec)

mysql>
mysql>
mysql> show slave hosts;
+-----------+---------------+------+-----------+--------------------------------------+
| Server_id | Host          | Port | Master_id | Slave_UUID                           |
+-----------+---------------+------+-----------+--------------------------------------+
| 921853309 | 10.10.101.100 | 3309 | 920413309 | f63b5336-09b0-11e9-8ee1-58f9874c9bac |
+-----------+---------------+------+-----------+--------------------------------------+
1 row in set (0.00 sec)

mysql>

Slave_IO_State: 线程已经连接上主服务器，正等待二进制日志事件到达
Master_Host: 主服务器ip
Master_User: 连接主服务器使用的用户
Master_Port: 主服务器的端口
Connect_Retry: 当重新建立主从连接时，如果连接建立失败，间隔多久后重试，默认60s。
Master_Log_File: I/O线程当前正在读取的主服务器二进制日志文件的名称
Read_Master_Log_Pos: 在当前的主服务器二进制日志中，I/O线程已经读取的位置。
Relay_Log_File: SQL线程当前正在读取和执行的中继日志文件的名称
Relay_Log_Pos: SQL线程在当前的中继日志中已读取和执行的位置。
Relay_Master_Log_File: SQL线程执行的主服务器二进制文件
Slave_IO_Running: I/O线程是否运行并成功地连接到主服务器上。
Slave_SQL_Running: SQL线程是否运行。
Replicate_Do_DB:用于复制的数据库，必须在配置文件中配置了
Replicate_Ignore_DB:不用来复制的数据库
Replicate_Do_Table:复制表
Replicate_Ignore_Table:不复制的表
Replicate_Wild_Do_Table: 限制复制更新的表匹配指定的数据库和表名模式的语句
Replicate_Wild_Ignore_Table: 不要复制表匹配给出的通配符模式的语句
Last_Errno:错误代码
Last_Error:错误信息
Skip_Counter: SQL_SLAVE_SKIP_COUNTER的值
Exec_Master_Log_Pos: 主服务器上一个被执行的位置
Relay_Log_Space: 中继日志文件大小
Until_Condition: 在START SLAVE语句的UNTIL子句中指定的值
Until_Log_File: 用于指示日志文件名
Until_Log_Pos: 位置值
Master_SSL_Allowed: 如果允许对主服务器进行SSL连接，则值为Yes
否则NO
Master_SSL_CA_File:下面的这些都是SSL连接的一些信息
Master_SSL_CA_Path:
Master_SSL_Cert:
Master_SSL_Cipher:
Master_SSL_Key:
Seconds_Behind_Master: 本字段是从属服务器落后多少的一个指示(这个状态是一个很重要的性能指标，正常为0，如果从服务器的I/O线程无法连接主服务器显示null)
Master_SSL_Verify_Server_Cert: No
Last_IO_Errno: 最近的IO线程错误代码，其中2003代表I/o线程无法连接主服务器
Last_IO_Error: 最近的IO线程错误信息（例如：error reconnecting to master 'repl@192.168.1.6:3306' - retry-time: 60  retries: 3）
Last_SQL_Errno: 最近的SQL线程错误代码
Last_SQL_Error: 最近的SQL线程错误信息
Replicate_Ignore_Server_Ids:
Master_Server_Id: 主服务器的服务器ID
Master_UUID: 主服务器的UUID值
Master_Info_File: 从服务器的master.info文件路径
SQL_Delay: 正数表明slave有延迟了
SQL_Remaining_Delay: 整数表明延迟时间
Slave_SQL_Running_State: SQL线程运行状态（SQL线程已经处理了中继日志文件中的所有事件，现在正等待I/O线程将新事件写入中继日志。
）
Master_Retry_Count: 86400
Master_Bind:
Last_IO_Error_Timestamp:最近的I/O线程错误时间
Last_SQL_Error_Timestamp:最近的SQL线程报错时间
Master_SSL_Crl:
Master_SSL_Crlpath:
Retrieved_Gtid_Set:
Executed_Gtid_Set:
Auto_Position: 0

redo 日志

mysql 为了提升性能不会把每次的修改都实时同步到磁盘，而是会先存到Boffer Pool(缓冲池)里头，
把这个当作缓存来用。然后使用后台线程去做缓冲池和磁盘之间的同步。

那么问题来了，如果还没来的同步的时候宕机或断电了怎么办？
还没来得及执行上面图中红色的操作。这样会导致丢部分已提交事务的修改信息！
所以引入了redo log来记录已成功提交事务的修改信息，并且会把redo log持久化到磁盘，
系统重启之后在读取redo log恢复最新数据。

redo log（重做日志）是实现事务持久性必备要素，
当一个事务提交后，并非直接修改数据库的数据，而是首先保证在 redo log中记录相关的操作。

总结：
redo log是用来恢复数据的 用于保障已提交事务的持久化特性

数据库表复制(克隆):

insert into Table2(field1,field2,…) select value1,value2,… from Table1：

insert into zzz(name, description, where_clause, rule_type, parallel_degree, create_datetime, update_datetime, src_table_id, rule_status, split_column_name, split_column_operator, split_column_type, split_column_value, trans_row, delete_row, create_user_id, is_splitting, delimiter, rule_hash, workorder, workorder_owner) 
select name, concat('clone_from_', id), where_clause, rule_type, parallel_degree, NOW(), NOW(), src_table_id, 0, split_column_name, split_column_operator, split_column_type, split_column_value, 0, 0, 99, 0, delimiter, rule_hash, workorder, workorder_owner 
from trans_rule_20210623 where id = 1227;

重命名表：

list_table=$(mysql -uname-ppassword -Nse "select table_name from information_schema.TABLES where TABLE_SCHEMA='dbs'")
for table in $list_table; do mysql -uname -ppassword -e "rename table dbs.$table to dbsbackup.$table"; done;

mysql 登录：

TCP/IP方式连接：
TCP/IP套接字方式是MySQL在任何平台下都提供的连接方式，也是网络中使用得最多的一种方式。
这种方式在TCP/IP连接上建立一个基于网络的连接请求，
一般情况下客户端在一台服务器上，MySQL实例在另一台服务器上，这两台机器通过一个TCP/IP网络连接。

socket(套接字)连接方式：
在Linux和Unix环境下，还可以使用Unix域套接字。
Unix域套接字其实不是一个网络协议，所以只能在MySQL客户端和数据库实例在同一台服务器上的情况下使用(本地连接)。
你可以在配置文件中指定套接字文件的路径，如-socket=/tmp/mys

环境变量:

rpl_semi_sync_master_timeout ：
	部署基于MySQL原生复制的HA系统时，发现在半同步模式下，
	半同步复制降级为异步复制的超时时间