[MDEV-9291] Parallel Slave SQL Thread Status Normal But not execute sql At Fusion-io Created: 2015-12-15  Updated: 2016-01-10  Resolved: 2016-01-10

Status: Closed
Project: MariaDB Server
Component/s: Replication
Affects Version/s: 10.0.22
Fix Version/s: N/A

Type: Bug Priority: Major
Reporter: sysdljr Assignee: Unassigned
Resolution: Duplicate Votes: 0
Labels: None
Environment:

CentOS 6.6, MariaDB Server 10.0.22 , Fusion-IO device


Attachments: Text File ShowEngineInnodbMutex.txt     Text File ShowEngineInnodbStatus.txt     Text File showallslavestatus.txt    
Issue Links:
Duplicate
duplicates MDEV-9230 mysql 5.6.22 mirgate to mariadb 10.0.... Closed

 Description   

Hi, All
When set slave_parallel_threads = 2 at Fusion-IO device, after 10 minutes, both slave io thead and sql thread status is normal , but Exec_Master_Log_Pos value not change,.
The Same slave database run normal at HDD , at the time , run stop slave sqlthread is Hang and not Error log .

kill -9 `pidof mysqld`
/etc/init.d/mysql start

error log :
151215 19:55:18 mysqld_safe Starting mysqld daemon with databases from /data/mysql/data
151215 19:55:18 [Note] /usr/sbin/mysqld (mysqld 10.0.22-MariaDB-log) starting as process 23665 ...
151215 19:55:19 [Note] InnoDB: Using mutexes to ref count buffer pool pages
151215 19:55:19 [Note] InnoDB: The InnoDB memory heap is disabled
151215 19:55:19 [Note] InnoDB: Mutexes and rw_locks use GCC atomic builtins
151215 19:55:19 [Note] InnoDB: Memory barrier is not used
151215 19:55:19 [Note] InnoDB: Compressed tables use zlib 1.2.3
151215 19:55:19 [Note] InnoDB: Using Linux native AIO
151215 19:55:19 [Note] InnoDB: Using CPU crc32 instructions
151215 19:55:19 [Note] InnoDB: Initializing buffer pool, size = 32.0G
151215 19:55:20 [Note] InnoDB: Completed initialization of buffer pool
151215 19:55:20 [Note] InnoDB: Opened 4 undo tablespaces
151215 19:55:20 [Note] InnoDB: Highest supported file format is Barracuda.
151215 19:55:20 [Note] InnoDB: The log sequence numbers 40295828165930 and 40295828165930 in ibdata files do not match the log sequence number 40312557761593 in the ib_logfiles!
151215 19:55:20 [Note] InnoDB: Database was not shutdown normally!
151215 19:55:20 [Note] InnoDB: Starting crash recovery.
151215 19:55:20 [Note] InnoDB: Reading tablespace information from the .ibd files...
151215 19:55:20 [Note] InnoDB: Restoring possible half-written data pages
151215 19:55:20 [Note] InnoDB: from the doublewrite buffer...
InnoDB: Last MySQL binlog file position 0 212127544, file name /data/mysql/log/mysql-bin.000046
151215 19:55:21 [Note] InnoDB: 128 rollback segment(s) are active.
151215 19:55:21 [Note] InnoDB: Waiting for purge to start
151215 19:55:21 [Note] InnoDB: Percona XtraDB (http://www.percona.com) 5.6.26-74.0 started; log sequence number 40312557761593
2015-12-15 19:55:21 7f2c663f9700 InnoDB: Loading buffer pool(s) from /data/mysql/data/ib_buffer_pool
151215 19:55:21 [Note] Plugin 'FEEDBACK' is disabled.
151215 19:55:21 server_audit: MariaDB Audit Plugin version 1.3.0 STARTED.
151215 19:55:21 [Note] Recovering after a crash using /data/mysql/log/mysql-bin
151215 19:55:21 [Note] Starting crash recovery...
151215 19:55:21 [Note] Crash recovery finished.
151215 19:55:21 [Note] /usr/sbin/mysqld: ready for connections.
Version: '10.0.22-MariaDB-log' socket: '/data/mysql/data/mysql.sock' port: 3306 MariaDB Server

attach file:
show engine innodb status, show engine innodb mutex, show slave status



 Comments   
Comment by Elena Stepanova [ 2016-01-08 ]

Is it not the same problem as MDEV-9230? There you also have a parallel replication, Fusion IO, non-changing Exec_Master_Log_Pos.

Comment by sysdljr [ 2016-01-08 ]

yes, I have a parallel replication at Fusion IO, and non-changing Exec_Master_Log_Pos. too.

now, we cancel parallel , set slave_parallel_thread =0, Exec_Master_Log_Pos change normal.

Comment by Elena Stepanova [ 2016-01-08 ]

So, can we consider this to be a duplicate of MDEV-9230, and continue work in the scope of MDEV-9230?

Comment by sysdljr [ 2016-01-10 ]

yes,

Generated at Thu Feb 08 07:33:34 UTC 2024 using Jira 8.20.16#820016-sha1:9d11dbea5f4be3d4cc21f03a88dd11d8c8687422.