congcheng1062

MySQL binlog基于时间点恢复数据失败是什么鬼？

问题现象

某客户反馈，在利用binlog做基于时间点的恢复时，频繁出现无法正确恢复数据的情况（出现概率大约5%~10%）。
数据库环境为MySQL 5.7.27版本的级联复制拓扑（A->B->C），主库A提供写服务，从库B提供读服务，级联复制从库C提供数据的备份和恢复服务。其中，AB库为生产服务库，数据的备份和恢复服务是利用级联复制从库C的数据做定期与手动快照，然后结合从库C的binlog做基于时间点的数据恢复。无法正确恢复数据的情况，具体指的就是实际恢复出来的数据对应的时间点比mysqlbinlog命令指定的时间点要早很多（例如：主库数据已经到达12:00、从库C的快照时间点是10:00、执行恢复操作命令指定的截止时间点是11:00、最终恢复出来的数据时间点是10:30；或者干脆最终恢复出来的数据只有快照数据——即只有10:00的数据，没有任何binlog补偿的数据）。

粗略推导分析

咋一看，有点懵，脑子里迅速推导了几种可能性（不是很靠谱那种）。

* 级联复制的逐级复制可能导致复制的延迟逐级增加、或者大事务导致复制延迟，然后，由于延迟导致的问题。
* 执行备份恢复这一套系统逻辑有BUG导致的问题。
* mysqlbinlog解析工具有BUG、或者MySQL Server在从库端写binlog有BUG导致的问题、或者高负载导致MySQL的脑子坏了？
* 一些未暴露出来的骚操作导致的问题。

PS：

显然，通过这些简单的信息和粗略的推导分析，并不能确定问题的真相，而要确定问题的真相，就需要更详尽的信息以及可复现的方法。下面，我们将遵循这个套路带着大家一步一步剖析问题的真相。

1、信息收集

需要收集哪些信息呢？下面我们大致罗列几种对分析问题可能有帮助的信息。

收集跟问题现象直接相关的数据，用于直观感受问题具体长什么样子。* 跟问题现象相关的操作有哪些，具体是如何操作的。
* 在从库C中解析binlog的原始命令文本，以及对应的binlog原始文件。
* 从库C复制状态与延迟信息。
* 从库C的my.cnf配置模板。
* 从库C中的事务信息、锁信息、show processlist线程状态信息。
收集从库C的主机负载信息和数据库的负载信息，用于判断一些可能由于高负载导致的问题。
收集从库C的MySQL错误日志、操作系统常规日志、操作系统安全日志，用于判断是否有某些错误或者BUG被触发。

收集到上述罗列的信息之后，就使得我们的分析排查工作具备了较强的可操作性了，但这些信息中有的可能是完全没有用的干扰信息、有的可能不是导致问题的因素但可以帮助矫正排查问题的方向（例如：被证实不是它导致的问题之后，就不会往这个方向继续深入分析排查）。真正有用的信息也许大多数时候都在跟你玩捉迷藏。因此我们需要对这些信息进行去伪存真，然后，真正有用的信息大概率就存在于剩下这一部分信息里边了。下面我们将遵循这个原则先在收集到的所有信息中筛选出有用的信息。 PS：留意下文代码段中的中文注释。

2、分析排查

根据收集到的主机负载和数据库的负载信息来判断，从库C的主机负载和数据库的负载信息都比较低，暂时排除高负载导致的问题。根据收集到的各种错误日志来判断，从库C中未找到任何报错信息，暂时排除MySQL Server的BUG导致的问题（但存疑）。根据收集到的跟问题现象直接相关的数据。

并没有发现什么明显的骚操作，排除人为操作事务的可能性。
从库延迟平均在5~20小时（需要引起注意）。
通过mysqlbinlog解析并查看从库C原始的binlog文件后发现，大多数binlog中记录的内容没有发现异常，但有极少数的binlog中的event时间戳顺序是乱序的（需要引起注意）：

* FDE、Previous-GTIDs类型的event时间戳为19:09:10
* 记录数据的event(GTID、Query、Table_map、Update_rows|Delete_rows|Update_rows、Xid)时间戳范围为 19:03:30 ~ 19:12:34
* Rotate类型的event时间戳为19:12:34 mysqlbinlog解析命令指定的--stop-datetime时间戳为'19:08:10'（需要引起注意）。配置模板没有发现什么异常，排除参数配置不当导致的可能性。数据库线程状态无异常、无大事务、也没有长时间的锁等待信息，排除大事务、锁等待、长时间未提交的事务导致的可能性。

根据以上收集到的信息，现在，我们能够大致判断是由于复制延迟引起的，那么，问题来了，复制延迟与基于时间点恢复数据不正确有啥关系？binlog中的event时间戳顺序乱序是怎么回事？mysqlbinlog解析命令指定时间戳为'19:08:10'，是否是碰到了FDE、Previous-GTIDs类型的event时间戳为19:09:10时，发现不满足时间范围条件，直接跳过了解析后续的event(也就是说跳过了数据部分的event解析)？要搞清楚这三个问题，我们就需要想办法复现问题现象了（由于客户现场是不能随便折腾的，所以，我们需要自己找环境来复现该现象，根据上述收集到的信息，复现该问题首先需要刻意制造复制延迟）。 PS：啰嗦一句，我们是如何判断上述信息的有效性的呢？除了需要具备一定的底层知识之外，我个人认为，能够让你感觉到一丝丝不安的因素，都需要注意，不能有意无意地忽略一些潜在的风险点。

3、找到原因

我们在自己的复制环境中，故意制造了复制延迟，以便在从库中制造复制延迟相关的数据。在从库中停止SQL线程，并手动执行flush binary logs语句滚动日志，记录下滚动之后的最后一个binlog。

# 停止SQL线程
root@localhost : (none) 05:21:12> stop slave sql_thread;
Query OK, 0 rows affected (0.00 sec)
# 为了便于后续查看数据以及避免之前记录的binlog内容的干扰，先手动在从库中切换binlog
root@localhost : (none) 05:21:31> flush binary logs;
Query OK, 0 rows affected (0.01 sec)
root@localhost : (none) 05:22:00> show binary logs;
+------------------+-----------+
| Log_name | File_size |
+------------------+-----------+
| mysql-bin.000001 | 60392080 |
......
| mysql-bin.000010 | 194 |  # 滚动之后，罪行的binlog file为mysql-bin.000010
+------------------+-----------+
10 rows in set (0.00 sec)

大约过了10分钟，我们在从库中启动了SQL线程追赶数据，此时查看复制状态，可以发现复制出现了延迟。

# 启动SQL线程
root@localhost : (none) 05:22:13> start slave sql_thread;
Query OK, 0 rows affected (0.00 sec)
# 查看复制状态
root@localhost : (none) 05:30:08> show slave status\G
*************************** 1. row ***************************
           Slave_IO_State: Waiting for master to send event
              Master_Host: 10.10.30.163
              Master_User: repl
              Master_Port: 3306
            Connect_Retry: 10
          Master_Log_File: mysql-bin.000015
      Read_Master_Log_Pos: 375161305
           Relay_Log_File: mysql-relay-bin.000026
            Relay_Log_Pos: 148909788
    Relay_Master_Log_File: mysql-bin.000009
         Slave_IO_Running: Yes
        Slave_SQL_Running: Yes
......
      Exec_Master_Log_Pos: 148909575
          Relay_Log_Space: 3596749378
......
    Seconds_Behind_Master: 648  # 成功制造复制延迟为648秒（当然，这个延迟时间可能不精确，但这里不是重点）
......

在从库中使用mysqlbinlog命令解析查看mysql-bin.000010文件中的内容。

[root@node3 binlog]# ll
total 4836776
......
-rw-r----- 1 mysql mysql 536903179 Jul 29 17:31 mysql-bin.000010
-rw-r----- 1 mysql mysql 21004292 Jul 29 17:31 mysql-bin.000011
-rw-r----- 1 mysql mysql 572 Jul 29 17:31 mysql-bin.index
# 解析文件mysql-bin.000010
[root@node3 binlog]# mysqlbinlog mysql-bin.000010 > a.sql
# 过滤一下a.sql中带server id的数据行，也就是标记event类型的那些文本行
[root@node3 binlog]# grep -E 'server id|GTID_NEXT' a.sql > a.txt 
# 查看两个文件的大小
[root@node3 binlog]# ls -lh a.*
-rw-r--r-- 1 root root 878M Jul 29 17:32 a.sql
-rw-r--r-- 1 root root 322M Jul 29 17:44 a.txt

