ITPUB首页 |  论坛 | 认证专区 | 博客 登录 | 注册

Fantasy life

明月三千里

  • 博客访问: 743787
  • 博文数量: 157
  • 用 户 组: 普通用户
  • 注册时间: 2014-07-28 23:51
  • 认证徽章:
个人简介

转载请注明出处: 作者:神谕。博客地址:/29773961/。

ITPUB论坛APP

ITPUB论坛APP



APP发帖 享双倍积分

文章分类

全部博文(157)

文章存档

2018年(4)

2017年(23)

2016年(38)

2015年(67)

2014年(25)

微信关注

IT168企业级官微



微信号:IT168qiye



系统架构师大会



微信号:SACC2013

分类: MySQL


〇 现象:
    
在通过binlog
增量恢复数据时,报错1050。
〇 版本:
    
MySQL 5.5.x 及以下
,低版本的MySQL 5.6.x (在5.6的高版本中测试,无法复现,疑似被修复
〇 原因:
    
binlog记录了
执行出错的DDL语句,此处,具体DDL是CREATE VIEW $view_name AS ... 

有点奇怪,难道执行错误了的DDL也会被记录到binlog中么?


〇 复现:

  1. [17:52:45] root@localhost [a]> FLUSH LOGS;
  2. Query OK, 0 rows affected (0.01 sec)

  3. [17:52:47] root@localhost [a]> SHOW BINLOG EVENTS IN 'mysql55-bin.000006';
  4. +--------------------+-----+-------------+-----------+-------------+---------------------------------------+
  5. | Log_name | Pos | Event_type | Server_id | End_log_pos | Info |
  6. +--------------------+-----+-------------+-----------+-------------+---------------------------------------+
  7. | mysql55-bin.000006 | 4 | Format_desc | 55 | 107 | Server ver: 5.5.57-log, Binlog ver: 4 |
  8. +--------------------+-----+-------------+-----------+-------------+---------------------------------------+
  9. 1 row in set (0.00 sec)

  10. [17:53:13] root@localhost [a]> CREATE TABLE t(id int);
  11. Query OK, 0 rows affected (0.01 sec)

  12. [17:53:18] root@localhost [a]> CREATE VIEW v_t AS SELECT * from t;
  13. Query OK, 0 rows affected (0.00 sec)

  14. [17:53:21] root@localhost [a]> CREATE VIEW v_t AS SELECT * from t;
  15. ERROR 1050 (42S01): Table 'v_t' already exists

此时,再次检查binlog:
  1. [17:53:24] root@localhost [a]> SHOW BINLOG EVENTS IN 'mysql55-bin.000006'\G
  2. *************************** 1. row ***************************
  3.    Log_name: mysql55-bin.000006
  4.         Pos: 4
  5.  Event_type: Format_desc
  6.   Server_id: 55
  7. End_log_pos: 107
  8.        Info: Server ver: 5.5.57-log, Binlog ver: 4
  9. *************************** 2. row ***************************
  10.    Log_name: mysql55-bin.000006
  11.         Pos: 107
  12.  Event_type: Query
  13.   Server_id: 55
  14. End_log_pos: 189
  15.        Info: use `a`; CREATE TABLE t(id int)
  16. *************************** 3. row ***************************
  17.    Log_name: mysql55-bin.000006
  18.         Pos: 189
  19.  Event_type: Query
  20.   Server_id: 55
  21. End_log_pos: 369
  22.        Info: use `a`; CREATE ALGORITHM=UNDEFINED DEFINER=`root`@`localhost` SQL SECURITY DEFINER VIEW `v_t` AS SELECT * from t
  23. *************************** 4. row ***************************
  24.    Log_name: mysql55-bin.000006
  25.         Pos: 369
  26.  Event_type: Query
  27.   Server_id: 55
  28. End_log_pos: 549
  29.        Info: use `a`; CREATE ALGORITHM=UNDEFINED DEFINER=`root`@`localhost` SQL SECURITY DEFINER VIEW `v_t` AS SELECT * from t
  30. 4 rows in set (0.00 sec)

可以发现,第二次执行CREATE VIEW,即便在mysql client执行时报错,也被记录到binlog中。
自然,在通过mysqlbinlog重放binlog时,也会报错。

在复制结构中,从实例不会重放该events,故从库不会报错。

重新通过mysqlbinlog解析日志得到:
  1. # at 107
  2. #180206 17:53:18 server id 55 end_log_pos 189 Query thread_id=13 exec_time=0 error_code=0
  3. use `a`/*!*/;
  4. SET TIMESTAMP=1517910798/*!*/;
  5. SET @@session.pseudo_thread_id=13/*!*/;
  6. SET @@session.foreign_key_checks=1, @@session.sql_auto_is_null=0, @@session.unique_checks=1, @@session.autocommit=1/*!*/;
  7. SET @@session.sql_mode=0/*!*/;
  8. SET @@session.auto_increment_increment=1, @@session.auto_increment_offset=1/*!*/;
  9. /*!\C utf8 *//*!*/;
  10. SET @@session.character_set_client=33,@@session.collation_connection=33,@@session.collation_server=8/*!*/;
  11. SET @@session.lc_time_names=0/*!*/;
  12. SET @@session.collation_database=DEFAULT/*!*/;
  13. CREATE TABLE t(id int)
  14. /*!*/;
  15. # at 189
  16. #180206 17:53:21 server id 55 end_log_pos 369 Query thread_id=13 exec_time=0 error_code=0
  17. SET TIMESTAMP=1517910801/*!*/;
  18. CREATE ALGORITHM=UNDEFINED DEFINER=`root`@`localhost` SQL SECURITY DEFINER VIEW `v_t` AS SELECT * from t
  19. /*!*/;
  20. # at 369
  21. #180206 17:53:22 server id 55 end_log_pos 549 Query thread_id=13 exec_time=0 error_code=1050
  22. SET TIMESTAMP=1517910802/*!*/;
  23. CREATE ALGORITHM=UNDEFINED DEFINER=`root`@`localhost` SQL SECURITY DEFINER VIEW `v_t` AS SELECT * from t
  24. /*!*/;
可以发现第二次报错的语句,虽然被记录到binlog中,但error_code标识为1050

至于为何从库不报错,大概是因为sql thread会特殊处理这种error_code,不会执行
而mysqlbinlog mysql-binlog.00000x | mysql -u -p -S 重放binlog的方式会报错。——大概是因为mysql这个client工具没有做对mysqlbinlog解析出来的error_code的特殊处理吧。

暂时不知道是否为bug,但高版本的MySQL5.6.x已经修正了该问题,5.7也如此。

因此,在可能出现问题的版本,通过binlog增量恢复数据时,可能需要特殊处理。



阅读(778) | 评论(0) | 转发(0) |
0

上一篇:【MySQL】mysqldump备份失败与解决方案合集

下一篇:没有了

相关热门文章
  • pl/sql中有没有类似c++内联函...
  • 在高并发、高负载的情况下,如...
  • PL/SQL查找数据库对象为什么没...
  • PL/SQL Challenge 每日一题:2...
  • PL/SQL Challenge 每日一题:2...
给主人留下些什么吧!~~
评论热议
请登录后评论。

登录 注册

友情链接:万达娱乐招商  guoqibee.com  华宇招商  万达招商QQ  万达主管QQ  万达娱乐注册  万达注册  万达娱乐  万达娱乐直属QQ  万达娱乐主管