Details
-
Bug
-
Status: Closed (View Workflow)
-
Critical
-
Resolution: Fixed
-
10.0(EOL), 10.1(EOL), 10.2(EOL), 10.3(EOL), 10.4(EOL), 10.5, 10.6, 10.7(EOL)
Description
Temporary tables require strict single-threaded operation, there is no locking protecting concurrent access. For this reason, they are considered non-transactional for the purpose of parallel replication.
However, even non-transactional event groups have an optimisation that allow part of the commit of such event groups to run in parallel with following event groups. Thus, it was still possible for part of the commit codepath to run in parallel with another operation on the temporary table such as a SELECT or DML or even a DROP TEMPORARY TABLE. This can cause access of freed memory and probably other nasty effects.
The problem is the mark_start_commit() in handle_rpl_parallel_thread() just before the COMMIT event is applied, as well as calls of wakeup_subsequent_commit() in the binlog code and in innobase_commit(). These are too early at these points when temporary tables are replicated.
Since temporary table operations are not binlogged in MIXED or ROW mode, this problem affects only statement-based replication.
This is seen as occasional test failures of rpl.rpl_parallel_temptable as reported by Elena and others:
http://buildbot.askmonty.org/buildbot/builders/kvm-fulltest2/builds/5564/steps/test_6/logs/stdio
rpl.rpl_parallel_temptable 'innodb_plugin,stmt' w1 [ fail ]
|
Test ended at 2016-07-09 07:04:06
|
|
|
CURRENT_TEST: rpl.rpl_parallel_temptable
|
mysqltest: At line 132: failed in 'select master_pos_wait('master-bin.000002', 558, 300, '')': 2013: Lost connection to MySQL server during query
|
|
|
The result from queries just before the failure was:
|
< snip >
|
INSERT INTO t2 VALUES (13);
|
INSERT INTO t3 SELECT a+32 FROM t4;
|
INSERT INTO t2 VALUES (14);
|
INSERT INTO t2 VALUES (15);
|
INSERT INTO t2 VALUES (16);
|
INSERT INTO t4 SELECT a+64 FROM t3;
|
INSERT INTO t2 VALUES (17);
|
INSERT INTO t2 VALUES (18);
|
INSERT INTO t2 VALUES (19);
|
INSERT INTO t3 SELECT a+128 FROM t4;
|
INSERT INTO t2 VALUES (20);
|
INSERT INTO t1 SELECT a, a MOD 7 FROM t3;
|
INSERT INTO t1 SELECT a, a MOD 7 FROM t4;
|
INSERT INTO t1 SELECT a, COUNT(*) FROM t2 GROUP BY a;
|
FLUSH TABLES;
|
SET SESSION debug_dbug="+d,crash_dispatch_command_before";
|
SELECT 1;
|
Got one of the listed errors
|
INSERT INTO t1 VALUES (0, 1);
|
include/start_slave.inc
|
|
|
More results from queries before failure can be found in /mnt/buildbot/build/mariadb-10.1.16/mysql-test/var/1/log/rpl_parallel_temptable.log
|
|
|
|
|
Server [mysqld.2 - pid: 26230, winpid: 26230, exit: 256] failed during test run
|
Server log from this test:
|
----------SERVER LOG START-----------
|
2016-07-09 7:03:47 3077719808 [Note] /mnt/buildbot/build/mariadb-10.1.16/sql/mysqld (mysqld 10.1.16-MariaDB-debug) starting as process 26231 ...
|
2016-07-09 7:03:47 3077719808 [Warning] Could not increase number of max_open_files to more than 1024 (request: 4162)
|
2016-07-09 7:03:47 3077719808 [Note] Plugin 'file_key_management' is disabled.
|
2016-07-09 7:03:47 3077719808 [Note] Plugin 'BLACKHOLE' is disabled.
|
2016-07-09 7:03:47 3077719808 [Note] Plugin 'partition' is disabled.
|
2016-07-09 7:03:47 3077719808 [Note] Plugin 'ARCHIVE' is disabled.
|
2016-07-09 7:03:48 3077719808 [Note] InnoDB: Using mutexes to ref count buffer pool pages
|
2016-07-09 7:03:48 3077719808 [Note] InnoDB: InnoDB: !!!!!!!! UNIV_DEBUG switched on !!!!!!!!!
|
2016-07-09 7:03:48 3077719808 [Note] InnoDB: InnoDB: !!!!!!!! UNIV_SYNC_DEBUG switched on !!!!!!!!!
|
2016-07-09 7:03:48 3077719808 [Note] InnoDB: The InnoDB memory heap is disabled
|
2016-07-09 7:03:48 3077719808 [Note] InnoDB: Mutexes and rw_locks use GCC atomic builtins
|
2016-07-09 7:03:48 3077719808 [Note] InnoDB: Memory barrier is not used
|
2016-07-09 7:03:48 3077719808 [Note] InnoDB: Compressed tables use zlib 1.2.3.4
|
2016-07-09 7:03:48 3077719808 [Note] InnoDB: Using Linux native AIO
|
2016-07-09 7:03:48 3077719808 [Note] InnoDB: Using generic crc32 instructions
|
2016-07-09 7:03:48 3077719808 [Note] InnoDB: Initializing buffer pool, size = 8.0M
|
2016-07-09 7:03:48 3077719808 [Note] InnoDB: Completed initialization of buffer pool
|
2016-07-09 7:03:48 3077719808 [Note] InnoDB: Highest supported file format is Barracuda.
|
2016-07-09 7:03:49 3077719808 [Note] InnoDB: 128 rollback segment(s) are active.
|
2016-07-09 7:03:49 3077719808 [Note] InnoDB: Waiting for purge to start
|
2016-07-09 7:03:49 3077719808 [Note] InnoDB: 5.6.31 started; log sequence number 1629517
|
2016-07-09 7:03:49 2858416960 [Note] InnoDB: Dumping buffer pool(s) not yet started
|
2016-07-09 7:03:49 3077719808 [Note] Plugin 'TEST_SQL_DISCOVERY' is disabled.
|
2016-07-09 7:03:49 3077719808 [Note] Plugin 'CONNECT' is disabled.
|
2016-07-09 7:03:49 3077719808 [Note] Plugin 'SPHINX' is disabled.
|
2016-07-09 7:03:49 3077719808 [Note] Plugin 'SEQUENCE' is disabled.
|
2016-07-09 7:03:49 3077719808 [Note] Plugin 'FEDERATED' is disabled.
|
2016-07-09 7:03:49 3077719808 [Note] Plugin 'INNODB_SYS_DATAFILES' is disabled.
|
2016-07-09 7:03:49 3077719808 [Note] Plugin 'INNODB_SYS_TABLESTATS' is disabled.
|
2016-07-09 7:03:49 3077719808 [Note] Plugin 'XTRADB_READ_VIEW' is disabled.
|
2016-07-09 7:03:49 3077719808 [Note] Plugin 'XTRADB_RSEG' is disabled.
|
2016-07-09 7:03:49 3077719808 [Note] Plugin 'CHANGED_PAGE_BITMAPS' is disabled.
|
2016-07-09 7:03:49 3077719808 [Note] Plugin 'QUERY_CACHE_INFO' is disabled.
|
2016-07-09 7:03:49 3077719808 [Note] Plugin 'INNODB_LOCK_WAITS' is disabled.
|
2016-07-09 7:03:49 3077719808 [Note] Plugin 'INNODB_TABLESPACES_ENCRYPTION' is disabled.
|
2016-07-09 7:03:49 3077719808 [Note] Plugin 'INNODB_SYS_FIELDS' is disabled.
|
2016-07-09 7:03:49 3077719808 [Note] Plugin 'INNODB_TABLESPACES_SCRUBBING' is disabled.
|
2016-07-09 7:03:49 3077719808 [Note] Plugin 'INNODB_FT_INDEX_TABLE' is disabled.
|
2016-07-09 7:03:49 3077719808 [Note] Plugin 'XTRADB_INTERNAL_HASH_TABLES' is disabled.
|
2016-07-09 7:03:49 3077719808 [Note] Plugin 'INNODB_MUTEXES' is disabled.
|
2016-07-09 7:03:49 3077719808 [Note] Plugin 'INNODB_CMPMEM_RESET' is disabled.
|
2016-07-09 7:03:49 3077719808 [Note] Plugin 'FEEDBACK' is disabled.
|
2016-07-09 7:03:49 3077719808 [Note] Plugin 'METADATA_LOCK_INFO' is disabled.
|
2016-07-09 7:03:49 3077719808 [Note] Plugin 'INNODB_CMP' is disabled.
|
2016-07-09 7:03:49 3077719808 [Note] Plugin 'INNODB_FT_DEFAULT_STOPWORD' is disabled.
|
2016-07-09 7:03:49 3077719808 [Note] Plugin 'INNODB_CMP_RESET' is disabled.
|
2016-07-09 7:03:49 3077719808 [Note] Plugin 'QUERY_RESPONSE_TIME' is disabled.
|
2016-07-09 7:03:49 3077719808 [Note] Plugin 'INNODB_FT_INDEX_CACHE' is disabled.
|
2016-07-09 7:03:49 3077719808 [Note] Plugin 'INNODB_FT_BEING_DELETED' is disabled.
|
2016-07-09 7:03:49 3077719808 [Note] Plugin 'INNODB_CMP_PER_INDEX_RESET' is disabled.
|
2016-07-09 7:03:49 3077719808 [Note] Plugin 'INNODB_SYS_SEMAPHORE_WAITS' is disabled.
|
2016-07-09 7:03:49 3077719808 [Note] Plugin 'INNODB_SYS_COLUMNS' is disabled.
|
2016-07-09 7:03:49 3077719808 [Note] Plugin 'INNODB_FT_CONFIG' is disabled.
|
2016-07-09 7:03:49 3077719808 [Note] Plugin 'INNODB_SYS_TABLESPACES' is disabled.
|
2016-07-09 7:03:49 3077719808 [Note] Plugin 'INNODB_FT_DELETED' is disabled.
|
2016-07-09 7:03:49 3077719808 [Note] Plugin 'INNODB_SYS_INDEXES' is disabled.
|
2016-07-09 7:03:49 3077719808 [Note] Plugin 'LOCALES' is disabled.
|
2016-07-09 7:03:49 3077719808 [Note] Plugin 'unix_socket' is disabled.
|
2016-07-09 7:03:49 3077719808 [Note] Plugin 'QUERY_RESPONSE_TIME_AUDIT' is disabled.
|
2016-07-09 7:03:49 3077719808 [Note] Plugin 'rpl_semi_sync_slave' is disabled.
|
2016-07-09 7:03:49 3077719808 [Note] Plugin 'rpl_semi_sync_master' is disabled.
|
2016-07-09 7:03:49 3077719808 [Warning] /mnt/buildbot/build/mariadb-10.1.16/sql/mysqld: unknown option '--loose-skip-plugin-innodb-changed-pages'
|
2016-07-09 7:03:49 3077719808 [Note] Server socket created on IP: '127.0.0.1'.
|
2016-07-09 7:03:49 3077719808 [Note] /mnt/buildbot/build/mariadb-10.1.16/sql/mysqld: ready for connections.
|
Version: '10.1.16-MariaDB-debug' socket: '/mnt/buildbot/build/mariadb-10.1.16/mysql-test/var/tmp/1/mysqld.2.sock' port: 16041 Source distribution
|
2016-07-09 7:03:50 2918969152 [Note] 'CHANGE MASTER TO executed'. Previous state master_host='', master_port='3306', master_log_file='', master_log_pos='4'. New state master_host='127.0.0.1', master_port='16040', master_log_file='master-bin.000001', master_log_pos='4'.
|
2016-07-09 7:03:50 2872782656 [Note] Slave I/O thread: connected to master 'root@127.0.0.1:16040',replication started in log 'master-bin.000001' at position 4
|
2016-07-09 7:03:50 2872479552 [Note] Slave SQL thread initialized, starting replication in log 'master-bin.000001' at position 4, relay log './slave-relay-bin.000001' position: 4
|
2016-07-09 7:03:51 2872479552 [Note] Error reading relay log event: slave SQL thread was killed
|
2016-07-09 7:03:51 2872782656 [ERROR] Error reading packet from server: Lost connection to MySQL server during query ( server_errno=2013)
|
2016-07-09 7:03:51 2872782656 [Note] Slave I/O thread exiting, read up to log 'master-bin.000001', position 314
|
2016-07-09 7:03:51 2918969152 [Note] 'CHANGE MASTER TO executed'. Previous state master_host='127.0.0.1', master_port='16040', master_log_file='master-bin.000001', master_log_pos='314'. New state master_host='127.0.0.1', master_port='16040', master_log_file='master-bin.000001', master_log_pos='314'.
|
2016-07-09 7:03:51 2918969152 [Note] Previous Using_Gtid=No. New Using_Gtid=Current_Pos
|
2016-07-09 7:03:51 2872479552 [Note] Slave I/O thread: connected to master 'root@127.0.0.1:16040',replication starts at GTID position ''
|
2016-07-09 7:03:51 2824539968 [Note] Slave SQL thread initialized, starting replication in log 'master-bin.000001' at position 314, relay log './slave-relay-bin.000001' position: 4; GTID position ''
|
2016-07-09 7:03:51 2824539968 [Note] Error reading relay log event: slave SQL thread was killed
|
2016-07-09 7:03:51 2872479552 [ERROR] Error reading packet from server: Lost connection to MySQL server during query ( server_errno=2013)
|
2016-07-09 7:03:51 2872479552 [Note] Slave I/O thread exiting, read up to log 'master-bin.000001', position 485; GTID position 0-1-1
|
2016-07-09 7:03:56 2824539968 [Note] Slave I/O thread: connected to master 'root@127.0.0.1:16040',replication starts at GTID position '0-1-1'
|
2016-07-09 7:03:56 2862300992 [Note] Slave SQL thread initialized, starting replication in log 'master-bin.000001' at position 485, relay log './slave-relay-bin.000001' position: 4; GTID position '0-1-1'
|
160709 7:03:56 [ERROR] mysqld got signal 11 ;
|
This could be because you hit a bug. It is also possible that this binary
|
or one of the libraries it was linked against is corrupt, improperly built,
|
or misconfigured. This error can also be caused by malfunctioning hardware.
|
|
|
To report this bug, see https://mariadb.com/kb/en/reporting-bugs
|
|
|
We will try our best to scrape up some info that will hopefully help
|
diagnose the problem, but since we have already crashed,
|
something is definitely wrong and this may fail.
|
|
|
Server version: 10.1.16-MariaDB-debug
|
key_buffer_size=1048576
|
read_buffer_size=131072
|
max_used_connections=2
|
max_threads=153
|
thread_count=2
|
It is possible that mysqld could use up to
|
key_buffer_size + (read_buffer_size + sort_buffer_size)*max_threads = 61813 K bytes of memory
|
Hope that's ok; if not, decrease some variables in the equation.
|
|
|
Thread pointer: 0x0xaa800670
|
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...
|
stack_bottom = 0xaa9696b8 thread_stack 0x48400
|
/mnt/buildbot/build/mariadb-10.1.16/sql/mysqld(my_print_stacktrace+0x29)[0x8b0fe39]
|
/mnt/buildbot/build/mariadb-10.1.16/sql/mysqld(handle_fatal_signal+0x53c)[0x8438b4c]
|
[0xe9b400]
|
/mnt/buildbot/build/mariadb-10.1.16/sql/mysqld(_Z19close_thread_tablesP3THD+0x48f)[0x81f7c3f]
|
/mnt/buildbot/build/mariadb-10.1.16/sql/mysqld(_Z21mysql_execute_commandP3THD+0x45b)[0x825582b]
|
/mnt/buildbot/build/mariadb-10.1.16/sql/mysqld(_Z11mysql_parseP3THDPcjP12Parser_state+0x36c)[0x8261b2c]
|
/mnt/buildbot/build/mariadb-10.1.16/sql/mysqld(_ZN15Query_log_event14do_apply_eventEP14rpl_group_infoPKcj+0xcef)[0x8540d3f]
|
/mnt/buildbot/build/mariadb-10.1.16/sql/mysqld(_ZN15Query_log_event14do_apply_eventEP14rpl_group_info+0x31)[0x8542031]
|
/mnt/buildbot/build/mariadb-10.1.16/sql/mysqld(_Z26apply_event_and_update_posP9Log_eventP3THDP14rpl_group_infoP19rpl_parallel_thread+0x63d)[0x81c41ad]
|
/mnt/buildbot/build/mariadb-10.1.16/sql/mysqld[0x83ad240]
|
/mnt/buildbot/build/mariadb-10.1.16/sql/mysqld(handle_rpl_parallel_thread+0x99b)[0x83b1e4b]
|
/mnt/buildbot/build/mariadb-10.1.16/sql/mysqld[0x8619a8a]
|
/lib/i386-linux-gnu/libpthread.so.0(+0x6d4c)[0x1a3d4c]
|
/lib/i386-linux-gnu/libc.so.6(clone+0x5e)[0xa38ace]
|
|
|
Trying to get some variables.
|
Some pointers may be invalid and cause the dump to abort.
|
Query (0xb2d12cd3): COMMIT
|
Connection ID (thread ID): 18
|
Status: NOT_KILLED
|
|
|
Optimizer switch: index_merge=on,index_merge_union=on,index_merge_sort_union=on,index_merge_intersection=on,index_merge_sort_intersection=off,engine_condition_pushdown=off,index_condition_pushdown=on,derived_merge=on,derived_with_keys=on,firstmatch=on,loosescan=on,materialization=on,in_to_exists=on,semijoin=on,partial_match_rowid_merge=on,partial_match_table_scan=on,subquery_cache=on,mrr=off,mrr_cost_based=off,mrr_sort_keys=off,outer_join_with_cache=on,semijoin_with_cache=on,join_cache_incremental=on,join_cache_hashed=on,join_cache_bka=on,optimize_join_buffer_size=off,table_elimination=on,extended_keys=on,exists_to_in=on,orderby_uses_equalities=off
|
|
|
The manual page at http://dev.mysql.com/doc/mysql/en/crashing.html contains
|
information that should help you find out what is causing the crash.
|
Writing a core file
|
It happens very rarely in buildbot, a handful of occasions over 2 years.
It's possible that the failure is caused by the same problem as was recently fixed in MDEV-10219, but then the fix needs to be backported into 10.1 and possibly 10.0.
Attachments
Issue Links
- blocks
-
MDEV-7069 Fix buildbot failures in main server trees
-
- Stalled
-
- is duplicated by
-
-
- Closed
-
- relates to
-
-
- Open
-
-
-
- Confirmed
-
-
-
- Closed
-
-
-
- Open
-
-
-
- Closed
-
Activity
Andrei, please have someone create a test case to prove/disapprove Marko statement and also if it could be the cause of the problem.
"Starting with MariaDB Server 10.2.2, InnoDB assumes that temporary tables are private to the connection that created the table. In MDEV-25064, we have direct evidence that parallel replication is executing CREATE TEMPORARY TABLE in one thread, executing a transaction on the temporary table in another thread, and executing DROP TEMPORARY TABLE in yet another thread (while the transaction that is using the temporary table is still active)."
Execution of temporary tables transaction on the slave cannot be done in parallel.
In theory it should work that CRETATE/DROP is done by different threads as long as the DROP is scheduled to be
done after any transaction.
Note that there are no MDL locks on temporary tables, so replication needs to ensure that there are no concurrent usage of the temporary table.
As a transaction can in theory use multiple temporary tables, possible created by different threads, it is not possible to schedule the query to the original thread. This means that any solution has to depend on that any queries using temporary table queries are executed strictly in order.
I think I understand the problem here, which seems to be a real bug in parallel replication and statement-based replication with temporary tables.
Temporary tables are binlogged as non-transactional. Parallel replication will wait for all prior transactions to commit before starting such event groups. This means that each temporary table query will complete before the next one starts. This is intended to make temporary tables safe for parallel replication.
But in the stack traces for the crashes during STOP SLAVE, I see a problem. There is a non-transactional INSERT SELECT followed by a DDL DROP TEMPORARY TABLE. As an optimization, the DDL is allowed to start as soon as the the INSERT...SELECT starts to commit. That means that innobase_commit() can run in parallel with DROP TABLE. The problem is the call of mark_start_commit() in handle_rpl_parallel_thread().
There may be a similar problem that the COMMIT of one temptable transaction can run in parallel with the following (non-DDL) query, due to the call of thd_wakeup_subsequent_commits() in innobase_commit(). I will need to analyze further to know for sure.
I was not so far able to reproduce the crash, I will need more time to do so. But it seems clear that the problem described above is real, and very likely that it is the cause of these test failures.
I'm not yet sure of the correct way to fix this, will need to think on it. The optimisations to overlap part of the commit of one transaction with the following transaction or DDL is very important for performance, while statement-based parallel replication of temporary tables is not an important use case. So we need to find a solution that solves the problem and makes temptables safe for statement-based without regressing the performance of other workloads. (In mixed mode binlogging, this problem does not occur).
knielsen, I tested your 10.6 patch on top of my current local 10.6 branch (some changes on top of what I tested in MDEV-25064 yesterday). I can reproduce the test failure without the patch, and can’t with the patch. Great work!
julien.fritsch, the same comments apply here. The ticket can't relate to the support issue.
Instead of to set to NEED_FEEDBACK (as it was going to be done to
MDEV-25064and which looks as a duplicate but I can't confirm) I just removed the CS reference.