在从库中使用vim打开a.txt文件，查看所有的event的时间戳信息。

[root@node3 binlog]# vim a.txt
# 发现binlog中event的时间戳乱序了，内容如下(FDE、Previous-GTIDs的时间戳为190729 17:22:00，记录数据的GTID、Query、Table_map、Update_rows|Delete_rows|Update_rows、Xid时间戳在190729 17:19:18 ~ 190729 17:20:57之间，Rotate时间戳为190729 17:20:57)
#190729 17:22:00 server id 33062 end_log_pos 123 CRC32 0xc3a9ea93 Start: binlog v 4, server v 5.7.27-log created 190729 17:22:00
#190729 17:22:00 server id 33062 end_log_pos 194 CRC32 0x22797305 Previous-GTIDs
#190729 17:19:18 server id 33061 end_log_pos 259 CRC32 0xd48537a6 GTID last_committed=0 sequence_number=1 rbr_only=yes
SET @@SESSION.GTID_NEXT= 'd9c5c228-b1e0-11e9-b14d-525400c33752:258161'/*!*/;
#190729 17:19:18 server id 33061 end_log_pos 327 CRC32 0x78818eeb Query thread_id=364 exec_time=650 error_code=0
#190729 17:19:18 server id 33061 end_log_pos 451 CRC32 0x6ca05182 Table_map: `sbtest`.`sbtest1` mapped to number 115
#190729 17:19:18 server id 33061 end_log_pos 867 CRC32 0xce1dc10f Update_rows: table id 115 flags: STMT_END_F
#190729 17:19:18 server id 33061 end_log_pos 986 CRC32 0xf4d017ed Table_map: `sbtest`.`sbtest2` mapped to number 114
#190729 17:19:18 server id 33061 end_log_pos 1211 CRC32 0xbbaebd66 Delete_rows: table id 114 flags: STMT_END_F
#190729 17:19:18 server id 33061 end_log_pos 1541 CRC32 0x14f2e853 Table_map: `sbtest`.`sbtest2` mapped to number 114
#190729 17:19:18 server id 33061 end_log_pos 1766 CRC32 0xd9080627 Write_rows: table id 114 flags: STMT_END_F
#190729 17:19:18 server id 33061 end_log_pos 1797 CRC32 0x1d0265e4 Xid = 1084024
......
#190729 17:20:57 server id 33061 end_log_pos 536900936 CRC32 0x12796d01 GTID last_committed=260141 sequence_number=260157 rbr_only=yes
SET @@SESSION.GTID_NEXT= 'd9c5c228-b1e0-11e9-b14d-525400c33752:518317'/*!*/;
#190729 17:20:57 server id 33061 end_log_pos 536901004 CRC32 0x8eb6df8a Query thread_id=360 exec_time=622 error_code=0
#190729 17:20:57 server id 33061 end_log_pos 536901128 CRC32 0x3e09a82e Table_map: `sbtest`.`sbtest2` mapped to number 114
#190729 17:20:57 server id 33061 end_log_pos 536901544 CRC32 0xa97d84de Update_rows: table id 114 flags: STMT_END_F
#190729 17:20:57 server id 33061 end_log_pos 536901786 CRC32 0x35aec8ff Table_map: `sbtest`.`sbtest1` mapped to number 115
#190729 17:20:57 server id 33061 end_log_pos 536902202 CRC32 0x05064820 Update_rows: table id 115 flags: STMT_END_F
#190729 17:20:57 server id 33061 end_log_pos 536902321 CRC32 0x293c82e4 Table_map: `sbtest`.`sbtest1` mapped to number 115
#190729 17:20:57 server id 33061 end_log_pos 536902546 CRC32 0xe4bfcf8b Delete_rows: table id 115 flags: STMT_END_F
#190729 17:20:57 server id 33061 end_log_pos 536902876 CRC32 0x1fbc35a7 Table_map: `sbtest`.`sbtest1` mapped to number 115
#190729 17:20:57 server id 33061 end_log_pos 536903101 CRC32 0x45c6cc8e Write_rows: table id 115 flags: STMT_END_F
#190729 17:20:57 server id 33061 end_log_pos 536903132 CRC32 0xc6b80fb0 Xid = 2284911
#190729 17:20:57 server id 33062 end_log_pos 536903179 CRC32 0x23a1bcf6 Rotate to mysql-bin.000011 pos: 4

开心 + 激动，赶紧在从库中用mysqlbinlog命令解析一下，这里只需要指定--stop-datetime时间戳小于190729 17:22:00，但大于190729 17:19:18，然后解析数据为空，就确认问题复现了。

# 这里我们就指定--stop-datetime时间戳为190729 17:20:00
[root@node3 binlog]# mysqlbinlog --stop-datetime='2019-07-29 17:20:00' mysql-bin.000010 > b.sql  
[root@node3 binlog]# ls -lh b.sql
-rw-r--r-- 1 root root 336 Jul 29 17:37 b.sql

在从库中，使用vim打开b.sql，嘿，果然发现没有数据，问题现象确认复现了。

# 一字不漏的码出来，就这么点了，没有任何数据相关的event ...
/*!50530 SET @@SESSION.PSEUDO_SLAVE_MODE=1*/;
/*!50003 SET @OLD_COMPLETION_TYPE=@@COMPLETION_TYPE,COMPLETION_TYPE=0*/;
DELIMITER /*!*/;
SET @@SESSION.GTID_NEXT= 'AUTOMATIC' /* added by mysqlbinlog */ /*!*/;
DELIMITER ;
# End of log file
/*!50003 SET COMPLETION_TYPE=@OLD_COMPLETION_TYPE*/;
/*!50530 SET @@SESSION.PSEUDO_SLAVE_MODE=0*/;

so...到这里，我们成功复现了问题现象，但对于前面提出的三个问题，现在，好像一个都没解决呢，现在回顾一下这三个问题：

第一个问题：复制延迟与基于时间点恢复数据不正确有啥关系？

* 对于这个问题，现在看起来好像还是没招。第二个问题： binlog中的event时间戳顺序乱序是怎么回事？
* 对于这个问题，现在可以往前走一步。从a.txt文件中挑选一两个GTID事务号(前面列举的a.txt文件内容代码段中2个事务的GTID分别为d9c5c228-b1e0-11e9-b14d-525400c33752:258161和d9c5c228-b1e0-11e9-b14d-525400c33752:518317)，然后到主库中解析这个GTID事务号对应的binlog记录，看看在主库中该事务对应的时间戳是长什么样的。第三个问题： mysqlbinlog解析命令指定时间戳为'2019-07-29 17:20:00'，是否是碰到了FDE、Previous-GTIDs类型的event时间戳为190729 17:22:00时，发现不满足时间范围条件，直接跳过了解析后续的event？ "
* 对于这个问题，现在可以通过查看mysqlbinlog命令的源码结合gdb调试，确定是在哪个event退出的（也许不少人会说，mysqlbinlog就是在解析FDE、Previous-GTIDs类型的event时退出的，看起来好像的确是这样，但。。做技术要严谨，必须要有确凿的证据，所以，不建议在这个时候草率下定论）。

现在，我们从第二个问题开始着手，在主库中使用GTID字符串d9c5c228-b1e0-11e9-b14d-525400c33752:258161:518317解析主库binlog。

