MariaDB 10.0.16 在导入 MySQL 5.1.70 转储期间崩溃
MariaDB 10.0.16 crash during import of MySQL 5.1.70 dump
我有一个小的MySQL 5.1.70 InnoDB 数据库：4 tables； ~3K、~23K、~500K、~600K 行。这在 OpenBSD 5.4 上运行。
我正在升级到 OpenBSD 5.7，它切换到 MariaDB 10.0.16（AFAIK 向后移植 MySQL 5.6 功能）。为此，我构建了一个小型临时 OpenBSD 5.7/MariaDB 服务器，以便我可以测试升级。为了安全起见，我重新创建了数据库架构以匹配产品架构和 运行 mysql_upgrade --force。
现在我想用产品数据填充它。我转储了数据：
$ mysqldump -u root -p --single-transaction --no-create-info \
--skip-add-drop-table --skip-extended-insert mydb > data_dump.sql
$ du -h data_dump.sql
116M data_dump.sql
转储包含 text/numbers，没有 blob 或二进制文件。
问题是 MariaDB 在导入转储中的第一个 table 时不断中止 运行domly，这只是 ~23K 行。
staging $ df -h
Filesystem Size Used Avail Capacity Mounted on
/dev/wd0a 7.2G 3.5G 3.3G 51% /
staging $ mysql -u root -p -D mydb < data_dump.sql
Enter password:
ERROR 2013 (HY000) at line 8039: Lost connection to MySQL server during query
它崩溃的行是一个正常的 INSERT，与之前的数千行没有什么不同。事实上，再次重复导入（截断 tables 并确保服务器正常启动后）不会在同一行崩溃。我已经看到它在 4000 行后崩溃，例如，相同的 my.cnf。所以我排除了坏数据假设。
错误日志显示如下（从服务器启动到崩溃）：
160211 12:07:05 mysqld_safe Starting mysqld daemon with databases from /var/mysql
160211 12:07:06 [Note] InnoDB: Using mutexes to ref count buffer pool pages
160211 12:07:06 [Note] InnoDB: The InnoDB memory heap is disabled
160211 12:07:06 [Note] InnoDB: Mutexes and rw_locks use GCC atomic builtins
160211 12:07:06 [Note] InnoDB: GCC builtin __sync_synchronize() is used for memory barrier
160211 12:07:06 [Note] InnoDB: Compressed tables use zlib 1.2.3
160211 12:07:06 [Note] InnoDB: Not using CPU crc32 instructions
160211 12:07:06 [Note] InnoDB: Initializing buffer pool, size = 128.0M
160211 12:07:06 [Note] InnoDB: Completed initialization of buffer pool
160211 12:07:06 [Note] InnoDB: Setting log file /var/mysql/ib_logfile101 size to 32 MB
160211 12:07:09 [Note] InnoDB: Setting log file /var/mysql/ib_logfile1 size to 32 MB
160211 12:07:11 [Note] InnoDB: Renaming log file /var/mysql/ib_logfile101 to /var/mysql/ib_logfile0
160211 12:07:11 [Warning] InnoDB: New log files created, LSN=27985430
160211 12:07:11 [Note] InnoDB: Highest supported file format is Barracuda.
160211 12:07:11 [Note] InnoDB: 128 rollback segment(s) are active.
160211 12:07:12 [Note] InnoDB: Waiting for purge to start
160211 12:07:12 [Note] InnoDB: Percona XtraDB (http://www.percona.com) 5.6.22-71.0 started; log sequence number 27985932
160211 12:07:12 [Note] Server socket created on IP: '127.0.0.1'.
160211 12:07:12 [Note] Event Scheduler: Loaded 0 events
160211 12:07:12 [Note] /usr/local/libexec/mysqld: ready for connections.
Version: '10.0.16-MariaDB-log' socket: '/var/run/mysql/mysql.sock' port: 3306 OpenBSD port: mariadb-server-10.0.16v0
2016-02-11 12:09:34 c10b6700 InnoDB: Assertion failure in thread 3238749952 in file trx0purge.cc line 695
InnoDB: Failing assertion: purge_sys->rseg->last_page_no != FIL_NULL
InnoDB: We intentionally generate a memory trap.
InnoDB: Submit a detailed bug report to http://bugs.mysql.com.
InnoDB: If you get repeated assertion failures or crashes, even
InnoDB: immediately after the mysqld startup, there may be
InnoDB: corruption in the InnoDB tablespace. Please refer to
InnoDB: http://dev.mysql.com/doc/refman/5.6/en/forcing-innodb-recovery.html
InnoDB: about forcing recovery.
Abort trap
160211 12:09:34 mysqld_safe mysqld restarted
160211 12:09:34 [Note] InnoDB: Using mutexes to ref count buffer pool pages
160211 12:09:34 [Note] InnoDB: The InnoDB memory heap is disabled
160211 12:09:34 [Note] InnoDB: Mutexes and rw_locks use GCC atomic builtins
160211 12:09:34 [Note] InnoDB: GCC builtin __sync_synchronize() is used for memory barrier
160211 12:09:34 [Note] InnoDB: Compressed tables use zlib 1.2.3
160211 12:09:34 [Note] InnoDB: Not using CPU crc32 instructions
160211 12:09:34 [Note] InnoDB: Initializing buffer pool, size = 128.0M
160211 12:09:35 [Note] InnoDB: Completed initialization of buffer pool
160211 12:09:35 [Note] InnoDB: Highest supported file format is Barracuda.
160211 12:09:35 [Note] InnoDB: Log scan progressed past the checkpoint lsn 31818497
160211 12:09:35 [Note] InnoDB: Database was not shutdown normally!
160211 12:09:35 [Note] InnoDB: Starting crash recovery.
160211 12:09:35 [Note] InnoDB: Reading tablespace information from the .ibd files...
160211 12:09:35 [Note] InnoDB: Restoring possible half-written data pages
160211 12:09:35 [Note] InnoDB: from the doublewrite buffer...
InnoDB: Doing recovery: scanned up to log sequence number 32140062
160211 12:09:36 [Note] InnoDB: Starting an apply batch of log records to the database...
InnoDB: Progress in percent: 54 55 56 57 58 59 60 61 62 63 64 65 66 67 68 69 70 71 72 73 74 75 76 77 78 79 80 81 82 83 84 85 86 87 88 89 90 91 92 93 94 95 96 97 98 99
InnoDB: Apply batch completed
InnoDB: Last MySQL binlog file position 0 2314577, file name ./binlog.000079
160211 12:09:36 [Note] InnoDB: 128 rollback segment(s) are active.
160211 12:09:36 [Note] InnoDB: Waiting for purge to start
160211 12:09:36 [Note] InnoDB: Percona XtraDB (http://www.percona.com) 5.6.22-71.0 started; log sequence number 32140062
160211 12:09:37 [Note] Recovering after a crash using binlog
160211 12:09:37 [Note] Starting crash recovery...
160211 12:09:37 [Note] Crash recovery finished.
160211 12:09:37 [Note] Server socket created on IP: '127.0.0.1'.
160211 12:09:37 [Note] Event Scheduler: Loaded 0 events
160211 12:09:37 [Note] /usr/local/libexec/mysqld: ready for connections.
Version: '10.0.16-MariaDB-log' socket: '/var/run/mysql/mysql.sock' port: 3306 OpenBSD port: mariadb-server-10.0.16v0
我没有用谷歌搜索 purge_sys->rseg->last_page_no != FIL_NULL 失败的断言。这是 MariaDB 的 /etc/my.cnf 文件：
[client]
port = 3306
socket = /var/run/mysql/mysql.sock
[mysqld]
port = 3306
socket = /var/run/mysql/mysql.sock
datadir = /var/mysql
max_allowed_packet = 128M
table_open_cache = 64
sort_buffer_size = 128K
read_buffer_size = 512K
net_buffer_length = 64K
server-id = 1
general-log = 1
general_log_file = query.log
log-error = error.log
slow-query-log = 1
long_query_time = 2
slow_query_log_file = slow_queries.log
bind-address = 127.0.0.1
log-bin = binlog
binlog_format = mixed
max_binlog_size = 512M
key_buffer_size = 2M
read_rnd_buffer_size = 1M
innodb_data_home_dir = /var/mysql/
innodb_log_group_home_dir = /var/mysql/
innodb_data_file_path = ibdata1:10M:autoextend
innodb_buffer_pool_size = 128M
innodb_log_file_size = 32M
innodb_log_buffer_size = 16M
innodb_lock_wait_timeout = 50
innodb_max_dirty_pages_pct = 1
[mysqldump]
quick
max_allowed_packet = 16M
[mysql]
no-auto-rehash
[mysqlhotcopy]
interactive-timeout
最初，其中一些参数设置为较低的值（仍在生产中 MySQL），但上述增加收效甚微：
net_buffer_length was 2K
max_allowed_packet was 1M
innodb_buffer_pool_size was 64M
innodb_log_file_size was 5M
innodb_log_buffer_size was 8M
此外，将 innodb_buffer_pool_size/innodb_log_file_size 增加到 256M/64M 似乎 post 稍微缓解了崩溃，但没有太大帮助。
除了将导入分成小块外，我不知道还能做什么。在我看来，这是一个非常小的导入文件。登台服务器是一个旧的 iBook（500mhz ppc），带有非 SSD 驱动器（3.3G 免费），但我没有注意到任何磁盘问题或高内存压力（top 报告 200+Mb 空闲 RAM）导入。
哪些 my.cnf 参数可能导致此崩溃？
编辑：
请求的超时信息：
MariaDB []> SHOW GLOBAL VARIABLES LIKE '%timeout';
+-----------------------------+----------+
| Variable_name | Value |
+-----------------------------+----------+
| connect_timeout | 10 |
| delayed_insert_timeout | 300 |
| innodb_flush_log_at_timeout | 1 |
| innodb_lock_wait_timeout | 50 |
| innodb_rollback_on_timeout | OFF |
| interactive_timeout | 28800 |
| lock_wait_timeout | 31536000 |
| net_read_timeout | 30 |
| net_write_timeout | 60 |
| slave_net_timeout | 3600 |
| thread_pool_idle_timeout | 60 |
| wait_timeout | 28800 |
+-----------------------------+----------+
看起来这可能是一个错误，可能与 OpenBSD/PowerPC 相关。已在此处向 MariaDB 开发人员报告：http://mariadb.atlassian.net/browse/MDEV-9569
我有一个小的MySQL 5.1.70 InnoDB 数据库：4 tables； ~3K、~23K、~500K、~600K 行。这在 OpenBSD 5.4 上运行。
我正在升级到 OpenBSD 5.7，它切换到 MariaDB 10.0.16（AFAIK 向后移植 MySQL 5.6 功能）。为此，我构建了一个小型临时 OpenBSD 5.7/MariaDB 服务器，以便我可以测试升级。为了安全起见，我重新创建了数据库架构以匹配产品架构和 运行 mysql_upgrade --force。
现在我想用产品数据填充它。我转储了数据：
$ mysqldump -u root -p --single-transaction --no-create-info \
--skip-add-drop-table --skip-extended-insert mydb > data_dump.sql
$ du -h data_dump.sql
116M data_dump.sql
转储包含 text/numbers，没有 blob 或二进制文件。 问题是 MariaDB 在导入转储中的第一个 table 时不断中止 运行domly，这只是 ~23K 行。
staging $ df -h
Filesystem Size Used Avail Capacity Mounted on
/dev/wd0a 7.2G 3.5G 3.3G 51% /
staging $ mysql -u root -p -D mydb < data_dump.sql
Enter password:
ERROR 2013 (HY000) at line 8039: Lost connection to MySQL server during query
它崩溃的行是一个正常的 INSERT，与之前的数千行没有什么不同。事实上，再次重复导入（截断 tables 并确保服务器正常启动后）不会在同一行崩溃。我已经看到它在 4000 行后崩溃，例如，相同的 my.cnf。所以我排除了坏数据假设。
错误日志显示如下（从服务器启动到崩溃）：
160211 12:07:05 mysqld_safe Starting mysqld daemon with databases from /var/mysql
160211 12:07:06 [Note] InnoDB: Using mutexes to ref count buffer pool pages
160211 12:07:06 [Note] InnoDB: The InnoDB memory heap is disabled
160211 12:07:06 [Note] InnoDB: Mutexes and rw_locks use GCC atomic builtins
160211 12:07:06 [Note] InnoDB: GCC builtin __sync_synchronize() is used for memory barrier
160211 12:07:06 [Note] InnoDB: Compressed tables use zlib 1.2.3
160211 12:07:06 [Note] InnoDB: Not using CPU crc32 instructions
160211 12:07:06 [Note] InnoDB: Initializing buffer pool, size = 128.0M
160211 12:07:06 [Note] InnoDB: Completed initialization of buffer pool
160211 12:07:06 [Note] InnoDB: Setting log file /var/mysql/ib_logfile101 size to 32 MB
160211 12:07:09 [Note] InnoDB: Setting log file /var/mysql/ib_logfile1 size to 32 MB
160211 12:07:11 [Note] InnoDB: Renaming log file /var/mysql/ib_logfile101 to /var/mysql/ib_logfile0
160211 12:07:11 [Warning] InnoDB: New log files created, LSN=27985430
160211 12:07:11 [Note] InnoDB: Highest supported file format is Barracuda.
160211 12:07:11 [Note] InnoDB: 128 rollback segment(s) are active.
160211 12:07:12 [Note] InnoDB: Waiting for purge to start
160211 12:07:12 [Note] InnoDB: Percona XtraDB (http://www.percona.com) 5.6.22-71.0 started; log sequence number 27985932
160211 12:07:12 [Note] Server socket created on IP: '127.0.0.1'.
160211 12:07:12 [Note] Event Scheduler: Loaded 0 events
160211 12:07:12 [Note] /usr/local/libexec/mysqld: ready for connections.
Version: '10.0.16-MariaDB-log' socket: '/var/run/mysql/mysql.sock' port: 3306 OpenBSD port: mariadb-server-10.0.16v0
2016-02-11 12:09:34 c10b6700 InnoDB: Assertion failure in thread 3238749952 in file trx0purge.cc line 695
InnoDB: Failing assertion: purge_sys->rseg->last_page_no != FIL_NULL
InnoDB: We intentionally generate a memory trap.
InnoDB: Submit a detailed bug report to http://bugs.mysql.com.
InnoDB: If you get repeated assertion failures or crashes, even
InnoDB: immediately after the mysqld startup, there may be
InnoDB: corruption in the InnoDB tablespace. Please refer to
InnoDB: http://dev.mysql.com/doc/refman/5.6/en/forcing-innodb-recovery.html
InnoDB: about forcing recovery.
Abort trap
160211 12:09:34 mysqld_safe mysqld restarted
160211 12:09:34 [Note] InnoDB: Using mutexes to ref count buffer pool pages
160211 12:09:34 [Note] InnoDB: The InnoDB memory heap is disabled
160211 12:09:34 [Note] InnoDB: Mutexes and rw_locks use GCC atomic builtins
160211 12:09:34 [Note] InnoDB: GCC builtin __sync_synchronize() is used for memory barrier
160211 12:09:34 [Note] InnoDB: Compressed tables use zlib 1.2.3
160211 12:09:34 [Note] InnoDB: Not using CPU crc32 instructions
160211 12:09:34 [Note] InnoDB: Initializing buffer pool, size = 128.0M
160211 12:09:35 [Note] InnoDB: Completed initialization of buffer pool
160211 12:09:35 [Note] InnoDB: Highest supported file format is Barracuda.
160211 12:09:35 [Note] InnoDB: Log scan progressed past the checkpoint lsn 31818497
160211 12:09:35 [Note] InnoDB: Database was not shutdown normally!
160211 12:09:35 [Note] InnoDB: Starting crash recovery.
160211 12:09:35 [Note] InnoDB: Reading tablespace information from the .ibd files...
160211 12:09:35 [Note] InnoDB: Restoring possible half-written data pages
160211 12:09:35 [Note] InnoDB: from the doublewrite buffer...
InnoDB: Doing recovery: scanned up to log sequence number 32140062
160211 12:09:36 [Note] InnoDB: Starting an apply batch of log records to the database...
InnoDB: Progress in percent: 54 55 56 57 58 59 60 61 62 63 64 65 66 67 68 69 70 71 72 73 74 75 76 77 78 79 80 81 82 83 84 85 86 87 88 89 90 91 92 93 94 95 96 97 98 99
InnoDB: Apply batch completed
InnoDB: Last MySQL binlog file position 0 2314577, file name ./binlog.000079
160211 12:09:36 [Note] InnoDB: 128 rollback segment(s) are active.
160211 12:09:36 [Note] InnoDB: Waiting for purge to start
160211 12:09:36 [Note] InnoDB: Percona XtraDB (http://www.percona.com) 5.6.22-71.0 started; log sequence number 32140062
160211 12:09:37 [Note] Recovering after a crash using binlog
160211 12:09:37 [Note] Starting crash recovery...
160211 12:09:37 [Note] Crash recovery finished.
160211 12:09:37 [Note] Server socket created on IP: '127.0.0.1'.
160211 12:09:37 [Note] Event Scheduler: Loaded 0 events
160211 12:09:37 [Note] /usr/local/libexec/mysqld: ready for connections.
Version: '10.0.16-MariaDB-log' socket: '/var/run/mysql/mysql.sock' port: 3306 OpenBSD port: mariadb-server-10.0.16v0
我没有用谷歌搜索 purge_sys->rseg->last_page_no != FIL_NULL 失败的断言。这是 MariaDB 的 /etc/my.cnf 文件：
[client]
port = 3306
socket = /var/run/mysql/mysql.sock
[mysqld]
port = 3306
socket = /var/run/mysql/mysql.sock
datadir = /var/mysql
max_allowed_packet = 128M
table_open_cache = 64
sort_buffer_size = 128K
read_buffer_size = 512K
net_buffer_length = 64K
server-id = 1
general-log = 1
general_log_file = query.log
log-error = error.log
slow-query-log = 1
long_query_time = 2
slow_query_log_file = slow_queries.log
bind-address = 127.0.0.1
log-bin = binlog
binlog_format = mixed
max_binlog_size = 512M
key_buffer_size = 2M
read_rnd_buffer_size = 1M
innodb_data_home_dir = /var/mysql/
innodb_log_group_home_dir = /var/mysql/
innodb_data_file_path = ibdata1:10M:autoextend
innodb_buffer_pool_size = 128M
innodb_log_file_size = 32M
innodb_log_buffer_size = 16M
innodb_lock_wait_timeout = 50
innodb_max_dirty_pages_pct = 1
[mysqldump]
quick
max_allowed_packet = 16M
[mysql]
no-auto-rehash
[mysqlhotcopy]
interactive-timeout
最初，其中一些参数设置为较低的值（仍在生产中 MySQL），但上述增加收效甚微：
net_buffer_length was 2K
max_allowed_packet was 1M
innodb_buffer_pool_size was 64M
innodb_log_file_size was 5M
innodb_log_buffer_size was 8M
此外，将 innodb_buffer_pool_size/innodb_log_file_size 增加到 256M/64M 似乎 post 稍微缓解了崩溃，但没有太大帮助。
除了将导入分成小块外，我不知道还能做什么。在我看来，这是一个非常小的导入文件。登台服务器是一个旧的 iBook（500mhz ppc），带有非 SSD 驱动器（3.3G 免费），但我没有注意到任何磁盘问题或高内存压力（top 报告 200+Mb 空闲 RAM）导入。
哪些 my.cnf 参数可能导致此崩溃？
编辑： 请求的超时信息：
MariaDB []> SHOW GLOBAL VARIABLES LIKE '%timeout';
+-----------------------------+----------+
| Variable_name | Value |
+-----------------------------+----------+
| connect_timeout | 10 |
| delayed_insert_timeout | 300 |
| innodb_flush_log_at_timeout | 1 |
| innodb_lock_wait_timeout | 50 |
| innodb_rollback_on_timeout | OFF |
| interactive_timeout | 28800 |
| lock_wait_timeout | 31536000 |
| net_read_timeout | 30 |
| net_write_timeout | 60 |
| slave_net_timeout | 3600 |
| thread_pool_idle_timeout | 60 |
| wait_timeout | 28800 |
+-----------------------------+----------+
看起来这可能是一个错误，可能与 OpenBSD/PowerPC 相关。已在此处向 MariaDB 开发人员报告：http://mariadb.atlassian.net/browse/MDEV-9569