【问题标题】:MySQL table is broken after failed dump process using mysqldump使用 mysqldump 的转储过程失败后 MySQL 表损坏
【发布时间】:2021-12-06 16:12:36
【问题描述】:

我需要转储 MySQL InnoDB-database 由几个表组成。一个导致问题的表有近 1300 万行。 XAMPP(V.3.2.2) 转储进程的全新安装成功,之后,转储进程总是失败并显示错误消息“mysqldump:错误 2013:在查询期间转储表 gv_faktur_header_history 在行时丢失与 MySQL 服务器的连接: 2623629”。此时状态如下:

  • 无法插入任何值(错误 2013:丢失与 MySQL 的连接)

  • 无法发出“CHECK TABLE”命令(错误 2013:与 MySQL 的连接丢失)

  • 无法更改此表(添加列)

  • 可以从这个表中选择数据

  • 可以选择行 2623629 (select * from table limit 2623629 ,1)

  • 可以运行“显示表状态”命令

我像这样重复这个过程几次:

  1. 重新安装 xampp
  2. 使用此方法导入数据库
> set global net_buffer_length = 1000000; 
> set global max_allowed_packet = 1000000000; 
> SET foreign_key_checks = 0;
> SET UNIQUE_CHECKS = 0; 
> SET AUTOCOMMIT = 0; 
> use db_name; 
> source backup-file.sql SET
> foreign_key_checks = 1; 
> SET UNIQUE_CHECKS = 1; 
> SET AUTOCOMMIT = 1;
  1. 不使用 --skip-extending-insert 转储数据库(成功)
  2. 不使用 --skip-extending-insert 转储数据库(失败)
  3. 不使用 --skip-extending-insert 转储数据库(失败)

mysqldump 命令:

mysqldump -u root -p --skip-extended-insert --max-allowed-packet=1G --net-buffer-length=32704 rent_scaff header_history > D:\dobol

环境规范:

  • i5 8 代
  • Ram 8 GB(在任务管理器中看到 3 Gb 未使用)
  • SSD 存储 512G
  • mysqldump Ver 10.16 Distrib 10.1.10-MariaDB

这是 my.ini 配置

[client] 
# password       = your_password 
port            = 3306 
socket          = "C:/xampp/mysql/mysql.sock"

[mysqld]
port= 3306
socket = "C:/xampp/mysql/mysql.sock"
basedir = "C:/xampp/mysql" 
tmpdir = "C:/xampp/tmp" 
datadir = "C:/xampp/mysql/data"
pid_file = "mysql.pid"
key_buffer = 16M
max_allowed_packet = 1G
sort_buffer_size = 512K
net_buffer_length = 8K
read_buffer_size = 256K
read_rnd_buffer_size = 512K
myisam_sort_buffer_size = 8M
log_error = "mysql_error.log"
plugin_dir = "C:/xampp/mysql/lib/plugin/" 
server-id   = 1
innodb_data_home_dir = "C:/xampp/mysql/data"
innodb_data_file_path = ibdata1:10M:autoextend
innodb_log_group_home_dir = "C:/xampp/mysql/data"
innodb_buffer_pool_size = 1G
innodb_additional_mem_pool_size = 2M
innodb_log_file_size = 250M
innodb_log_buffer_size = 250M
innodb_flush_log_at_trx_commit = 1
innodb_lock_wait_timeout = 50

[mysqldump]
quick
max_allowed_packet = 1G

[mysql]
no-auto-rehash

[isamchk]
key_buffer = 20M
sort_buffer_size = 20M
read_buffer = 2M
write_buffer = 2M

[myisamchk]
key_buffer = 20M
sort_buffer_size = 20M
read_buffer = 2M
write_buffer = 2M

[mysqlhotcopy]
interactive-timeout
enter code here

Mysql 日志:

Server version: 10.1.10-MariaDB
key_buffer_size=16777216
read_buffer_size=262144
max_used_connections=2
max_threads=1001
thread_count=2
It is possible that mysqld could use up to 
key_buffer_size + (read_buffer_size + sort_buffer_size)*max_threads = 787099 K  bytes of memory
Hope that's ok; if not, decrease some variables in the equation.

