今天,我们的mysql数据库服务器突然中断了。在重新启动服务器后的几分钟内,服务器一次又一次地关闭。为了了解正在发生的事情,我们暂时将应用程序置于维护模式中,发现数据库不再关闭。这帮助我找出了发生了什么;
一个特定表上的每个UPDATE或INSERT都会导致大量SELECT查询(在同一表上)“等待表元数据锁”。由于这个原因,许多打开的连接在几秒钟内就出现了,最后服务器崩溃了。我不明白为什么一个简单的UPDATE app.notes SET user_id=5 WHERE note_id=1查询花了这么长时间,甚至在10分钟之后,等待仍未完成。该查询上的SHOW PROCESSLIST状态仍在执
作为mysql根用户,我在运行mysqldump时遇到了困难。当我试图备份mysql表时,会得到以下错误:
mysqldump: Got error: 1142: SELECT,LOCK TABL command denied to user
'root'@'localhost' for table 'cond_instances' when using LOCK TABLES
有人以前见过吗?我看到了对mysql和mysqldump的一些引用,它们是不同的版本,但是当我运行时,它们在同一个目录中。
我正在运行MySQL 5.5.8。
我已经建立了一个系统,它的目的是生成我们生产数据的增量转储到我们的数据仓库。从这个意义上说,“增量”意味着我们可以每分钟与我们的数据仓库“同步”生产数据库,而不必生成一个完整的转储。相反,我们只是转储和插入新的/更改的数据。
在复制保存中,我已经建立了一个系统,其中生产数据库的每个相关表都有一个插入TRIGGER和一个更新TRIGGER。这些复制插入或更新到不同架构中的“审核表”中的每一行。此审计模式包含与生产表具有相同结构的表,但不包含索引,通过使用这些TRIGGER,审计表将只包含上次导出后的新行或更新行。
目前,我正在使用mysql命令行客户端对每个审计表执行以下操作:
LOCK T