【一】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
   


物理备份命令 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 status： 在主库和从库是执行，返回的内容是一样的
show slave  status： 在主库上执行返回空，在从库上执行才有返回,
show slave  host： 在主库上执行返回从库的信息


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>

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系统时，发现在半同步模式下，
	半同步复制降级为异步复制的超时时间