# 尴尬的是，不知道这两个GTID在主库的哪个binlog中，只能从第一个binlog开始，挨个向后解析主库binlog，并查看前50行中的Previous-GTIDs event中的GTID SET来判断，通过逐个解析binlog查看，发现我们需要寻找的两个GTID藏在主库的mysql-bin.000009 和mysql-bin.000010两个二进制日志文件中
# 解析mysql-bin.000009 文件
[root@node2 binlog]# mysqlbinlog mysql-bin.000009 |head -50  
......
'/*!*/;
# at 123
#190729 17:19:01 server id 33061 end_log_pos 194 CRC32 0xf53f1220 Previous-GTIDs
# d9c5c228-b1e0-11e9-b14d-525400c33752:1-214532
......
# 解析mysql-bin.000010文件
[root@node2 binlog]# mysqlbinlog mysql-bin.000010 |head -50
......
'/*!*/;
# at 123
#190729 17:20:41 server id 33061 end_log_pos 194 CRC32 0x27fe0eac Previous-GTIDs
# d9c5c228-b1e0-11e9-b14d-525400c33752:1-474622
# 解析mysql-bin.000011文件
[root@node2 binlog]# mysqlbinlog mysql-bin.000011 |head -50 
......
'/*!*/;
# at 123
#190729 17:22:17 server id 33061 end_log_pos 194 CRC32 0x1457abd9 Previous-GTIDs
# d9c5c228-b1e0-11e9-b14d-525400c33752:1-731105

在主库中，使用mysqlbinlog解析mysql-bin.000009 和mysql-bin.000010两个二进制日志文件，并指定GTID包含d9c5c228-b1e0-11e9-b14d-525400c33752:258161:518317

# 解析binlog
[root@node2 binlog]# mysqlbinlog mysql-bin.000009 mysql-bin.000010 --include-gtids='d9c5c228-b1e0-11e9-b14d-525400c33752:258161:518317' > c.sql
# 过滤出event事件类型的信息行
[root@node2 binlog]# grep -E 'server id|GTID_NEXT' c.sql > c.txt
# 查看一下c.sql和c.txt两个文件的大小
[root@node2 binlog]# ls -lh c.*
-rw-r--r-- 1 root root 102M Jul 29 18:16 c.sql
-rw-r--r-- 1 root root 3.3K Jul 29 18:18 c.txt
# vim查看c.txt文件中的内容
[root@node2 binlog]# vim c.txt 
#190729 17:19:01 server id 33061 end_log_pos 123 CRC32 0xfade248c Start: binlog v 4, server v 5.7.27-log created 190729 17:19:01
#190729 17:19:01 server id 33061 end_log_pos 194 CRC32 0xf53f1220 Previous-GTIDs
# GTID为 d9c5c228-b1e0-11e9-b14d-525400c33752:258161 的binlog event时间戳与从库中的binlog event时间戳完全相同
#190729 17:19:18 server id 33061 end_log_pos 88394786 CRC32 0x7a13b001 GTID last_committed=43590 sequence_number=43629 rbr_only=yes
SET @@SESSION.GTID_NEXT= 'd9c5c228-b1e0-11e9-b14d-525400c33752:258161'/*!*/;
#190729 17:19:18 server id 33061 end_log_pos 88394865 CRC32 0x1cb7f558 Query thread_id=364 exec_time=0 error_code=0
#190729 17:19:18 server id 33061 end_log_pos 88394989 CRC32 0xf07fac6f Table_map: `sbtest`.`sbtest1` mapped to number 115
#190729 17:19:18 server id 33061 end_log_pos 88395405 CRC32 0x8a0adc66 Update_rows: table id 115 flags: STMT_END_F
#190729 17:19:18 server id 33061 end_log_pos 88395524 CRC32 0x60282fdb Table_map: `sbtest`.`sbtest2` mapped to number 114
#190729 17:19:18 server id 33061 end_log_pos 88395749 CRC32 0xe041108a Delete_rows: table id 114 flags: STMT_END_F
#190729 17:19:18 server id 33061 end_log_pos 88396079 CRC32 0x1d8f8fd2 Table_map: `sbtest`.`sbtest2` mapped to number 114
#190729 17:19:18 server id 33061 end_log_pos 88396304 CRC32 0x704462b2 Write_rows: table id 114 flags: STMT_END_F
#190729 17:19:18 server id 33061 end_log_pos 88396335 CRC32 0xbf367aab Xid = 5087302
#190729 17:20:41 server id 33061 end_log_pos 536892835 CRC32 0x864ece23 Rotate to mysql-bin.000010 pos: 4
......
#190729 17:20:41 server id 33061 end_log_pos 123 CRC32 0x489dccb5 Start: binlog v 4, server v 5.7.27-log created 190729 17:20:41
#190729 17:20:41 server id 33061 end_log_pos 194 CRC32 0x27fe0eac Previous-GTIDs
# GTID为 d9c5c228-b1e0-11e9-b14d-525400c33752:518317 的binlog event时间戳仍然与从库中的binlog event时间戳完全相同
#190729 17:20:57 server id 33061 end_log_pos 91264585 CRC32 0xc7ea8f93 GTID last_committed=43656 sequence_number=43695 rbr_only=yes
SET @@SESSION.GTID_NEXT= 'd9c5c228-b1e0-11e9-b14d-525400c33752:518317'/*!*/;
#190729 17:20:57 server id 33061 end_log_pos 91264664 CRC32 0x7b4539d5 Query thread_id=360 exec_time=0 error_code=0
#190729 17:20:57 server id 33061 end_log_pos 91264788 CRC32 0xf11c5c66 Table_map: `sbtest`.`sbtest2` mapped to number 114
#190729 17:20:57 server id 33061 end_log_pos 91265204 CRC32 0x856ae255 Update_rows: table id 114 flags: STMT_END_F
#190729 17:20:57 server id 33061 end_log_pos 91265446 CRC32 0xdcd7ee6b Table_map: `sbtest`.`sbtest1` mapped to number 115
#190729 17:20:57 server id 33061 end_log_pos 91265862 CRC32 0x3a8a4aa2 Update_rows: table id 115 flags: STMT_END_F
#190729 17:20:57 server id 33061 end_log_pos 91265981 CRC32 0xf51f1fc2 Table_map: `sbtest`.`sbtest1` mapped to number 115
#190729 17:20:57 server id 33061 end_log_pos 91266206 CRC32 0xc52d3e94 Delete_rows: table id 115 flags: STMT_END_F
#190729 17:20:57 server id 33061 end_log_pos 91266536 CRC32 0xff5e2784 Table_map: `sbtest`.`sbtest1` mapped to number 115
#190729 17:20:57 server id 33061 end_log_pos 91266761 CRC32 0x708a7aaa Write_rows: table id 115 flags: STMT_END_F
#190729 17:20:57 server id 33061 end_log_pos 91266792 CRC32 0xcde1e798 Xid = 10289372
......

通过比对主从库的binlog中，这两个事务的binlog event时间戳，发现完全相同，说明从库的binlog中该事务的时间戳是来自主库binlog中该事务的原始时间戳（这些事务对应的event的时间戳，在复制拓扑中不会被其他数据库实例改变），但，为何从库的binlog file中的FDE、Previous-GTIDs时间戳会大于事务的event时间戳呢？难道从库存在延迟之后，从库自身的每个binlog都是这样的吗？带着疑问，在从库中继续往后解析mysql-bin.000011、mysql-bin.000012 ...