Thread pointer: 0x0x3eee2178
Attempting backtrace. You can use the following information to find out
where mysqld died. If you see no messages after this, something went
terribly wrong...
mysqld.exe!my_parameter_handler()
mysqld.exe!my_mb_ctype_mb()
mysqld.exe!??2Geometry@@SAPAXIPAX@Z()
mysqld.exe!??2Geometry@@SAPAXIPAX@Z()
mysqld.exe!?propagate_equal_fields@Item_func_expr_str_metadata@@UAEPAVItem@@PAVTHD@@ABVContext@Value_source@@PAVCOND_EQUAL@@@Z()
mysqld.exe!??2Geometry@@SAPAXIPAX@Z()
mysqld.exe!??2Geometry@@SAPAXIPAX@Z()
mysqld.exe!??2Geometry@@SAPAXIPAX@Z()
mysqld.exe!??0Alter_table_prelocking_strategy@@QAE@XZ()
mysqld.exe!?mysql_alter_table@@YA_NPAVTHD@@PAD1PAUHA_CREATE_INFO@@PAUTABLE_LIST@@PAVAlter_info@@IPAUst_order@@_N@Z()
mysqld.exe!?execute@Sql_cmd_alter_table@@UAE_NPAVTHD@@@Z()
mysqld.exe!?mysql_execute_command@@YAHPAVTHD@@@Z()
mysqld.exe!?mysql_parse@@YAXPAVTHD@@PADIPAVParser_state@@@Z()
mysqld.exe!?dispatch_command@@YA_NW4enum_server_command@@PAVTHD@@PADI@Z()
mysqld.exe!?do_command@@YA_NPAVTHD@@@Z()
mysqld.exe!?threadpool_process_request@@YAHPAVTHD@@@Z()
mysqld.exe!?tp_end@@YAXXZ()
KERNEL32.DLL!SetUserGeoName()
ntdll.dll!TpCheckTerminateWorker()
ntdll.dll!TpCallbackIndependent()
KERNEL32.DLL!BaseThreadInitThunk()
ntdll.dll!RtlGetAppContainerNamedObjectPath()
ntdll.dll!RtlGetAppContainerNamedObjectPath()

Trying to get some variables.
Some pointers may be invalid and cause the dump to abort.

请帮助我如何转储(备份)大型数据库,至少如何安全地转储数据库,以便在进程失败时,表仍然可用。

【问题讨论】:

  • 这是题外话,应该在Database Admin :)
  • 哦,对不起,我会发帖到Database Admin
  • 没问题!不了解所有这些社区是正常的 x)

标签: mysql


【解决方案1】:

发生的情况是,要么一个命令永远占用并且超时,要么有太多数据无法一次放入缓存。

我会尝试使用 HeidiSQL 之类的程序来备份数据库。这将允许分阶段进行备份,而不是一个巨大的请求。

这将是使用 HeidiSQL 执行此操作的示例。如果 SQL 服务器在第二台计算机上,或者您认为不同的任何其他设置,请随意将 127.0.0.1 替换为不同的 IP 地址。

您将从设置连接开始:
HeidiSQL Sesssion Manager Setup

  • 然后,点击打开
  • 右键单击位于屏幕左上角的数据库
  • 单击将数据库导出为 SQL

首先我们将备份您的数据库结构:

  • 点击左侧的复选框
  • 单击右侧选项卡上的 SQL 导出
    • 数据库 -> 删除(未选中),创建(选中)
    • 表 -> 删除(未选中),创建(选中)
    • 数据 -> 无数据
    • 输出 -> 单个 .sql 文件
    • 文件名 -> 单击文件夹图标,选择一个位置并将文件命名为 DB_Structure.sql 之类的名称
  • 最后,点击导出

接下来,我们将从数据库中备份数据:

-与之前相同的步骤,在 SQL 导出中执行:

  • 数据库 -> 删除(取消选中),创建(取消选中)
  • 表 -> 删除(取消选中),创建(取消选中)
  • 数据 -> 从无数据更改为插入
  • 最大插入尺寸 -> 1024
  • 输出 -> 从单个 .sql 文件更改为 ZIP 压缩的 .sql 文件
  • 文件名 -> 单击文件夹图标,选择一个位置并将文件命名为 DB_Data.zip 之类的名称
  • 最后,点击导出

这就是您使用这些备份文件的方式:

  • 单击名为 ►Query 的选项卡
  • Ctrl + O
  • 在“打开文件”对话框中,导航到结构的备份 SQL 文件
  • 然后点击打开
  • 接下来,按 F9 运行 SQL 命令

完成后,您对数据 SQL 备份文件执行相同的过程。

【讨论】:

  • 您好,Ivar Harris,感谢您的回复。这不是超时问题,正如我在帖子中所写,对于xampp的全新安装,转储过程成功(5分钟),第一次转储后,第二次转储仅持续约30秒并失败。感谢您通知我 HeidiSQL,我会尝试一下,但我仍然对我的问题感到好奇
猜你喜欢
  • 1970-01-01
  • 1970-01-01
  • 1970-01-01
  • 1970-01-01
  • 2011-04-01
  • 1970-01-01
  • 1970-01-01
  • 1970-01-01
  • 2011-04-05
相关资源
最近更新 更多