我的mysql服务目前无法启动的错误 InnoDB：找不到'wowcher / temp_import'的有效表空间文件。 我想我知道问题是什么。 我有一个PHP脚本将CSV文件导入临时表，然后将信息分解到正确的相关表。 然后，它会擦除脚本末尾的临时表，但由于某种原因，它在完成和擦除表之前已经出错了。 所以林相当肯定临时表是巨大的，现在。 我无法启动mysql服务时如何擦除它？ 还是其他的东西导致了这个问题呢？
我用正式的docker图像设置了几个maraidb v10.2.10容器。 Master可以读/写，slave是只读的。 [mysqld] server_id=2 read_only=1 innodb_read_only=1 复制工作一段时间，但它停止了以下错误： Slave_IO_Running: Yes Slave_SQL_Running: No Last_Errno: 1942 Last_Error: Error during COMMIT: failed to update GTID state in mysql.gtid_slave_pos: 1036: Table 'gtid_slave_pos' is read only 我把这行添加到slave的my.cnf中，并从头开始重新设置，但仍然出现同样的错误。 replicate-ignore-table=mysql.gtid_slave_pos 这是否意味着Innodb无法复制到innodb-read-only服务器？
每当我启动MySQL服务器5.1.33或5.1.40（开发人员构build），并尝试从一个表读取服务器崩溃与日志文件中的这条消息： InnoDB：错误：（1500）无法从索引（PRIMARY）读取MAX（userFK）autoinc值。 我已经升级到5.1.40每个http://bugs.mysql.com/bug.php?id=44030，但我仍然无法从表中读取，所以我无法恢复它。 我已经用innodb_force_recovery = 1启动了服务器，但是这也没有帮助，REPAIR，CHECK或者SELECT或者任何其他的命令都会使服务器崩溃。 我该如何修复表格，使其再次可读？
我有一个InnoDB数据表，这个数据表已经完美的工作了好几年，但是昨天两次失败了，可能是访问量增加的原因没有明显的原因，这个表locking了，有数百个DELETE REPLACE INTO查询（+ 500）与“更新”或“清理”状态。 （我没有更多的过程清单的副本…） 这个表格包含500到1500之间的几个条目，所以更新查询通常非常快并且不locking。 当问题发生时，我查了很多次这个进程列表，还没有看到任何明确locking表的查询。 实际上，我把我的网站设置为维护模式，所以没有更多的查询被添加到队列中，仍然有500多个查询，都是一样的： +———+———+————–+———+———+——+———-+———————————————–+ | Id | User | Host | db | Command | Time | State | Info | +———+———+————–+———+———+——+———-+———————————————–+ | 2780657 | XXXXXXX | XXXXXX:58199 | XXXXXXX | Query | 660 | updating | DELETE FROM connected WHERE time < 1272100968 | | 2764941 | XXXXXXX | […]
我想了解这是如何发生的。 我正在运行一个需要很长时间的查询，但不应该locking任何表。 不过，我的dbs几乎是倒下了 – 看起来它正在被“FLUSH TABLES WITH READ LOCK” 03:21:31 从guid_target_infos组中selecttype_id，count（ ）按type_id 02:38:11从guid_infos组中selecttype_id，count（ ）按type_id 02:24:29 FLUSH TABLES WITH READ LOCK 但是我没有开始这个命令。 有人可以告诉我为什么自动启动？
我知道这听起来很奇怪，但显然我的一列被locking。 select * from table where type_id = 1 and updated_at < '2010-03-14' limit 1; select * from table where type_id = 3 and updated_at < '2010-03-14' limit 10; 第一个没有完成，第二个完成顺利。 唯一的区别是type_id 在此先感谢您的帮助 – 我有一个紧急的数据工作完成，这个问题正在让我疯狂
我目前正在尝试从.ibd文件恢复MySQL表。 我一直在关注如何使用DISCARD和IMPORT TABLESPACEreplace.idb文件的MySQL参考手册上的说明。 放弃表空间返回没有错误，并且文件被删除但是IMPORTINGreplace.ibd文件产生“从存储引擎得到错误-1”错误。 似乎没有太多关于错误-1是什么的信息。 有没有人有进一步的见解，为什么导入表空间不工作？
我有一个问题设置innodb作为Ubuntu 10.04上的MySQL 5.1的默认数据库引擎。 只要我切换到innodb作为默认引擎服务器拒绝启动。 这是我在启用innodb之后尝试启动MySQL时在syslog中得到的内容： Oct 6 21:18:29 artemis init: mysql main process ended, respawning Oct 6 21:18:58 artemis init: mysql post-start process (5825) terminated with status 1 Oct 6 21:18:59 artemis init: mysql main process (5943) terminated with status 7 Oct 6 21:18:59 artemis init: mysql main process ended, respawning Oct 6 21:19:28 artemis […]
问题描述 我有一个相当大的MySQL安装。 至less有3个独立的服务器运行innodb存储引擎。 每分钟一次，每分钟同一时间，大约3-4秒，我的每一台无人机突然停止运转。 当我在正常的时间在每个服务器上执行SHOW PROCESSLIST时，我会看到大约10-15个连接，正常工作： +——–+——————+————————–+——+———+——+——-+——————+ | Id | User | Host | db | Command | Time | State | Info | +——–+——————+————————–+——+———+——+——-+——————+ | 23457 | root | localhost | NULL | Query | 0 | NULL | show processlist | | 180042 | ********** | web2.***.com:49867 | *** | Sleep | 1 […]
我在最近几天遇到了一个问题，我有一个数据库服务器2个四核处理器和24 GB的内存，最近我们遇到了一个大问题，服务器正常运行在大约130％的CPU，然后它会随机高峰到几乎750％的内核都能够让我们的网站超级爬行。 我重新启动了mysql进程，然后解决了大约10分钟后再次发生。 最后一次发生，我让它坐在750％，几分钟后它又回落。 我做了一个stream程转储，因为它正在发生，它有大约4000个队列中的查询，说复制/发送到tmp表。 如果有人知道这个问题，或者在MySQL innodb数据库和PHP的专家让我知道，我甚至愿意支付以获得此修复，价格不是一个问题，只是想解决问题。