我有一个小的MySQL 5.1.70 InnoDB数据库：4个表; ~3K，~23K，~500K，~600K行。这适用于OpenBSD 5.4。
我正在升级到OpenBSD 5.7，切换到MariaDB 10.0.16（AFAIK后端MySQL 5.6功能）。为此我构建了一个小型的OpenBSD 5.7 / MariaDB服务器，以便我可以测试升级。我重新创建了db模式以匹配prod，并运行mysql_upgrade --force只是为了安全。
现在我想用prod数据填充它。我倾倒了数据：
$ 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
转储包含文本/数字，没有blob或二进制文件。 问题是MariaDB在导入转储中的第一个表时会随机中止，这只是~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，与之前的数千个没有什么不同。实际上重复导入（在截断表并确保服务器启动之后）不会在同一行崩溃。我看到它在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-＆gt; rseg-＆gt; 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
最初这些参数中的一些被设置为较低的值（仍然在prod 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似乎稍稍发生了崩溃，但没有显着帮助。
如果没有将导入分成小块，我不知道还能做什么。在我看来，这是一个非常小的导入文件。登台服务器是旧的iBook（500mhz ppc），带有非SSD驱动器（3.3G免费），但我没有发现任何磁盘问题或高内存压力（top报告200 + Mb空闲RAM）导入。
my.cnf params会导致这次崩溃？
编辑： 请求的超时信息：
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 |
+-----------------------------+----------+
答案 0 :(得分：0)
看起来这可能是一个bug，也许与OpenBSD / PowerPC相关。已向MariaDB开发人员报告：http://mariadb.atlassian.net/browse/MDEV-9569