MySQL5.7(5.6)GTID环境下恢复从库思路方法(转发）

要讨论如何恢复从库，我们得先来了解如下一些概念：

GTID_EXECUTED:它是一组包含已经记录在二进制日志文件中的事务集合

GTID_PURGED:它是一组包含已经从二进制日志删除掉的事务集合。

在继续讨论时，我们先来看下如何新建一个基于GTID的slave。

通过了解上面的两个参数，我们现在只需要：

1.从主库上做一个备份时记录备份时gtid_executed的值。

2.在新的slave上恢复此备份时设置从库的gtid_purged的值为备份时master上gtid_executed的值。

通过mysqldump可以完成我们需要的功能。

目前主库上的状态（3301）：

[zejin] 3301>show global variables like 'gtid_executed';

+---------------+-------------------------------------------+

| Variable_name | Value |

+---------------+-------------------------------------------+

| gtid_executed | a97983fc-5a29-11e6-9d28-000c29d4dc3f:1-15 |

+---------------+-------------------------------------------+

1 row in set (0.00 sec)

[zejin] 3301>show global variables like 'gtid_purged';

+---------------+-------------------------------------------+

| Variable_name | Value |

+---------------+-------------------------------------------+

| gtid_purged | a97983fc-5a29-11e6-9d28-000c29d4dc3f:1-13 |

+---------------+-------------------------------------------+

1 row in set (0.00 sec)

step1:用mysqldump做一个全备

mysqldump --all-databases --single-transaction --triggers --routines --events --host=127.0.0.1 --port=3301 --user=root --password=123 > dump3301.sql

打开dump3301.sql我们可以看到如下语句：

SET @@GLOBAL.GTID_PURGED='a97983fc-5a29-11e6-9d28-000c29d4dc3f:1-15';

此值即为master3301上gtid_executed的值。

step2:全新启动一个新的库3303,注意在配置文件中配置enforce_gtid_consistency及gtid_mode=on

mysqld_safe --defaults-file=/home/mysql/my3303.cnf &

此时新库3303上的状态应该是这样的：

[(none)] 3303>show global variables like 'gtid_executed';

+---------------+-------+

| Variable_name | Value |

+---------------+-------+

| gtid_executed | |

+---------------+-------+

1 row in set (0.01 sec)

[(none)] 3303>show global variables like 'gtid_purged';

+---------------+-------+

| Variable_name | Value |

+---------------+-------+

| gtid_purged | |

+---------------+-------+

1 row in set (0.00 sec)

step3:导入备份文件并查看状态值：

mysql -uroot -h127.0.0.1 -p123 -P3303 < dump3301.sql

[(none)] 3303>show global variables like 'gtid_executed';

+---------------+-------------------------------------------+

| Variable_name | Value |

+---------------+-------------------------------------------+

| gtid_executed | a97983fc-5a29-11e6-9d28-000c29d4dc3f:1-15 |

+---------------+-------------------------------------------+

1 row in set (0.02 sec)

[(none)] 3303>show global variables like 'gtid_purged';

+---------------+-------------------------------------------+

| Variable_name | Value |

+---------------+-------------------------------------------+

| gtid_purged | a97983fc-5a29-11e6-9d28-000c29d4dc3f:1-15 |

+---------------+-------------------------------------------+

1 row in set (0.00 sec)

step4:做主从change语句

[zejin] 3303>change master to master_host='192.168.1.240',master_port=3301,master_user='repl',master_password='123',master_auto_position=1;

Query OK, 0 rows affected, 2 warnings (0.01 sec)

[zejin] 3303>start slave;

Query OK, 0 rows affected (0.00 sec)

[zejin] 3303>show slave status\G

*************************** 1. row ***************************

               Slave_IO_State: Waiting for master to send event

                  Master_Host: 192.168.1.240

                  Master_User: repl

                  Master_Port: 3301

                Connect_Retry: 60

              Master_Log_File: binlog57.000014

          Read_Master_Log_Pos: 194

               Relay_Log_File: zejin240-relay-bin.000002

                Relay_Log_Pos: 365

        Relay_Master_Log_File: binlog57.000014

             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: 194

              Relay_Log_Space: 575

              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: 3301

                  Master_UUID: a97983fc-5a29-11e6-9d28-000c29d4dc3f

             Master_Info_File: /home/mysql/I3303/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:

            Executed_Gtid_Set: a97983fc-5a29-11e6-9d28-000c29d4dc3f:1-15

                Auto_Position: 1

         Replicate_Rewrite_DB:

                 Channel_Name:

           Master_TLS_Version:

1 row in set (0.00 sec)

至此完成了加入一台新的slave的GTID主从环境。

假如我们目前拥有一主带两从的环境：

master（3301）

slave（3302）

slave（3303）

我们来考虑这么一种异常情况，由于种种原因，有可能主库上已经purge掉了一些binlog，但从库都还没有接收到（如slave停了一段时间，而master已经把一些binlog给purge掉了。）

主库目前的状态是：

[zejin] 3301>show global variables like 'gtid_executed';

+---------------+-------------------------------------------+

| Variable_name | Value |

+---------------+-------------------------------------------+

| gtid_executed | a97983fc-5a29-11e6-9d28-000c29d4dc3f:1-21 |

+---------------+-------------------------------------------+

1 row in set (0.00 sec)

[zejin] 3301>show global variables like 'gtid_purged';

+---------------+-------------------------------------------+

| Variable_name | Value |

+---------------+-------------------------------------------+

| gtid_purged | a97983fc-5a29-11e6-9d28-000c29d4dc3f:1-20 |

+---------------+-------------------------------------------+

1 row in set (0.00 sec)

[zejin] 3301>select * from t_users;

+----+------+

| id | name |

+----+------+

| 1 | chen |

| 2 | ok |

| 3 | li |

+----+------+

3 rows in set (0.00 sec)

在从库3303上，我们可以看到如下错误提示：

Last_IO_Error: Got fatal error 1236 from master when reading data from binary log: 'The slave is connecting using CHANGE MASTER TO MASTER_AUTO_POSITION = 1, but the master has purged binary logs containing GTIDs that the slave requires.'

[zejin] 3303>show slave status\G

*************************** 1. row ***************************

               Slave_IO_State:

                  Master_Host: 192.168.1.240

                  Master_User: repl

                  Master_Port: 3301

                Connect_Retry: 60

              Master_Log_File: binlog57.000014

          Read_Master_Log_Pos: 457

               Relay_Log_File: zejin240-relay-bin.000003

                Relay_Log_Pos: 4

        Relay_Master_Log_File: binlog57.000014

             Slave_IO_Running: No

            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: 457

              Relay_Log_Space: 194

              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: NULL

Master_SSL_Verify_Server_Cert: No

                Last_IO_Errno: 1236

                Last_IO_Error: Got fatal error 1236 from master when reading data from binary log: 'The slave is connecting using CHANGE MASTER TO MASTER_AUTO_POSITION = 1, but the master has purged binary logs containing GTIDs that the slave requires.'

               Last_SQL_Errno: 0

               Last_SQL_Error:

  Replicate_Ignore_Server_Ids:

             Master_Server_Id: 3301

                  Master_UUID: a97983fc-5a29-11e6-9d28-000c29d4dc3f

             Master_Info_File: /home/mysql/I3303/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: 160809 17:25:39

     Last_SQL_Error_Timestamp:

               Master_SSL_Crl:

           Master_SSL_Crlpath:

           Retrieved_Gtid_Set: a97983fc-5a29-11e6-9d28-000c29d4dc3f:16

            Executed_Gtid_Set: a97983fc-5a29-11e6-9d28-000c29d4dc3f:1-16

                Auto_Position: 1

         Replicate_Rewrite_DB:

                 Channel_Name:

           Master_TLS_Version:

1 row in set (0.00 sec)

[zejin] 3303>select * from t_users;

+----+------+

| id | name |

+----+------+

|  1 | li   |

|  2 | zhou |

+----+------+

2 rows in set (0.00 sec)

主从已经中断，数据也已不一致。

接下来我们来看如何恢复：

由于GTID具有全局唯一性，那么其它正常的gtid已经被复制到了slave3302上，所以我们可以把3303指向3302，同步完毕后再指回master3301（此前提基于3302的binlog还没被purge掉，即存在3303没有从master3301接收到的GTID事务）

操作方法如下：

[zejin] 3303>change master to master_host='192.168.1.240',master_port=3302,master_user='repl',master_password='123',master_auto_position=1;

[zejin] 3303>start slave;

Query OK, 0 rows affected (0.03 sec)

[zejin] 3303>show slave status\G

*************************** 1. row ***************************

               Slave_IO_State: Waiting for master to send event

                  Master_Host: 192.168.1.240

                  Master_User: repl

                  Master_Port: 3302

                Connect_Retry: 60

              Master_Log_File: binlog57.000007

          Read_Master_Log_Pos: 1723

               Relay_Log_File: zejin240-relay-bin.000002

                Relay_Log_Pos: 1687

        Relay_Master_Log_File: binlog57.000007

             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: 1723

              Relay_Log_Space: 1937

              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: 3302

                  Master_UUID: 5cee6f9f-5ab8-11e6-a081-000c29d4dc3f

             Master_Info_File: /home/mysql/I3303/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: a97983fc-5a29-11e6-9d28-000c29d4dc3f:17-21

            Executed_Gtid_Set: a97983fc-5a29-11e6-9d28-000c29d4dc3f:1-21

                Auto_Position: 1

         Replicate_Rewrite_DB:

                 Channel_Name:

           Master_TLS_Version:

1 row in set (0.00 sec)

[zejin] 3303>select * from t_users;

+----+------+

| id | name |

+----+------+

|  1 | chen |

|  2 | ok   |

|  3 | li   |

+----+------+

3 rows in set (0.00 sec)

数据也已经完全与主的一致了，复制正常后再change到3301master上。

[zejin] 3303>change master to master_host='192.168.1.240',master_port=3301,master_user='repl',master_password='123',master_auto_position=1;

Query OK, 0 rows affected, 2 warnings (0.01 sec)

[zejin] 3303>start slave;

Query OK, 0 rows affected (0.00 sec)

上面这种情况是基于还有另一个从库已经接收到了master的所有binlog的情况下，那如果结果只是M-S，也发生了如上的问题，那又该如何恢复，我们有如下两种方法：

目前Master上状态为：

[zejin] 3301>show global variables like '%gtid%';

+----------------------------------+-------------------------------------------+

| Variable_name                    | Value                                     |

+----------------------------------+-------------------------------------------+

| gtid_executed                    | a97983fc-5a29-11e6-9d28-000c29d4dc3f:1-27 |

……

| gtid_purged                      | a97983fc-5a29-11e6-9d28-000c29d4dc3f:1-25 |

……

+----------------------------------+-------------------------------------------+

8 rows in set (0.00 sec)

Slave上状态为：

[zejin] 3303>show slave status \G

*************************** 1. row ***************************

               Slave_IO_State:

                  Master_Host: 192.168.1.240

                  Master_User: repl

                  Master_Port: 3301

                Connect_Retry: 60

              Master_Log_File: binlog57.000016

          Read_Master_Log_Pos: 729

               Relay_Log_File: zejin240-relay-bin.000003

                Relay_Log_Pos: 4

        Relay_Master_Log_File: binlog57.000016

             Slave_IO_Running: No

            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: 729

              Relay_Log_Space: 194

              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: NULL

Master_SSL_Verify_Server_Cert: No

                Last_IO_Errno: 1236

                Last_IO_Error: Got fatal error 1236 from master when reading data from binary log: 'The slave is connecting using CHANGE MASTER TO MASTER_AUTO_POSITION = 1, but the master has purged binary logs containing GTIDs that the slave requires.'

               Last_SQL_Errno: 0

               Last_SQL_Error:

  Replicate_Ignore_Server_Ids:

             Master_Server_Id: 3301

                  Master_UUID: a97983fc-5a29-11e6-9d28-000c29d4dc3f

             Master_Info_File: /home/mysql/I3303/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: 160809 17:54:42

     Last_SQL_Error_Timestamp:

               Master_SSL_Crl:

           Master_SSL_Crlpath:

           Retrieved_Gtid_Set: a97983fc-5a29-11e6-9d28-000c29d4dc3f:22

            Executed_Gtid_Set: a97983fc-5a29-11e6-9d28-000c29d4dc3f:1-22

                Auto_Position: 1

         Replicate_Rewrite_DB:

                 Channel_Name:

           Master_TLS_Version:

1 row in set (0.00 sec)

和之前同样类型的错误，我们恢复的思路为：

把slave上的gtid_purged设置为master还没有被purge掉的值，最后借助第三方一致性同步工具来做数据的一致性同步。

我们需要先在slave上做一下reset master来清除gtid的一些信息，直接设置会报如下错误：

[zejin] 3303>set global GTID_PURGED="a97983fc-5a29-11e6-9d28-000c29d4dc3f:1-26";

ERROR 1840 (HY000): @@GLOBAL.GTID_PURGED can only be set when @@GLOBAL.GTID_EXECUTED is empty.

正确操作步骤如下（在slave上执行）：

[zejin] 3303>reset master;

Query OK, 0 rows affected (0.02 sec)

[zejin] 3303>set global GTID_PURGED="a97983fc-5a29-11e6-9d28-000c29d4dc3f:1-26";

Query OK, 0 rows affected (0.00 sec)

[zejin] 3303>start slave;

Query OK, 0 rows affected (0.00 sec)

[zejin] 3303>show slave status \G

*************************** 1. row ***************************

               Slave_IO_State: Waiting for master to send event

                  Master_Host: 192.168.1.240

                  Master_User: repl

                  Master_Port: 3301

                Connect_Retry: 60

              Master_Log_File: binlog57.000018

          Read_Master_Log_Pos: 728

               Relay_Log_File: zejin240-relay-bin.000004

                Relay_Log_Pos: 718

        Relay_Master_Log_File: binlog57.000018

             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: 728

              Relay_Log_Space: 968

              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: 3301

                  Master_UUID: a97983fc-5a29-11e6-9d28-000c29d4dc3f

             Master_Info_File: /home/mysql/I3303/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: a97983fc-5a29-11e6-9d28-000c29d4dc3f:22:27

            Executed_Gtid_Set: a97983fc-5a29-11e6-9d28-000c29d4dc3f:1-27

                Auto_Position: 1

         Replicate_Rewrite_DB:

                 Channel_Name:

           Master_TLS_Version:

1 row in set (0.00 sec)

当然执行完这个之后数据是不一致的，那么此时就可以通过pt-table-checksum和pt-table-sync来做数据的一致性恢复了。

我们还有另一种方法，那就是重建slave，方法如本文最开始的那样新建一个slave，但是在由于目前slave上已经有gtid的一些信息，所以在恢复时得先在slave上reset master，具体操作如下：

在slave上操作：

reset master

source dump3301.sql;

change master to master_host='192.168.1.240',master_port=3301,master_user='repl',master_password='123',master_auto_position=1;

start slave;

show slave status\G

至此完成slave同步异常的恢复。

MySQL5.7(5.6)GTID环境下恢复从库思路方法(转发）的更多相关文章

MySQL5.7(5.6)GTID环境下恢复从库思(qi)路(yin)方(ji)法(qiao)
要讨论如何恢复从库,我们得先来了解如下一些概念: GTID_EXECUTED:它是一组包含已经记录在二进制日志文件中的事务集合 GTID_PURGED:它是一组包含已经从二进制日志删除掉的事务集合 ...
python环境下安装opencv库的方法
注意:安装opencv之前需要先安装numpy,matplotlib等一.安装方法方法一.在线安装 1.先安装opencv-python pip install opencv-python --u ...
linux下恢复误删除的文件方法（ext2及ext3）
linux下恢复误删除的文件方法(ext2及ext3) 2009-12-19 15:23:47 分类: LINUX 如果是ext2文件系统的,直接用debugfs是可以恢复出来的,但对于ext3,d ...
mac下使用glew库，方法
mac下使用glew库,方法分类: OpenGL2015-01-15 15:52 210人阅读评论(0) 收藏举报目录(?)[+] 主要参考http://www.cnblogs.com ...
mysql 在gtid环境下缺少一部分binlog部署从库
我的环境: 有两台linux服务器一台是192.168.1.1 mysql 端口3301 一台是192.168.1.2 mysql 端口3303 要讨论如何恢复从库,我们得先来了解如下一些概 ...
gtid环境下mysqldump对于set-gtid-purged的取值
gtid环境备份的时候,还在为set-gtid-purged=0|1的选择而烦恼吗,一起来分析一下. [mysql@lxd-vm1@/home/mysql]$ mysqldump --help | g ...
Tomcat：云环境下的Tomcat设计思路——Tomcat的多实例安装
Cloud现在是一个热门的技术,Tomcat是学习Java的人一般都会接触的Web服务器,如果在Cloud环境下使用Tomcat,又当如何呢?不可避免的,要安装多个Tomcat了,这里称之为Tomca ...
VS2017环境下安装AO10.2的方法
软件版本 Visual Studio的全称.简称及版本号对应关系为: Microsoft Visual Studio 2002 VS2002 VC7.0 Microsoft Visual Studio ...
Linux环境下FTP工具的使用方法
在Windows环境下创建Ftp目录作为服务器根目录在Linux端的操作: 从服务器端下载文件到Linux端: ftpget -u User -p Password ServerIP File Fi ...

随机推荐

如何用DAX实现查看每个月中不同类别排名前一位，以及一个简单的svg案例
现在给大家带来的是如何用DAX实现查看每个月中不同类别的排名前一位,最终完成效果如下!!! 首先我们需要两张简单的表基数表和类别表当我们创建好表之后,我们再创建一个表格,然后我们将类别表里的列值 ...
threejs path controls example html
<!DOCTYPE html> <html lang="en"> <head> <title>three.js webgl - pa ...
修改select样式
CSS就可以解决,原理是将浏览器默认的下拉框样式清除,然后应用上自己的,再附一张向右对齐小箭头的图片即可. select { /*Chrome和Firefox里面的边框是不一样的,所以复写了一下*/ ...
2018牛客27---D---愤怒: (有关子序列的dp问题)
链接:https://www.nowcoder.com/acm/contest/188/D来源:牛客网题目描述小w很生气小w有一个长为n的括号序列愤怒小w想把这个括号序列分为两个括号序列小w ...
java-冒泡排序、选择排序、二分查找
1.冒泡排序 public void bubbleSort(int[] arr) { for (int i = 0; i < arr.length - 1; i++) { //外循环只需要比较a ...
opencv学习记录
#include<iostream> #include <opencv2/core/core.hpp> #include <opencv2/highgui/highgui ...
20165313 《Java程序设计》第一周学习总结
教材学习内容总结 1.Java的地位 1.网络地位 2.语言地位 3.需求地位 2.Java的特点 1.简单 2.面向对象 3.平台无关 4.多线程 5.动态 3.安装JDK(重点) 注释:需修改系统 ...
走进 AQS 瞧一瞧看一看
并发中有一块很重要的东西就是AQS.接下来一周的目标就是它. 看复杂源码时,一眼望过去,这是什么?不要慌,像剥洋葱一样,一层层剥开(哥,喜欢"扒开"这个词). 参考资源: http ...
SQL Server 排序的时候使 null 值排在最后
https://www.cnblogs.com/Brambling/p/7046148.html 最近遇到一个 SQL Server 排序的问题,以前也没了解过,然后这次碰到了. 才发现 SQL Se ...
java 彻底理解 byte char short int float long double
遇到过很多关于数值类型范围的问题了,在这做一个总结,我们可以从多方面理解不同数值类型的所能表示的数值范围在这里我们只谈论 java中的数值类型首先说byte: 这段是摘自jdk中 Byte.ja ...

MySQL5.7(5.6)GTID环境下恢复从库思路方法(转发）

MySQL5.7(5.6)GTID环境下恢复从库思路方法(转发）的更多相关文章

随机推荐

热门专题