Bug #91008 mysql stop for multi-threaded slave gives error code 1756
Submitted: 24 May 2018 11:03 Modified: 19 Jul 2018 8:24
Reporter: Prasad N Email Updates:
Status: Not a Bug Impact on me:
None 
Category:MySQL Server: Replication Severity:S2 (Serious)
Version:5.7.21 OS:CentOS (CentOS (2.6.32-696.23.1.el6.x86_64 ))
Assigned to: Bogdan Kecman CPU Architecture:x86
Tags: MTS, slave

[24 May 2018 11:03] Prasad N
Description:
On stopping the mysql server that is running multi-threaded slave, I am seeing the following message in the error log:
[ERROR] Slave SQL for channel '': ... The slave coordinator and worker threads are stopped, possibly leaving data in inconsistent state. A restart should restore consistency automatically, although using non-transactional storage for data or info tables or DDL queries could lead to problems. In such cases you have to examine your data (see documentation for details). Error_code: 1756

How to repeat:
Multi threaded slave configured with 30 worker threads doing asynchronous replication .
Master has continuous writes - 30 client threads inserting data into a table with 2 columns .

stop the the slave mysql server [ may have to repeat start and stop few time]

Seeing the above error message.

my.cnf file:

[mysqld]

port=3306
skip_name_resolve=1
bind_address=0.0.0.0
user=mysql
pid_file=/var/run/mysqld/mysqld.pid
socket=/var/lib/mysql/mysql.sock
server_id=137
require_secure_transport=OFF
log_bin=mysql-bin
expire_logs_days=21
sync_binlog=1
innodb_log_files_in_group=2
innodb_flush_log_at_trx_commit=1
max_connect_errors=1000000
max_allowed_packet=16777216
max_heap_table_size=33554432
max_connections=60
max_user_connections=48
thread_cache_size=50
open_files_limit=65535
table_open_cache=2048
table_definition_cache=2048
relay_log=relay-log-slave
gtid_mode=ON
enforce_gtid_consistency=ON
binlog_format=MIXED
log_slave_updates=true
slave_net_timeout=60
master_info_repository=TABLE
relay_log_info_repository=TABLE
sync_master_info=10000
sync_relay_log=10000
relay_log_recovery=1
slave_parallel_workers=30
slave_preserve_commit_order=1
slave_parallel_type=LOGICAL_CLOCK
relay_log_space_limit=0
max_relay_log_size=0
max_binlog_size=1073741824
datadir=/mysql_data/mysql
general_log=ON
general_log_file=/var/log/mysql/general.log
log_error=/var/log/mysql/mysqld.log
default_storage_engine=innodb
innodb_flush_method=O_DIRECT
innodb_file_per_table=ON
innodb_log_file_size=134217728
innodb_buffer_pool_size=134217728
innodb_io_capacity=200
innodb_adaptive_hash_index=ON
innodb_lock_wait_timeout=50
log_queries_not_using_indexes=OFF
log_slow_admin_statements=OFF
log_throttle_queries_not_using_indexes=0
long_query_time=10
slow_query_log=ON
slow_query_log_file=/var/log/mysql/mysql-slowquery.log
symbolic_links=0
interactive_timeout=28800
div_precision_increment=4
sql_mode="ONLY_FULL_GROUP_BY,STRICT_ALL_TABLES,NO_ZERO_IN_DATE,NO_ZERO_DATE,ERROR_FOR_DIVISION_BY_ZERO,NO_AUTO_CREATE_USER,NO_ENGINE_SUBSTITUTION"
event_scheduler=OFF

Suggested fix:
Ensure there is no data inconsistency as this is a clean shutdown.
[19 Jul 2018 8:24] Bogdan Kecman
Hi,
I don't believe this is a bug. It would be a bug if a start would not solve the issue but since the system will autocorrect when you start it... it's a design choice.

If you want consistent data in the slave you should stop replication before you do shutdown.

all best
Bogdan