# 解析mysql-bin.000011
[root@node3 binlog]# mysqlbinlog mysql-bin.000011 |grep -E 'server id|GTID_NEXT' > d.txt
# vim查看d.txt文件内容，并没有发现FDE、Previous-GTIDs时间戳比事务的binlog event时间戳大的情况（WTF...，这是神马情况？）
[root@node3 binlog]# vim d.txt
#190729 17:20:57 server id 33062 end_log_pos 123 CRC32 0xa03c5bbc Start: binlog v 4, server v 5.7.27-log created 190729 17:20:57
#190729 17:20:57 server id 33062 end_log_pos 194 CRC32 0xfff79f0a Previous-GTIDs
#190729 17:20:57 server id 33061 end_log_pos 259 CRC32 0x37ef05b1 GTID last_committed=0 sequence_number=1 rbr_only=yes
SET @@SESSION.GTID_NEXT= 'd9c5c228-b1e0-11e9-b14d-525400c33752:518318'/*!*/;
#190729 17:20:57 server id 33061 end_log_pos 327 CRC32 0xe88d5be8 Query thread_id=332 exec_time=622 error_code=0
#190729 17:20:57 server id 33061 end_log_pos 451 CRC32 0x3f4748f8 Table_map: `sbtest`.`sbtest1` mapped to number 115
#190729 17:20:57 server id 33061 end_log_pos 867 CRC32 0x6cab4c30 Update_rows: table id 115 flags: STMT_END_F
#190729 17:20:57 server id 33061 end_log_pos 986 CRC32 0x8f8db6cc Table_map: `sbtest`.`sbtest1` mapped to number 115
#190729 17:20:57 server id 33061 end_log_pos 1211 CRC32 0x49418317 Delete_rows: table id 115 flags: STMT_END_F
#190729 17:20:57 server id 33061 end_log_pos 1541 CRC32 0x6faf4972 Table_map: `sbtest`.`sbtest1` mapped to number 115
#190729 17:20:57 server id 33061 end_log_pos 1766 CRC32 0x35b274e6 Write_rows: table id 115 flags: STMT_END_F
#190729 17:20:57 server id 33061 end_log_pos 1797 CRC32 0x70757956 Xid = 2284921
......
#190729 17:22:34 server id 33062 end_log_pos 536885932 CRC32 0xe8e5a7b3 Rotate to mysql-bin.000012 pos: 4
# 继续解析mysql-bin.000012
[root@node3 binlog]# mysqlbinlog mysql-bin.000012 |grep -E 'server id|GTID_NEXT' > e.txt 
# vim查看e.txt文件内容，仍然没有发现FDE、Previous-GTIDs时间戳比事务的binlog event时间戳大的情况
[root@node3 binlog]# vim e.txt
#190729 17:22:34 server id 33062 end_log_pos 123 CRC32 0x55c719a6 Start: binlog v 4, server v 5.7.27-log created 190729 17:22:34
#190729 17:22:34 server id 33062 end_log_pos 194 CRC32 0x246c1b20 Previous-GTIDs
#190729 17:22:34 server id 33061 end_log_pos 259 CRC32 0x5dbbac77 GTID last_committed=0 sequence_number=1 rbr_only=yes
SET @@SESSION.GTID_NEXT= 'd9c5c228-b1e0-11e9-b14d-525400c33752:776005'/*!*/;
#190729 17:22:34 server id 33061 end_log_pos 327 CRC32 0x86ca88e5 Query thread_id=331 exec_time=593 error_code=0
#190729 17:22:34 server id 33061 end_log_pos 451 CRC32 0xc2c13e95 Table_map: `sbtest`.`sbtest1` mapped to number 115
#190729 17:22:34 server id 33061 end_log_pos 867 CRC32 0xd95ec374 Update_rows: table id 115 flags: STMT_END_F
#190729 17:22:34 server id 33061 end_log_pos 1109 CRC32 0xc698d4ca Table_map: `sbtest`.`sbtest1` mapped to number 115
#190729 17:22:34 server id 33061 end_log_pos 1525 CRC32 0x893ec0b8 Update_rows: table id 115 flags: STMT_END_F
#190729 17:22:34 server id 33061 end_log_pos 1644 CRC32 0x503ef822 Table_map: `sbtest`.`sbtest1` mapped to number 115
#190729 17:22:34 server id 33061 end_log_pos 1869 CRC32 0x56078d13 Delete_rows: table id 115 flags: STMT_END_F
#190729 17:22:34 server id 33061 end_log_pos 2199 CRC32 0xb134e795 Table_map: `sbtest`.`sbtest1` mapped to number 115
#190729 17:22:34 server id 33061 end_log_pos 2424 CRC32 0x0bf4a350 Write_rows: table id 115 flags: STMT_END_F
#190729 17:22:34 server id 33061 end_log_pos 2455 CRC32 0x4d065250 Xid = 3484259
......
#190729 17:24:12 server id 33062 end_log_pos 536888910 CRC32 0x029b5df4 Rotate to mysql-bin.000013 pos: 4

为毛从库的mysql-bin.000010文件中的event时间顺序有问题？而后续所有的binlog文件中的时间戳都没有问题？他们之间有哪里不同？想来想去，好像想起了，mysql-bin.000010是手动执行flush binary logs语句做切换时生成的，而后续的其他binlog文件，是自动切换的，自动切换怎么切换？当binlog大小达到max_binlog_size系统变量的设置，就会触发自动切换，我们在从库中查看一下binlog文件的大小以及max_binlog_size系统变量的设置。

# max_binlog_size系统变量的设置
root@localhost : (none) 06:56:20> show variables like '%max_binlog_size%';
+-----------------+-----------+
| Variable_name | Value |
+-----------------+-----------+
| max_binlog_size | 536870912 |  # 转换为M单位就是512M
+-----------------+-----------+
1 row in set (0.00 sec)
# 查看binlog文件的大小
[root@node3 binlog]# ls -lh                                                                                                                                                                                                                   
total 9.4G
......
-rw-r----- 1 mysql mysql 176615208 Jul 29 17:22 mysql-bin.000009  # 在mysql-bin.000009的时候执行了flush binary logs切换到了mysql-bin.000010 ，所以mysql-bin.000009的文件大小小很多
-rw-r----- 1 mysql mysql 536903179 Jul 29 17:31 mysql-bin.000010  # 转换为M单位就是512M，刚好达到max_binlog_size系统变量的设置
-rw-r----- 1 mysql mysql 536885932 Jul 29 17:32 mysql-bin.000011
-rw-r----- 1 mysql mysql 536888910 Jul 29 17:33 mysql-bin.000012
-rw-r----- 1 mysql mysql 536887458 Jul 29 17:34 mysql-bin.000013
-rw-r----- 1 mysql mysql 536888575 Jul 29 17:35 mysql-bin.000014
-rw-r----- 1 mysql mysql 536903940 Jul 29 17:37 mysql-bin.000015
-rw-r----- 1 mysql mysql 491243565 Jul 29 18:14 mysql-bin.000016
-rw-r----- 1 mysql mysql 832 Jul 29 17:37 mysql-bin.index

至此，我们离真相更进一步了，知道了从库中binlog文件 mysql-bin.000010 中的时间戳乱序是因为手动执行了flush binary logs语句切换日志导致的，而其他的binlog是自动触发滚动生成的就没有这个问题。但是。。还是比较迷糊，这两种方式产生的binlog中的FDE、Previous-GTIDs时间戳一定有蹊跷，如果要直接去找出在两种情况下各自获取时间戳的时机可能就比较复杂，这里我们采用了反证法，在复制存在延迟的情况下，先在从库中把复制线程停掉并执行flush binary logs; 发现FDE、Previous-GTIDs时间戳是从库实例的当前时间戳，然后，在从库中重新启动复制线程，让从库的binlog文件大小达到max_binlog_size系统变量的设置时自动切换，发现FDE、Previous-GTIDs时间戳是来自上一个binlog文件中最后一个事务对应的event的时间戳（即，自动切换的binlog中的FDE、Previous-GTIDs时间戳是跟随主库binlog event的，整个binlog中的event时间戳不会出现乱序，在使用mysqlbinlog解析binlog时就不可能出现无法解析事务对应的event的问题），有兴趣的同学可自行验证，这里不再赘述。

第二个问题到这里就已经解决了，现在，我们来解决第三个问题，怎么解决呢？翻看源码，做gdb调试，我们临时邀请了一位神秘友人相助（文末也提供了这位神秘友人相关文档的参考链接），下面是mysqlbinlog命令退出位置的关键证据。 FDE、Previous-GTIDs时间戳为190825 0:01:37，数据的event时间戳为190724 14:07:36，mysqlbinlog解析binlog时指定--stop-datetime时间为2019-07-25 00:00:00（友情提示：该图中的数据是这位神秘友人的环境，与本文上下文中的数据不对应）。

源码文件mysqlbinlog.cc中处理时间戳的逻辑代码如下。

调试测试数据的binlog中的event数据如下。

执行mysqlbinlog解析的命令如下。

gdb调试信息如下，可以直观地看到，在处理FORMAT_DESCRIPTION_EVENT（FDE）的event时，直接goto end退出了。

