当前位置: 首页 > 编程笔记 >

mysql错误处理之ERROR 1786 (HY000)

翁文康
2023-03-14
本文向大家介绍mysql错误处理之ERROR 1786 (HY000),包括了mysql错误处理之ERROR 1786 (HY000)的使用技巧和注意事项,需要的朋友参考一下

ERROR 1786 (HY000)

【环境描述】

msyql5.6.14

【报错信息】

执行create table ... select的时候遇到报错:

db1 [test] [23:01:58]> create tablelgmnr_bak select * from lgmnr;
ERROR 1786 (HY000): CREATE TABLE ... SELECTis forbidden when @@GLOBAL.ENFORCE_GTID_CONSISTENCY = 1

【报错原因】

ERROR1786是由于开启了enforce_gtid_consistency=true功能导致的,MySQL官方解释说当启用enforce_gtid_consistency功能的时候,MySQL只允许能够保障事务安全,并且能够被日志记录的SQL语句被执行,像create table ... select 和 create temporarytable语句,以及同时更新事务表和非事务表的SQL语句或事务都不允许执行

db1 [test] [23:28:28]> show variableslike 'ENFORCE_GTID_CONSISTENCY';

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

| Variable_name  | Value |

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

| enforce_gtid_consistency | ON |

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

【解决方法

由于enforce_gtid_consistency参数是只读的,所以必须重启MySQL服务才能是配置生效。

尝试在线动态修改时的报错:

db1 [test] [23:37:56]> set globalenforce_gtid_consistency=true;
ERROR 1238 (HY000): Variable'enforce_gtid_consistency' is a read only variable

下面是其他网友的补充

一般mysql5.7以前版本是支持create table XXX as select * from XXX; 这种创建表的语法,但是MySQL5.7.x版本里面gtid是开启的,会报错

ERROR 1786 (HY000):Statement violates GTID consistency: CREATE TABLE ... SELECT.

官方说明:https://dev.mysql.com/doc/refman/5.7/en/replication-gtids-restrictions.html

CREATE TABLE ... SELECT statements. CREATE TABLE ... SELECT is not safe for statement-based replication. When using row-based replication, this statement is actually logged as two separate events—one for the creation of the table, and another for the insertion of rows from the source table into the new table just created. When this statement is executed within a transaction, it is possible in some cases for these two events to receive the same transaction identifier, which means that the transaction containing the inserts is skipped by the slave. Therefore, CREATE TABLE ... SELECT is not supported when using GTID-based replication.

解决办法关闭GTID模式:

my.cnf里面修改参数为:

gtid_mode = OFF
enforce_gtid_consistency = OFF

重启MySQL,再次创建成功:

mysql> show variables like '%gtid_mode%';
+---------------+-------+
| Variable_name | Value |
+---------------+-------+
| gtid_mode   | OFF  |
+---------------+-------+
1 row in set (0.01 sec)

mysql> show variables like '%enforce_gtid_consistency%';
+--------------------------+-------+
| Variable_name      | Value |
+--------------------------+-------+
| enforce_gtid_consistency | OFF  |
+--------------------------+-------+
1 row in set (0.01 sec)

mysql> create table t1 as select * from BS_CONT;
Query OK, 0 rows affected (0.12 sec)

到此这篇关于mysql错误处理之ERROR 1786 (HY000)的文章就介绍到这了,更多相关mysql错误处理之ERROR 1786 (HY000)内容请搜索小牛知识库以前的文章或继续浏览下面的相关文章希望大家以后多多支持小牛知识库!

 类似资料:
  • 本文向大家介绍mysql错误处理之ERROR 1665 (HY000),包括了mysql错误处理之ERROR 1665 (HY000)的使用技巧和注意事项,需要的朋友参考一下 ERROR 1665 (HY000) 【环境描述】 msyql5.6.14 【报错信息】 执行SQL语句的时候报错: 【报错原因】 innodb的事务隔离级别是read commited或者read uncommited模式

  • 问题内容: 我已经阅读了一些在node.js中使用mysql的示例,并且对错误处理有疑问。 大多数示例都进行如下错误处理(为简便起见): 每次发生sql错误时,这都会导致服务器崩溃。我想避免这种情况并保持服务器运行。 我的代码是这样的: 我不确定这是否是处理它的最佳方法。我也想知道查询的块中是否应该有一个。否则,连接可能会保持打开状态并随着时间的推移逐渐建立。 我习惯了Java 或在这里可以“干净

  • 问题内容: 我正在运行一个基于python flask的小型Web服务,我想在其中执行一个小型MySQL查询。当我获得SQL查询的有效输入时,一切都按预期工作,并且我获得了正确的值。但是,如果该值未存储在数据库中,则会收到一个 我试图利用错误处理自己,并在我的项目中使用此代码,但看来这无法正常工作。 基本上,我只想返回一个值,当一切都正常工作时,如果最好不要在服务器上显示错误消息,则不返回任何值。

  • 问题内容: 我相信MySQL当前没有可用的东西允许访问MySQL存储过程中最后执行的语句。这意味着在存储过程中引发泛型时,很难/不可能得出错误的确切性质。 是否有人有变通办法来推导MySQL存储过程中的错误,而不涉及为每个可能的SQLSTATE声明处理程序? 例如,假设我正在尝试返回一个error_status,它超出了下面的通用“ SQLException在此块中的某处发生”: 有小费吗? PS

  • 通过对错误类型实现 Display 和 From,我们能够利用上绝大部分标准库错误处理工具。然而,我们遗漏了一个功能:轻松 Box 我们错误类型的能力。 标准库会自动通过 Form 将任意实现了 Error trait 的类型转换成 trait 对象 Box<Error> 的类型(原文:The std library automatically converts any type that imp

  • 错误处理(error handling)是处理可能发生失败情况的过程。例如读取一个文件失败,然后继续使用这个失效的输入显然是有问题的。错误处理允许我们以一种显式的方式来发现并处理这类错误,避免了其余代码发生潜在的问题。 有关错误处理的更多内容,可参考官方文档的错误处理的章节。