gpt4 book ai didi

mysql - 大型 (1G) MySQL 数据库需要 30 小时才能导入 WAMP,加上 Null 错误

转载 作者:可可西里 更新时间:2023-11-01 07:58:53 25 4
gpt4 key购买 nike

我已经为此工作了几天,非常沮丧。

有一个 Magento 数据库,大约 1Gb 和 3MM 记录 - 需要进行备份并将其导入到我的本地机器上。本地机器在具有 16 Gb RAM 的全新游戏装备规范上运行 WAMP)。使用 PHPMyAdmin 将数据库导出到 .sql 文件中。

强烈建议使用 Saw BigDump 导入大型数据库。还可以找到一个链接,上面写着推荐使用 include column names in every INSERT statement 的语法。完毕。 ( http://www.atomicsmash.co.uk/blog/import-large-sql-databases/ )

开始导入。几个小时过去了(大约 3-4 小时)。得到一个错误:Page unavailable, or wrong url!更多搜索,尝试建议(主要在这里: http://www.sitehostingtalk.com/f16/bigdump-error-page-unavailable-wrong-url-56939/ )删除 $linespersession到 500 并添加 $delaypersession 300。再次运行,更多小时,同样的错误。

然后我将数据库重新导出到两个 .sql 转储(一个保存所有超过 100K 记录的大表),重复,同样的错误。所以我不再使用 Bigdump。

接下来是命令行!使用 Console2 我跑了 source mydump.sql . 30 小时 过去。然后报错:
ERROR 1231 (42000): Variable 'character_set_client' can't be set to the value of 'NULL'
ERROR 1231 (42000): Variable 'collation_connection' can't be set to the value of 'NULL'

更多的搜索,真正多样的解释。我尝试使用之前的拆分文件 - 再次运行它,同样的错误。

我无法弄清楚是什么导致了这两个错误。我知道我在两个不同的导出中遇到了相同的错误。我知道有一些表在 1-300,000 行之间。我也不认为 30 小时是正常的(在尖叫的快速机器上)仅导入 1Gb,但我可能是错的。

我应该尝试哪些其他选择?是导出格式吗?应该压缩还是不压缩?有没有更快的导入方式?有什么办法可以让这个过程更快吗?

谢谢!

编辑

感谢一些搜索和@Bill Karwin 的建议,这就是我所在的位置:

  • 使用 ssh 获取一个新的 mysqldump 并下载它。
  • 导入了 10 次不同的数据库。每次都快得多(5-10 分钟),因此修复了荒谬的导入时间。
  • 使用命令行,>source dump.sql
  • 但是,来自同一个 dump.sql 文件的每次导入都有不同数量的记录。在 300 万条记录中,它们相差 600 到 200,000 条记录。其中一个导入的记录比原始记录多 12,000 条。我试过设置和不设置 foreign_key_checks = 0;我尝试使用完全相同的设置多次运行相同的查询。每次的行数都不一样。

  • 我现在也收到这些错误:
    ERROR 1231 (42000): Variable 'time_zone' can't be set to the value of 'NULL'
    ERROR 1231 (42000): Variable 'sql_mode' can't be set to the value of 'NULL'
    ERROR 1231 (42000): Variable 'foreign_key_checks' can't be set to the value of 'NULL'
    ERROR 1231 (42000): Variable 'unique_checks' can't be set to the value of 'NULL'
    ERROR 1231 (42000): Variable 'character_set_client' can't be set to the value of 'NULL'
    ERROR 1231 (42000): Variable 'collation_connection' can't be set to the value of 'NULL'
    ERROR 1231 (42000): Variable 'sql_notes' can't be set to the value of 'NULL'

    从我读到的内容来看,这些似乎并不那么重要。还有其他警告,但我似乎无法确定它们是什么。

    有任何想法吗?

    编辑:解决方案已在此处删除并在下面作为单独的帖子列出

    引用文献:

    https://serverfault.com/questions/244725/how-to-is-mysqls-net-buffer-length-config-viewed-and-reset

    http://dev.mysql.com/doc/refman/5.1/en/server-system-variables.html#sysvar_net_buffer_length

    Make phpMyAdmin show exact number of records for InnoDB tables?

    Export a large MySQL table as multiple smaller files

    https://dba.stackexchange.com/questions/31197/why-max-allowed-packet-is-larger-in-mysqldump-than-mysqld-in-my-cnf

    最佳答案

    不,这不是正常的恢复时间,除非您在一台 15 岁的计算机上运行 MySQL,或者您试图通过非常慢的网络将数据库写入共享卷。我可以在大约 45 分钟内导入大约该大小的数据转储,即使在 x-small EC2 实例上也是如此。

    将变量设置为 NULL 的错误似乎是 BigDump 的限制。它在 BigDump FAQ 中提到.我从未见过使用命令行客户端恢复转储文件时出现的这些错误。

    所以这里有一些建议:

  • 确保您的本地 MySQL 数据目录位于本地连接的驱动器上——而不是网络驱动器上。
  • 使用 mysql命令行客户端,而不是 phpMyAdmin 或 BigDump。
    mysql> source mydump.sql
  • 转储文件大多是一长串INSERT语句,可以阅读Speed of INSERT Statements有关加速 INSERT 的提示。请务必阅读它链接到的子页面。
  • 例如,当您导出数据库时,检查“在每个 INSERT 语句中插入多行”的单选按钮(这与 BigDump 不兼容,但在 mysql 客户端中使用 source 时性能更好)。
  • 建议将耐久性设置用于生产用途,但它们会带来一些性能损失。听起来您只是想让开发实例运行,因此降低持久性可能是值得的,至少在您进行导入时是这样。 MySQL 社区经理 Morgan Tocker 的博客中对降低持久性做了很好的总结:Reducing MySQL durability for testing .


  • 重新回答您的新问题和错误:

    很多人在导入由 phpMyAdmin 或 Drupal 或其他工具创建的大型转储文件时都会报告类似的错误。

    最可能的原因是转储文件中的某些数据大于 max_allowed_packet .此 MySQL 配置设置是单个 SQL 语句或单个数据行的最大大小。当您在单个 SQL 语句中超过此值时,服务器将中止该 SQL 语句并关闭您的连接。 mysql 客户端尝试自动重新连接并恢复转储文件的来源,但有两个副作用:
  • 您的某些数据行无法加载。
  • 保留 @time_zone 的 session 变量导入期间的其他设置将丢失,因为它们的范围仅限于 session 。当重新连接发生时,您将获得一个新 session 。

  • 解决方法是增加您的 max_allowed_packet . MySQL 5.6 上的默认级别为 4MB,早期版本仅为 1MB。您可以找出此配置的当前值:
    mysql> SELECT @@max_allowed_packet;
    +----------------------+
    | @@max_allowed_packet |
    +----------------------+
    | 4194304 |
    +----------------------+

    您可以将其增加到 1GB:
    mysql> set global max_allowed_packet = 1024*1024*1024;

    然后再次尝试导入:
    mysql> source mydump.sql

    此外,如果您使用类似 SHOW TABLE STATUS 的命令测量表的大小。或查询 INFORMATION_SCHEMA.TABLES ,你应该知道 TABLE_ROWS count 只是一个估计值——它可能相差很远,比如表实际行数的 +/- 10%(或更多)。即使您没有更改表中的任何数据,报告的数字甚至可能会不时更改。计算表中行数的唯一正确方法是使用 SELECT COUNT(*) FROM SomeTable .

    关于mysql - 大型 (1G) MySQL 数据库需要 30 小时才能导入 WAMP,加上 Null 错误,我们在Stack Overflow上找到一个类似的问题: https://stackoverflow.com/questions/22540266/

    25 4 0
    Copyright 2021 - 2024 cfsdn All Rights Reserved 蜀ICP备2022000587号
    广告合作:1813099741@qq.com 6ren.com