现在，第三个问题也解决了，还剩下第一个问题：复制延迟与基于时间点恢复数据不正确有啥关系？我们解决了第二个问题和第三个问题，第一个问题似乎答案也呼之欲出，我们来复盘整理一下上文中的信息。

我们在sysbench压测过程中，先停止了SQL线程，然后手工执行了flush binary logs语句切换binlog，此时切换后的binlog文件名为mysql-bin.000010，该binlog中的FDE、Previous-GTIDs时间戳是从库的当前时间戳（190729 17:22:00），此时，SQL线程未启动，也就是说不会应用relay log中来自主库的binlog，也就是说从库自身的binlog中不会写入任何数据event。
然后，过了10分钟左右，我们启动了SQL线程，开始应用来自主库的binlog，写入mysql-bin.000010文件中第一个事务相关的event时间戳为190729 17:19:18（它是来自主库写入binlog时的时间戳，不会因为从库做任何操作而改变），也就是说，此时mysql-bin.000010中的event时间戳就处于一个乱序的状态了。
然后，使用mysqlbinlog解析binlog时，指定了--stop-datetime时间戳为2019-07-29 17:20:00，该时间小于FDE、Previous-GTIDs时间戳190729 17:22:00，根据上文中gdb调试的逻辑判断，指定的时间戳小于了FDE的时间戳，不满足条件，不再往后扫描（即使后续的数据event的时间戳为190729 17:19:18，满足小于mysqlbinlog指定的时间戳也无济于事），mysqlbinlog命令退出解析任务。

至此，第三个问题也得到了解决。

导致基于时间点恢复数据不正确的原因是：在从库存在复制延迟的情况下，手工执行了flush binary logs语句切换binlog（这里要注意：从库存在复制延迟的情况下，如果重启从库数据库进程，binlog中的时间戳仍然会乱序），导致了binlog文件中的时间戳乱序，然后，mysqlbinlog工具指定了一个尴尬的时间戳（卡在了小于FDE、Previous-GTIDs的时间戳，但大于数据event的时间戳的范围内），导致解析任务退出，无法正确解析数据的event。

PS：到这里，我们通过上述一系列的分析排查步骤，已经找出了导致从库binlog中的时间戳乱序的2个直接原因。

手工执行flush bianry logs语句。
重启从库数据库进程。

4、问题追踪

此时此刻，是不是就可以收工交作业了呢？如果是纯技术研究，嗯，到此收工应该问题不大，但，这不是单纯的技术问题，而是一个由客户现场发现的实际问题，需要找出在实际环境中哪里执行了flush语句或者重启了从库数据库进程，并研究预防策略。因此，我们需要与客户现场做二次确认。经再次确认，并没有手工执行flush binary logs语句，执行过一两次重启从库进程的操作，但，重启的一两次操作对于5%~10%的问题现象概率来说显然不匹配，其中一定有蹊跷，一定是哪里手动执行了flush binary logs;语句，但到此时，可被怀疑的因素已经不多了。实在要说哪里还可以被怀疑，首当其冲的应该就是数据库的管理系统的代码。于是，向相关的研发人员反馈，建议在代码中查看是否有执行flush binary logs或者flush logs语句，以及是否做了一些不必要的重启从库进程的操作。第二天，他们果然在代码中找到了在对数据卷打快照时，加全局读锁之后有一个flush logs语句，对于数据库实现基于时间点恢复数据的功能逻辑来说，这个操作完全没必要，可以删除flush语句。但是，这里是否可以立即建议研发将管理系统代码中的flush语句删除就完事了呢？作为一个严谨的技术从业人员，不应该有意无意忽略潜在的风险点。你应该建议研发人员去追查代码提交信息，看看是什么时候提交的，谁提交的，然后，确认为什么会添加这个操作，然后再来评估是否需要删除flush语句相关的代码。大约又过了一天，研发的小伙伴们惊奇地发现flush语句相关的代码是3.5年前提交的，提交注释上说只是为了实现打一个快照的功能，但已经没有人知道当初为何添加这个flush操作。那怎么办？我们最后建议研发删除flush语句相关的代码，然后，整个管理系统走一遍常规的功能测试，然后，再走一遍重压测试，等到所有测试走完，直到不再出现"基于时间点恢复数据"无法正确恢复数据的问题，且没有其他新的问题产生。然后，建议客户，除非必须，否则不要随意在从库中执行flush语句，不要随意重启从库，否则可能会造成什么影响等巴拉巴拉巴拉。。。这时，你就可以出具相关报告文档交作业了。

参考链接：

重庆八怪（高鹏）： https://www.jianshu.com/p/ba37faa3022a

作者简介

罗小波·沃趣科技高级数据库技术专家

IT从业多年，主要负责MySQL 产品的数据库支撑与售后二线支撑。曾参与版本发布系统、轻量级监控系统、运维管理平台、数据库管理平台的设计与编写，熟悉MySQL体系结构，Innodb存储引擎，喜好专研开源技术，多次在公开场合做过线下线上数据库专题分享，发表过多篇数据库相关的研究文章。

来自 “ ITPUB博客 ” ，链接：http://blog.itpub.net/28218939/viewspace-2652553/，如需转载，请注明出处，否则将追究法律责任。

转载于:http://blog.itpub.net/28218939/viewspace-2652553/

你可能感兴趣的:(MySQL binlog基于时间点恢复数据失败是什么鬼？)

