我不确定这是否应该在SuperUser中发布,因为我们在Workbench中使用了内置的迁移向导,如果应该移动这个问题,请告诉我。
目标
我们目前正在将数据库从一个服务器迁移到另一个服务器,因为MySQL Workbench有一个称为迁移向导的内置函数,我们认为我们会采用我们的快乐方式来迁移它。我们有16种不同的数据库模式需要以不同的大小进行迁移(最小为3 MB,最大为76 GB)。
问题
我们开始尝试迁移其中一个中型到大型的,位于14.7 GB并且开始很好但是在它成功迁移了一半的表之后我们得到错误“MySQL服务器已经消失”。在确保连接稳定并将其与电缆连接后(可能是无线信号丢失了?)并确保了完全权限并使用root用户进行迁移我们仍然得到“服务器已经消失”错误。
然后我们尝试使用较小的数据库工作正常,因此我们认为这可能是一个超时问题。我们尝试删除超时设置但我们仍然会为较大的数据库获得相同的错误。真正的踢球者是我们目前正在经历的。
当我们在150 MB数据库上尝试此操作时,迁移向导会正确完成迁移,而不会出现任何错误或警告。出于好奇,我运行了以下代码
SELECT table_name AS "Table",
round(((data_length + index_length) / 1024 / 1024), 2) "Size in MB"
FROM information_schema.TABLES
WHERE table_schema = "TableName"
ORDER BY "Table";
确保表格大小正确。令我们惊讶的是,源数据库中的表总和为150 MB,但目标数据库中的总和为94 MB。
问题(S)
除了超时和特权之外,为什么我们得到“服务器已经消失”的错误还有什么其他原因呢?为什么迁移向导会说迁移成功而没有警告或错误,但实际上只有大约60%的数据被迁移?迁移向导不可信,还是不应该信任的表大小查询?我们是否完全错误,即您是否建议采用另一种更稳定的方式迁移数据库?
如果需要,我很乐意提供更多信息。
修改
MySQL版本:5.1.41(Ubuntu)
我们还检查了每个模式中每个表中的行数,虽然大多数都是正确的,但有些错误。这是数据不一致发挥作用的地方。在150 MB / 94 MB示例中,有25个表。在这25个表中,23个是正确的,2个不是。在源代码中,其中一个表有257万行,但其中只有150万行最终出现在目标表中。
编辑2:
再次运行相同的查询现在给了我150个中的94个,150个中的8个,150个中的24个,现在是第四次迁移整个数据库。我猜这个问题位于其他地方,但不能为我的生活找出原因。迁移150 MB数据花了92分钟。推断这将给我大约一个月的时间来迁移75 GB的数据库 - 这显然是不对的。
答案 0 :(得分:1)
我知道它的帖子很旧,但是为了他人的利益,您可以使用HeidiSQL,它可以通过将数据库导出到您选择的另一个数据库来完美地完成工作:
答案 1 :(得分:0)