MySQL导入Innodb表在某一点上会出现严重的峰值
我正在尝试将30GB数据库从一台服务器迁移到另一台服务器 简单地说,在整个过程的某一点上,导入记录所需的时间会随着峰值的增加而急剧增加。下面是使用SOURCE命令导入500k条记录(整个数据库中约有2500-3000万条记录),这些记录作为sql文件导出,并通过ssh隧道传输到新服务器:MySQL导入Innodb表在某一点上会出现严重的峰值,mysql,database,innodb,mysqldump,server,Mysql,Database,Innodb,Mysqldump,Server,我正在尝试将30GB数据库从一台服务器迁移到另一台服务器 简单地说,在整个过程的某一点上,导入记录所需的时间会随着峰值的增加而急剧增加。下面是使用SOURCE命令导入500k条记录(整个数据库中约有2500-3000万条记录),这些记录作为sql文件导出,并通过ssh隧道传输到新服务器: ... Query OK, 2871 rows affected (0.73 sec) Records: 2871 Duplicates: 0 Warnings: 0 Query OK, 2870 ro
...
Query OK, 2871 rows affected (0.73 sec)
Records: 2871 Duplicates: 0 Warnings: 0
Query OK, 2870 rows affected (0.98 sec)
Records: 2870 Duplicates: 0 Warnings: 0
Query OK, 2865 rows affected (0.80 sec)
Records: 2865 Duplicates: 0 Warnings: 0
Query OK, 2871 rows affected (0.87 sec)
Records: 2871 Duplicates: 0 Warnings: 0
Query OK, 2864 rows affected (2.60 sec)
Records: 2864 Duplicates: 0 Warnings: 0
Query OK, 2866 rows affected (7.53 sec)
Records: 2866 Duplicates: 0 Warnings: 0
Query OK, 2879 rows affected (8.70 sec)
Records: 2879 Duplicates: 0 Warnings: 0
Query OK, 2864 rows affected (7.53 sec)
Records: 2864 Duplicates: 0 Warnings: 0
Query OK, 2873 rows affected (10.06 sec)
Records: 2873 Duplicates: 0 Warnings: 0
...
每受影响的2800行,峰值最终平均为16-18秒。虽然我通常不使用Source进行大规模导入,但为了显示合法的输出,我使用它来了解峰值何时发生。使用mysql命令或mysqlimport可以得到相同的结果。即使将结果直接传输到新数据库而不是通过sql文件,也会出现这些峰值
据我所知,这是在将一定数量的记录插入表之后发生的。当我第一次启动服务器并导入一个如此大小的块时,它运行得很好。给出或获取估计的处理量,直到这些峰值出现。我不能把这两者联系起来,因为我没有一贯地复制这个问题来得出明显的结论。大约有20个表的记录少于500000条,当通过一个命令导入这20个表时,这些记录都导入得很好。这似乎只发生在数据量过多的表上。诚然,到目前为止,我遇到的解决方案似乎只解决了随着时间的推移导入时发生的自然灾难恢复(在我的案例中,预期的结果是最终导入500k记录时,每2800条记录需要2-3秒,而问题似乎解决了,最后不应该花那么长的时间)。这来自一个名为“campaign_log”的sugarCRM表,该表有约900万条记录。我能够将500k的数据块导入到我正在迁移的旧服务器上,而不会出现这些峰值,因此我认为这与我的新服务器配置有关。另一件事是,每当出现这些峰值时,导入到的表似乎有一种通过计数显示记录数的笨拙方式。我知道InnoDB给出了计数估计值,但数字没有成功~,表示估计值。它通常是准确的,并且每次刷新表时,它都不会更改它显示的量(这取决于它通过PHPMyAdmin报告的内容)
以下是我在新服务器上的以下命令/InnoDB系统变量:
...
Query OK, 2871 rows affected (0.73 sec)
Records: 2871 Duplicates: 0 Warnings: 0
Query OK, 2870 rows affected (0.98 sec)
Records: 2870 Duplicates: 0 Warnings: 0
Query OK, 2865 rows affected (0.80 sec)
Records: 2865 Duplicates: 0 Warnings: 0
Query OK, 2871 rows affected (0.87 sec)
Records: 2871 Duplicates: 0 Warnings: 0
Query OK, 2864 rows affected (2.60 sec)
Records: 2864 Duplicates: 0 Warnings: 0
Query OK, 2866 rows affected (7.53 sec)
Records: 2866 Duplicates: 0 Warnings: 0
Query OK, 2879 rows affected (8.70 sec)
Records: 2879 Duplicates: 0 Warnings: 0
Query OK, 2864 rows affected (7.53 sec)
Records: 2864 Duplicates: 0 Warnings: 0
Query OK, 2873 rows affected (10.06 sec)
Records: 2873 Duplicates: 0 Warnings: 0
...
INNODB系统变量:
+---------------------------------+------------------------+
| Variable_name | Value |
+---------------------------------+------------------------+
| have_innodb | YES |
| ignore_builtin_innodb | OFF |
| innodb_adaptive_flushing | ON |
| innodb_adaptive_hash_index | ON |
| innodb_additional_mem_pool_size | 8388608 |
| innodb_autoextend_increment | 8 |
| innodb_autoinc_lock_mode | 1 |
| innodb_buffer_pool_instances | 1 |
| innodb_buffer_pool_size | 8589934592 |
| innodb_change_buffering | all |
| innodb_checksums | ON |
| innodb_commit_concurrency | 0 |
| innodb_concurrency_tickets | 500 |
| innodb_data_file_path | ibdata1:10M:autoextend |
| innodb_data_home_dir | |
| innodb_doublewrite | ON |
| innodb_fast_shutdown | 1 |
| innodb_file_format | Antelope |
| innodb_file_format_check | ON |
| innodb_file_format_max | Antelope |
| innodb_file_per_table | OFF |
| innodb_flush_log_at_trx_commit | 1 |
| innodb_flush_method | fsync |
| innodb_force_load_corrupted | OFF |
| innodb_force_recovery | 0 |
| innodb_io_capacity | 200 |
| innodb_large_prefix | OFF |
| innodb_lock_wait_timeout | 50 |
| innodb_locks_unsafe_for_binlog | OFF |
| innodb_log_buffer_size | 8388608 |
| innodb_log_file_size | 5242880 |
| innodb_log_files_in_group | 2 |
| innodb_log_group_home_dir | ./ |
| innodb_max_dirty_pages_pct | 75 |
| innodb_max_purge_lag | 0 |
| innodb_mirrored_log_groups | 1 |
| innodb_old_blocks_pct | 37 |
| innodb_old_blocks_time | 0 |
| innodb_open_files | 300 |
| innodb_print_all_deadlocks | OFF |
| innodb_purge_batch_size | 20 |
| innodb_purge_threads | 1 |
| innodb_random_read_ahead | OFF |
| innodb_read_ahead_threshold | 56 |
| innodb_read_io_threads | 8 |
| innodb_replication_delay | 0 |
| innodb_rollback_on_timeout | OFF |
| innodb_rollback_segments | 128 |
| innodb_spin_wait_delay | 6 |
| innodb_stats_method | nulls_equal |
| innodb_stats_on_metadata | ON |
| innodb_stats_sample_pages | 8 |
| innodb_strict_mode | OFF |
| innodb_support_xa | ON |
| innodb_sync_spin_loops | 30 |
| innodb_table_locks | ON |
| innodb_thread_concurrency | 0 |
| innodb_thread_sleep_delay | 10000 |
| innodb_use_native_aio | ON |
| innodb_use_sys_malloc | ON |
| innodb_version | 5.5.39 |
| innodb_write_io_threads | 8 |
+---------------------------------+------------------------+
系统规格:
Intel Xeon E5-2680 v2 (Ivy Bridge) 8 Processors
15GB Ram
2x80 SSDs
要导出的命令:
mysqldump -u <olduser> <oldpw>, <olddb> <table> --verbose --disable-keys --opt | ssh -i <privatekey> <newserver> "cat > <nameoffile>"
mysqldump-u,--verbose--disable key--opt | ssh-i“cat>”
谢谢你的帮助。如果我能提供任何其他信息,请告诉我。我找到了。我将innodb_日志_文件大小从5MB增加到1024MB。虽然它确实显著增加了我导入的记录数量(从未超过每3000行1秒),但它也修复了峰值。在我导入的所有记录中只有2条,但在它们发生后,它们立即返回到1秒以下