MySQL crash:InnoDB redo log error

最新推荐文章于 2024-09-13 22:40:44 发布

最新推荐文章于 2024-09-13 22:40:44 发布 · 253 阅读

文章标签：

本文探讨了InnoDB数据库出现的特定错误及其解决办法，包括错误代码解析及应对策略，并介绍了在主从同步环境下创建存储过程时可能遇到的问题及解决方案。

InnoDB: Progress in percents: 1120731 9:56:59 InnoDB: Error: page 9 log sequence number 5746244819174
InnoDB: is in the future! Current system log sequence number 5706919300319.
InnoDB: Your database may be corrupt or you may have copied the InnoDB

InnoDB: tablespace but not the InnoDB log files.

===================================
innodb redo log 出错

原因:不详

解决方法:MHA切换到备机上去,主机重新恢复,在用备机上的binlog对齐数据后,加入为备机.

求其他DBA,或者SA、R&D大侠给个补充

tudou@b2c.xiaomi.com

主从同步的情况下创建存储过程会报错：

ERROR 1418 (HY000): This function has none of DETERMINISTIC, NO SQL, or READS SQL DATA in its declaration and binary logging is enabled (you *might* want to use the less safe log_bin_trust_function_creators variable)

原因是：

This variable applies when binary logging is enabled. It controls whether stored function creators can be trusted not to create stored functions that will cause unsafe events to be written to the binary log. If set to 0 (the default), users are not permitted to create or alter stored functions unless they have theSUPERprivilege in addition to theCREATE ROUTINEorALTER ROUTINEprivilege. A setting of 0 also enforces the restriction that a function must be declared with theDETERMINISTICcharacteristic, or with theREADS SQL DATAorNO SQLcharacteristic. If the variable is set to 1, MySQL does not enforce these restrictions on stored function creation. This variable also applies to trigger creation.

=================================

通过设置set global log_bin_trust_function_creators = 1;不再限制存储过程创建。

也可以在my.cnf中直接限制。

Multi-statement transaction required more than 'max_binlog_cache_size' bytes of storage; increase this mysqld variable and try again

dump后在其他实例上做恢复报错，目前做法：set globalmax_binlog_cache_size=dumpserversize;

不知道其他DBA 有神马好方法