关于沟通这件事，项目经理不需要每次都面对面进行流程大师兄
很多项目经理都会遇到这样的问题，项目中由于事情太多，根本没有足够的时间去召开会议，那在这种情况下如何去有效地管理项目中的利益相关者？当然，不建议电子邮件也不需要开会的话，建议可以采取下面几种方式来形成有效的沟通，这几种方式可以帮助你努力的通过各种办法来保持和各方面的联系。项目经理首先要问自己几个问题，项目中哪些利益相关者是必须要进行沟通的？可以列出项目中所有的利益相关者清单，同时也整理出项目中哪些
2020-01-25 晴岚85
郑海燕坚持分享590天2020.1.24在生活中只存在两个问题。一个问题是：你知道想要达成的目标是什么，但却不知道如何才能达成；另一个问题是：你不知道你的目标是什么。前一个是行动的问题，后一个是结果的问题。通过制定具体的下一步行动，可以解决不知道如何开始行动的问题。而通过去想象结果，对结果做预估，可以解决找不着目标的问题。对于所有吸引我们注意力，想要完成的任务，你可以先想象一下，预期的结果究竟是什
LocalDateTime 转 String igotyback java 开发语言
importjava.time.LocalDateTime;importjava.time.format.DateTimeFormatter;publicclassMain{publicstaticvoidmain(String[]args){//获取当前时间LocalDateTimenow=LocalDateTime.now();//定义日期格式化器DateTimeFormatterformat
mysql禁用远程登录 igotyback mysql
去mysql库中的user表里，将host都改成localhost之后刷新权限FLUSHPRIVILEGES;
如何在 Fork 的 GitHub 项目中保留自己的修改并同步上游更新？github_fork_update iBaoxing github
如何在Fork的GitHub项目中保留自己的修改并同步上游更新？在GitHub上Fork了一个项目后，你可能会对项目进行一些修改，同时原作者也在不断更新。如果想要在保留自己修改的基础上，同步原作者的最新更新，很多人会不知所措。本文将详细讲解如何在不丢失自己改动的情况下，将上游仓库的更新合并到自己的仓库中。问题描述假设你在GitHub上Fork了一个项目，并基于该项目做了一些修改，随后你发现原作者对
扫地机类清洁产品之直流无刷电机控制悟空胆好小清洁服务机器人单片机人工智能
扫地机类清洁产品之直流无刷电机控制1.1前言扫地机产品有很多的电机控制，滚刷电机1个，边刷电机1-2个，清水泵电机，风机一个，部分中高端产品支持抹布功能，也就是存在抹布盘电机，还有追觅科沃斯石头等边刷抬升电机，滚刷抬升电机等的，这些电机有直流有刷电机，直接无刷电机，步进电机，电磁阀，挪动泵等不同类型。电机的原理，驱动控制方式也不行。接下来一段时间的几个文章会作个专题分析分享。直流有刷电机会自动持续
抖音乐买买怎么加入赚钱?赚钱方法是什么测评君高省
你会在抖音买东西吗?如果会，那么一定要免费注册一个乐买买，抖音直播间，橱窗，小视频里的小黄车买东西都可以返佣金!省下来都是自己的，分享还可以赚钱乐买买是好省旗下的抖音返佣平台，乐买买分析社交电商的价值，乐买买属于今年难得的副业项目风口机会，2019年错过做好省的搞钱的黄金时期，那么2022年千万别再错过乐买买至于我为何转到高省呢？当然是高省APP佣金更高，模式更好，终端用户不流失。【高省】是一个自
开心蒋泳频
从无比抗拒来上课到接受，感动，收获～看着波哥成长，晶晶幸福笑容满面。感觉自己做的事情很有意义，很开心！还有3个感召目标就是还有三个有缘人，哈哈。明天感召去明日计划：8：30-11：00小公益11：00-21点上班，感召图片发自App图片发自App图片发自App
《庄子.达生9》钱江潮369
【原文】孔子观于吕梁，县水三十仞，流沫四十里，鼋鼍鱼鳖之所不能游也。见一丈夫游之，以为有苦而欲死也，使弟子并流而拯之。数百步而出，被发行歌而游于塘下。孔子从而问焉，曰：“吾以子为鬼，察子则人也。请问，‘蹈水有道乎’”曰：“亡，吾无道。吾始乎故，长乎性，成乎命。与齐俱入，与汩偕出，从水之道而不为私焉。此吾所以蹈之也。”孔子曰：“何谓始乎故，长乎性，成乎命？”曰：“吾生于陵而安于陵，故也；长于水而安于
腾讯云技术深度探索：构建高效云原生微服务架构我的运维人生云原生架构腾讯云运维开发技术共享
腾讯云技术深度探索：构建高效云原生微服务架构在当今快速发展的技术环境中，云原生技术已成为企业数字化转型的关键驱动力。腾讯云作为行业领先的云服务提供商，不断推出创新的产品和技术，助力企业构建高效、可扩展的云原生微服务架构。本文将深入探讨腾讯云在微服务领域的最新进展，并通过一个实际案例展示如何在腾讯云平台上构建云原生应用。腾讯云微服务架构概览腾讯云微服务架构基于云原生理念，旨在帮助企业快速实现应用的容
Pyecharts数据可视化大屏：打造沉浸式数据分析体验我的运维人生信息可视化数据分析数据挖掘运维开发技术共享
Pyecharts数据可视化大屏：打造沉浸式数据分析体验在当今这个数据驱动的时代，如何将海量数据以直观、生动的方式展现出来，成为了数据分析师和企业决策者关注的焦点。Pyecharts，作为一款基于Python的开源数据可视化库，凭借其丰富的图表类型、灵活的配置选项以及高度的定制化能力，成为了构建数据可视化大屏的理想选择。本文将深入探讨如何利用Pyecharts打造数据可视化大屏，并通过实际代码案例
Google earth studio 简介陟彼高冈yu 旅游
GoogleEarthStudio是一个基于Web的动画工具，专为创作使用GoogleEarth数据的动画和视频而设计。它利用了GoogleEarth强大的三维地图和卫星影像数据库，使用户能够轻松地创建逼真的地球动画、航拍视频和动态地图可视化。网址为https://www.google.com/earth/studio/。GoogleEarthStudio是一个基于Web的动画工具，专为创作使用G
相信相信的力量孙丽_cdb3
孙丽中级十期坚持分享第345天有一个特别有哲理的故事：有一只老鹰下了蛋，这个蛋，不知怎的就滚到了鸡窝里去了，鸡也下了一窝蛋，然后鸡妈妈把这些蛋全都浮出来了，孵出来之后等小鸡长大一点了，就觉得鹰蛋孵出来的那只小鹰怪模怪样，这些小鸡都嘲笑它，真难看，真笨，丑死了，那只小鹰觉得自己真是谁也不像，真是不好看，后来鸡妈妈也不喜欢他，我怎么生出你这样的孩子来了？真烦人，后来这群小鸡和小鹰一起生活，有一天，老鹰
linux中sdl的使用教程,sdl使用入门 Melissa Corvinus linux中sdl的使用教程
本文通过一个简单示例讲解SDL的基本使用流程。示例中展示一个窗口，窗口里面有个随机颜色快随机移动。当我们鼠标点击关闭按钮时间窗口关闭。基本步骤如下：1.初始化SDL并创建一个窗口。SDL_Init()初始化SDL_CreateWindow()创建窗口2.纹理渲染存储RGB和存储纹理的区别：比如一个从左到右由红色渐变到蓝色的矩形，用存储RGB的话就需要把矩形中每个点的具体颜色值存储下来；而纹理只是一
LLM 词汇表落难Coder LLMs NLP 大语言模型大模型 llama 人工智能
Contextwindow“上下文窗口”是指语言模型在生成新文本时能够回溯和参考的文本量。这不同于语言模型训练时所使用的大量数据集，而是代表了模型的“工作记忆”。较大的上下文窗口可以让模型理解和响应更复杂和更长的提示，而较小的上下文窗口可能会限制模型处理较长提示或在长时间对话中保持连贯性的能力。Fine-tuning微调是使用额外的数据进一步训练预训练语言模型的过程。这使得模型开始表示和模仿微调数
基于社交网络算法优化的二维最大熵图像分割智能算法研学社（Jack旭）智能优化算法应用图像分割算法 php 开发语言
智能优化算法应用：基于社交网络优化的二维最大熵图像阈值分割-附代码文章目录智能优化算法应用：基于社交网络优化的二维最大熵图像阈值分割-附代码1.前言2.二维最大熵阈值分割原理3.基于社交网络优化的多阈值分割4.算法结果：5.参考文献：6.Matlab代码摘要：本文介绍基于最大熵的图像分割，并且应用社交网络算法进行阈值寻优。1.前言阅读此文章前，请阅读《图像分割：直方图区域划分及信息统计介绍》htt
509. 斐波那契数(每日一题) lzyprime
lzyprime博客(github)创建时间：2021.01.04qq及邮箱：2383518170leetcode笔记题目描述斐波那契数，通常用F(n)表示，形成的序列称为斐波那契数列。该数列由0和1开始，后面的每一项数字都是前面两项数字的和。也就是：F(0)=0，F(1)=1F(n)=F(n-1)+F(n-2)，其中n>1给你n，请计算F(n)。示例1：输入：2输出：1解释：F(2)=F(1)+
今又重阳芮峻
今又重阳图片发自App白露成霜菊花黄，岁岁重阳，今又重阳。登高远望，君不见，那来时路上少年，青丝已染雪霜。落日一点一点西坠，谁有力量，托住使其回往。转眼缺了大半，又能怎样？江天两茫茫。给我一壶烈酒，我要敬那斜阳，看谁先醉？笑指西天红了一片，借点酒力，老夫聊发一次少年狂。老严.2019年重阳节.杭州
2020.11.19 隆非凡
日精进，今日体验：在维修过程中遇到的问题，把源头找到，在进行下一步开始。不要停留在一个点上，合理调整心态，把当下事做好。
关于提高复杂业务逻辑代码可读性的思考编程经验分享开发经验 java 数据库开发语言
目录前言需求场景常规写法拆分方法领域对象总结前言实际工作中大部分时间都是在写业务逻辑，一般都是三层架构，表示层（Controller）接收客户端请求，并对入参做检验，业务逻辑层（Service）负责处理业务逻辑，一般开发都是在这一层中写具体的业务逻辑。数据访问层（Dao）是直接和数据库交互的，用于查数据给业务逻辑层，或者是将业务逻辑层处理后的数据写入数据库。简单的增删改查接口不用多说，基本上写好一
18-115 一切思考不能有效转化为行动，都TM是扯淡！成长时间线
7月25号写了一篇关于为什么会断更如此严重的反思，然而，之后日更仅仅维持了一周，又出现了这次更严重的现象。从8月2号到昨天8月6号，5天！又是5天没有更文！虽然这次断更时间和上次一样，那为什么说这次更严重？因为上次之后就分析了问题的原因，以及应该如何解决，按理说应该会好转，然而，没过几天严重断更的现象再次出现，想想，经过反思，问题依然没有解决与改变，这让我有些担忧。到底是哪里出了问题，难道我就真的
郎朗大婚娶公主：所有光环的背后，都是十年如一日的自律简小尘
近日，关于郎朗大婚的新闻上了热搜，看了新娘的照片，既有天使般的面容，更有魔鬼般的身材，关键是人家还身世好，又有才华，这真的是让所有男人羡慕嫉妒恨哪。有些人不禁会想，“凭什么郎朗的人生就象开挂了一样，可我却每天都活得这么狼狈！”其实，每个开挂的人生背后，都是苦行僧般的自律。01欲戴王冠，必承其重。练琴不能只靠兴趣，更需要自律！我们先来看一下朗朗在小时候的作息时间表：早晨5:45起床，练琴1小时。中午
四章-32-点要素的聚合彩云飘过
本文基于腾讯课堂老胡的课《跟我学Openlayers--基础实例详解》做的学习笔记，使用的openlayers5.3.xapi。源码见1032.html，对应的官网示例https://openlayers.org/en/latest/examples/cluster.htmlhttps://openlayers.org/en/latest/examples/earthquake-clusters.
《人世间》南询yi
今日分享十点推文，《人世间》有感苏格拉底说：“天地只有三尺，而人在五尺开外，所以人人都要懂得低头。”深以为然。懂得低头，不是认输。而是于人世间找寻温存的成熟，于困境中寻觅柳暗花明的智慧，于争执中展示屈伸自如的格局。正如仰头不是骄傲，是要看见自己的天空；低头也不是认输，而是要看清自己的路。成大事者，不仅要抬头挺胸，还得低头看路。懂得低头，进退有度，不是认输，而是竭尽全力过好这一生。宫崎骏说过：“所有
【华为OD机试真题2023B卷 JAVA&JS】We Are A Team 若博豆 java 算法华为 javascript
华为OD2023（B卷）机试题库全覆盖，刷题指南点这里WeAreATeam时间限制：1秒|内存限制：32768K|语言限制：不限题目描述：总共有n个人在机房，每个人有一个标号（1<=标号<=n），他们分成了多个团队，需要你根据收到的m条消息判定指定的两个人是否在一个团队中，具体的：1、消息构成为：abc，整数a、b分别代
少了生活气息我爱大草莓
最近啊，总觉得自己日更的内容缺了点什么。我仔细地想，大概是少了些生活气息。这两三个月减少了许多与别人相处的时间，独自生活，偶尔只是出去买菜，总觉得生活好像变空了许多。买菜的时候会跟档口的阿姨聊一两句话，让自己感觉在真实地生活着。幸好我也不是一宅到底，偶尔周末也会约着跟好朋友见面，面对面交流跟隔着屏幕交流，效果还是不一样的，至少有更为真实的生活感。写作不仅需要有阅读量，有文笔，生活阅历也是非常重要的
398顺境，逆境戴骁勇
2018.11.27周二雾霾最近儿子进入了一段顺境期，今天表现尤其不错。今天的数学测试成绩喜人，没有出现以往的计算错误，整个卷面书写工整，附加题也在规定时间内完成且做对。为迎接体育测试的锻炼有了质的飞跃。坐位体前屈成绩突飞猛进，估测成绩能达到12cm，这和上次测试的零分来比，简直是逆袭。儿子还在不断锻炼和提升，唯恐到时候掉链子。跑步姿势在我的调教下，逐渐正规起来，速度随之也有了提升。今晚测试的50
从0到500+，我是如何利用自媒体赚钱？一列脚印
运营公众号半个多月，从零基础的小白到现在慢慢懂了一些运营的知识。做好公众号是很不容易的，要做很多事情；排版、码字、引流…通通需要自己解决，业余时间全都花费在这上面涨这么多粉丝是真的不容易，对比知乎大佬来说，我们这种没资源，没人脉，还没钱的小透明来说，想要一个月涨粉上万，怕是今天没睡醒（不过你有的方法，算我piapia打脸）至少我是清醒的，自己慢慢努力，实现我的万粉目标！大家快来围观、支持我吧！孩子
python是什么意思中文-在python中%是什么意思编程大乐趣
Python中%有两种：1、数值运算：%代表取模，返回除法的余数。如：>>>7%212、%操作符（字符串格式化，stringformatting），说明如下：%[(name)][flags][width].[precision]typecode(name)为命名flags可以有+，-，''或0。+表示右对齐。-表示左对齐。''为一个空格，表示在正数的左侧填充一个空格，从而与负数对齐。0表示使用0填
使用Apify加载Twitter消息以进行微调的完整指南 nseejrukjhad twitter easyui 前端 python
#使用Apify加载Twitter消息以进行微调的完整指南##引言在自然语言处理领域，微调模型以适应特定任务是提升模型性能的常见方法。本文将介绍如何使用Apify从Twitter导出聊天信息，以便进一步进行微调。##主要内容###使用Apify导出推文首先，我们需要从Twitter导出推文。Apify可以帮助我们做到这一点。通过Apify的强大功能，我们可以批量抓取和导出数据，适用于各类应用场景。
二分查找排序算法周凡杨 java 二分查找排序算法折半
一：概念二分查找又称折半查找（折半搜索/ 二分搜索），优点是比较次数少，查找速度快，平均性能好；其缺点是要求待查表为有序表，且插入删除困难。因此，折半查找方法适用于不经常变动而查找频繁的有序列表。首先，假设表中元素是按升序排列，将表中间位置记录的关键字与查找关键字比较，如果两者相等，则查找成功；否则利用中间位置记录将表分成前、后两个子表，如果中间位置记录的关键字大于查找关键字，则进一步
java中的BigDecimal bijian1013 java BigDecimal
在项目开发过程中出现精度丢失问题，查资料用BigDecimal解决，并发现如下这篇BigDecimal的解决问题的思路和方法很值得学习，特转载。原文地址：http://blog.csdn.net/ugg/article/de
Shell echo命令详解 daizj echo shell
Shell echo命令 Shell 的 echo 指令与 PHP 的 echo 指令类似，都是用于字符串的输出。命令格式： echo string 您可以使用echo实现更复杂的输出格式控制。 1.显示普通字符串: echo "It is a test" 这里的双引号完全可以省略，以下命令与上面实例效果一致： echo Itis a test 2.显示转义
Oracle DBA 简单操作周凡杨 oracle dba sql
--执行次数多的SQL select sql_text,executions from ( select sql_text,executions from v$sqlarea order by executions desc ) where rownum<81; &nb
画图重绘朱辉辉33 游戏
我第一次接触重绘是编写五子棋小游戏的时候，因为游戏里的棋盘是用线绘制的，而这些东西并不在系统自带的重绘里，所以在移动窗体时，棋盘并不会重绘出来。所以我们要重写系统的重绘方法。在重写系统重绘方法时，我们要注意一定要调用父类的重绘方法，即加上super.paint(g)，因为如果不调用父类的重绘方式，重写后会把父类的重绘覆盖掉，而父类的重绘方法是绘制画布，这样就导致我们
线程之初体验西蜀石兰线程
一直觉得多线程是学Java的一个分水岭，懂多线程才算入门。之前看《编程思想》的多线程章节，看的云里雾里，知道线程类有哪几个方法，却依旧不知道线程到底是什么？书上都写线程是进程的模块，共享线程的资源，可是这跟多线程编程有毛线的关系，呜呜。。。线程其实也是用户自定义的任务，不要过多的强调线程的属性，而忽略了线程最基本的属性。你可以在线程类的run()方法中定义自己的任务，就跟正常的Ja
linux集群互相免登陆配置林鹤霄 linux
配置ssh免登陆 1、生成秘钥和公钥 ssh-keygen -t rsa 2、提示让你输入，什么都不输，三次回车之后会在~下面的.ssh文件夹中多出两个文件id_rsa 和 id_rsa.pub 其中id_rsa为秘钥，id_rsa.pub为公钥，使用公钥加密的数据只有私钥才能对这些数据解密 c
mysql : Lock wait timeout exceeded; try restarting transaction aigo mysql
原文：http://www.cnblogs.com/freeliver54/archive/2010/09/30/1839042.html 原因是你使用的InnoDB 表类型的时候, 默认参数:innodb_lock_wait_timeout设置锁等待的时间是50s, 因为有的锁等待超过了这个时间,所以抱错. 你可以把这个时间加长,或者优化存储
Socket编程基本的聊天实现。 alleni123 socket
public class Server { //用来存储所有连接上来的客户 private List<ServerThread> clients; public static void main(String[] args) { Server s = new Server(); s.startServer(9988); } publi
多线程监听器事件模式(一个简单的例子) 百合不是茶线程监听模式
多线程的事件监听器模式监听器时间模式经常与多线程使用,在多线程中如何知道我的线程正在执行那什么内容,可以通过时间监听器模式得到创建多线程的事件监听器模式思路: 1, 创建线程并启动,在创建线程的位置设置一个标记 2,创建队
spring InitializingBean接口 bijian1013 java spring
spring的事务的TransactionTemplate，其源码如下： public class TransactionTemplate extends DefaultTransactionDefinition implements TransactionOperations, InitializingBean{ ... } TransactionTemplate继承了DefaultT
Oracle中询表的权限被授予给了哪些用户 bijian1013 oracle 数据库权限
Oracle查询表将权限赋给了哪些用户的SQL，以备查用。 select t.table_name as "表名", t.grantee as "被授权的属组", t.owner as "对象所在的属组"
【Struts2五】Struts2 参数传值 bit1129 struts2
Struts2中参数传值的3种情况 1.请求参数绑定到Action的实例字段上 2.Action将值传递到转发的视图上 3.Action将值传递到重定向的视图上一、请求参数绑定到Action的实例字段上以及Action将值传递到转发的视图上 Struts可以自动将请求URL中的请求参数或者表单提交的参数绑定到Action定义的实例字段上，绑定的规则使用ognl表达式语言
【Kafka十四】关于auto.offset.reset[Q/A] bit1129 kafka
I got serveral questions about auto.offset.reset. This configuration parameter governs how consumer read the message from Kafka when there is no initial offset in ZooKeeper or
nginx gzip压缩配置 ronin47 nginx gzip 压缩范例
nginx gzip压缩配置更多 0 nginx gzip 配置随着nginx的发展，越来越多的网站使用nginx，因此nginx的优化变得越来越重要，今天我们来看看nginx的gzip压缩到底是怎么压缩的呢？ gzip(GNU-ZIP)是一种压缩技术。经过gzip压缩后页面大小可以变为原来的30%甚至更小，这样，用
java-13.输入一个单向链表，输出该链表中倒数第 k 个节点 bylijinnan java
two cursors. Make the first cursor go K steps first. /* * 第 13 题：题目：输入一个单向链表，输出该链表中倒数第 k 个节点 */ public void displayKthItemsBackWard(ListNode head,int k){ ListNode p1=head,p2=head;
Spring源码学习-JdbcTemplate queryForObject bylijinnan java spring
JdbcTemplate中有两个可能会混淆的queryForObject方法： 1. Object queryForObject(String sql, Object[] args, Class requiredType) 2. Object queryForObject(String sql, Object[] args, RowMapper rowMapper) 第1个方法是只查
[冰川时代]在冰川时代,我们需要什么样的技术? comsci 技术
看美国那边的气候情况....我有个感觉...是不是要进入小冰期了? 那么在小冰期里面...我们的户外活动肯定会出现很多问题...在室内呆着的情况会非常多...怎么在室内呆着而不发闷...怎么用最低的电力保证室内的温度.....这都需要技术手段... &nb
js 获取浏览器型号 cuityang js 浏览器
根据浏览器获取iphone和apk的下载地址 <!DOCTYPE html> <html> <head> <meta charset="utf-8" content="text/html"/> <meta name=
C# socks5详解转 dalan_123 socket C#
http://www.cnblogs.com/zhujiechang/archive/2008/10/21/1316308.html 这里主要讲的是用.NET实现基于Socket5下面的代理协议进行客户端的通讯，Socket4的实现是类似的，注意的事，这里不是讲用C#实现一个代理服务器，因为实现一个代理服务器需要实现很多协议，头大，而且现在市面上有很多现成的代理服务器用，性能又好，
运维 Centos问题汇总 dcj3sjt126com 云主机
一、sh 脚本不执行的原因 sh脚本不执行的原因只有2个 1.权限不够 2.sh脚本里路径没写完整。二、解决You have new mail in /var/spool/mail/root 修改/usr/share/logwatch/default.conf/logwatch.conf配置文件 MailTo = MailFrom 三、查询连接数
Yii防注入攻击笔记 dcj3sjt126com sql WEB安全 yii
网站表单有注入漏洞须对所有用户输入的内容进行个过滤和检查，可以使用正则表达式或者直接输入字符判断，大部分是只允许输入字母和数字的，其它字符度不允许；对于内容复杂表单的内容，应该对html和script的符号进行转义替换：尤其是<,>,',"",&这几个符号这里有个转义对照表： http://blog.csdn.net/xinzhu1990/articl
MongoDB简介[一] eksliang mongodb MongoDB简介
MongoDB简介转载请出自出处：http://eksliang.iteye.com/blog/2173288 1.1易于使用 MongoDB是一个面向文档的数据库，而不是关系型数据库。与关系型数据库相比，面向文档的数据库不再有行的概念，取而代之的是更为灵活的“文档”模型。另外，不
zookeeper windows 入门安装和测试 greemranqq zookeeper 安装分布式
一、序言以下是我对zookeeper 的一些理解： zookeeper 作为一个服务注册信息存储的管理工具，好吧，这样说得很抽象，我们举个“栗子”。栗子1号：假设我是一家KTV的老板，我同时拥有5家KTV，我肯定得时刻监视
Spring之使用事务缘由(2-注解实现) ihuning spring
Spring事务注解实现 1. 依赖包： 1.1 spring包： spring-beans-4.0.0.RELEASE.jar spring-context-4.0.0.
iOS App Launch Option 啸笑天 option
iOS 程序启动时总会调用application:didFinishLaunchingWithOptions:，其中第二个参数launchOptions为NSDictionary类型的对象，里面存储有此程序启动的原因。 launchOptions中的可能键值见UIApplication Class Reference的Launch Options Keys节。 1、若用户直接
jdk与jre的区别（_） macroli java jvm jdk
简单的说JDK是面向开发人员使用的SDK，它提供了Java的开发环境和运行环境。SDK是Software Development Kit 一般指软件开发包，可以包括函数库、编译程序等。 JDK就是Java Development Kit JRE是Java Runtime Enviroment是指Java的运行环境，是面向Java程序的使用者，而不是开发者。如果安装了JDK，会发同你
Updates were rejected because the tip of your current branch is behind qiaolevip 学习永无止境每天进步一点点众观千象 git
$ git push joe prod-2295-1 To [email protected]:joe.le/dr-frontend.git ! [rejected] prod-2295-1 -> prod-2295-1 (non-fast-forward) error: failed to push some refs to '[email protected]
[一起学Hive]之十四-Hive的元数据表结构详解 superlxw1234 hive hive元数据结构
关键字：Hive元数据、Hive元数据表结构之前在 “[一起学Hive]之一–Hive概述，Hive是什么”中介绍过，Hive自己维护了一套元数据，用户通过HQL查询时候，Hive首先需要结合元数据，将HQL翻译成MapReduce去执行。本文介绍一下Hive元数据中重要的一些表结构及用途，以Hive0.13为例。文章最后面，会以一个示例来全面了解一下，
Spring 3.2.14，4.1.7，4.2.RC2发布 wiselyman Spring 3
Spring 3.2.14、4.1.7及4.2.RC2于6月30日发布。其中Spring 3.2.1是一个维护版本(维护周期到2016-12-31截止)，后续会继续根据需求和bug发布维护版本。此时，Spring官方强烈建议升级Spring框架至4.1.7 或者将要发布的4.2 。其中Spring 4.1.7主要包含这些更新内容。