mysql - MariaDB 10.0.16 在导入 MySQL 5.1.70 转储期间崩溃

Question

我有一个小型 MySQL 5.1.70 InnoDB 数据库:4 个表； ~3K、~23K、~500K、~600K 行。它在 OpenBSD 5.4 上运行。

我正在升级到 OpenBSD 5.7，它将切换到 MariaDB 10.0.16(据我所知，它反向移植了 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

转储包含文本/数字，没有 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->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 似乎可以稍微延迟崩溃，但没有显着帮助。

除了将导入分成小块之外，我不知道还能做什么。在我看来，这是一个非常小的导入文件。登台服务器是一台旧的 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    |
    +-----------------------------+----------+

Answer 1

看起来这可能是一个错误，可能与 OpenBSD/PowerPC 相关。已向 MariaDB 开发人员报告:http://mariadb.atlassian.net/browse/MDEV-9569