Channel based replication thread conflicts with Default Channel.
Hi All,
I am trying to set up a multi-channel replication with 2 Masters feeding one Slave.
If I manually start each channel using 'Start slave for channel 'slave1/2'; everything is fine.
But if the server reboots, or I just issue a normal "START SLAVE;' command, it seems like the original default channel still tries to launch. This then causes a conflict where either itself or one of the channel threads will error out.
SELECT * FROM replication_connection_status\G;
*************************** 1. row ***************************
CHANNEL_NAME:
GROUP_NAME:
SOURCE_UUID: 7382909c-e2ad-11e8-950f-000c2929361a
THREAD_ID: NULL
SERVICE_STATE: OFF
COUNT_RECEIVED_HEARTBEATS: 17
LAST_HEARTBEAT_TIMESTAMP: 2018-11-13 16:01:50.684358
RECEIVED_TRANSACTION_SET: 7382909c-e2ad-11e8-950f-000c2929361a:1-4
LAST_ERROR_NUMBER: 13114
LAST_ERROR_MESSAGE: Got fatal error 1236 from master when reading data from binary log: 'A slave with the same server_uuid/server_id as this slave has connected to the master; the first event '' at 4, the last event read from '/var/log/mysql/mysql-bin.000004' at 41461, the last byte read from '/var/log/mysql/mysql-bin.000004' at 41461.'
LAST_ERROR_TIMESTAMP: 2018-11-13 16:01:50.781611
LAST_QUEUED_TRANSACTION:
LAST_QUEUED_TRANSACTION_ORIGINAL_COMMIT_TIMESTAMP: 0000-00-00 00:00:00.000000
LAST_QUEUED_TRANSACTION_IMMEDIATE_COMMIT_TIMESTAMP: 0000-00-00 00:00:00.000000
LAST_QUEUED_TRANSACTION_START_QUEUE_TIMESTAMP: 0000-00-00 00:00:00.000000
LAST_QUEUED_TRANSACTION_END_QUEUE_TIMESTAMP: 0000-00-00 00:00:00.000000
QUEUEING_TRANSACTION:
QUEUEING_TRANSACTION_ORIGINAL_COMMIT_TIMESTAMP: 0000-00-00 00:00:00.000000
QUEUEING_TRANSACTION_IMMEDIATE_COMMIT_TIMESTAMP: 0000-00-00 00:00:00.000000
QUEUEING_TRANSACTION_START_QUEUE_TIMESTAMP: 0000-00-00 00:00:00.000000
*************************** 2. row ***************************
CHANNEL_NAME: sc-1
GROUP_NAME:
SOURCE_UUID: 7382909c-e2ad-11e8-950f-000c2929361a
THREAD_ID: 57
SERVICE_STATE: ON
COUNT_RECEIVED_HEARTBEATS: 5623
LAST_HEARTBEAT_TIMESTAMP: 2018-11-15 14:52:52.402809
RECEIVED_TRANSACTION_SET:
LAST_ERROR_NUMBER: 0
LAST_ERROR_MESSAGE:
LAST_ERROR_TIMESTAMP: 0000-00-00 00:00:00.000000
LAST_QUEUED_TRANSACTION:
LAST_QUEUED_TRANSACTION_ORIGINAL_COMMIT_TIMESTAMP: 0000-00-00 00:00:00.000000
LAST_QUEUED_TRANSACTION_IMMEDIATE_COMMIT_TIMESTAMP: 0000-00-00 00:00:00.000000
LAST_QUEUED_TRANSACTION_START_QUEUE_TIMESTAMP: 0000-00-00 00:00:00.000000
LAST_QUEUED_TRANSACTION_END_QUEUE_TIMESTAMP: 0000-00-00 00:00:00.000000
QUEUEING_TRANSACTION:
QUEUEING_TRANSACTION_ORIGINAL_COMMIT_TIMESTAMP: 0000-00-00 00:00:00.000000
QUEUEING_TRANSACTION_IMMEDIATE_COMMIT_TIMESTAMP: 0000-00-00 00:00:00.000000
QUEUEING_TRANSACTION_START_QUEUE_TIMESTAMP: 0000-00-00 00:00:00.000000
*************************** 3. row ***************************
CHANNEL_NAME: sc-2
GROUP_NAME:
SOURCE_UUID: c5b263d8-e433-11e8-8c4f-5254009262e2
THREAD_ID: 59
SERVICE_STATE: ON
COUNT_RECEIVED_HEARTBEATS: 5623
LAST_HEARTBEAT_TIMESTAMP: 2018-11-15 14:52:51.955988
RECEIVED_TRANSACTION_SET:
LAST_ERROR_NUMBER: 0
LAST_ERROR_MESSAGE:
LAST_ERROR_TIMESTAMP: 0000-00-00 00:00:00.000000
LAST_QUEUED_TRANSACTION:
LAST_QUEUED_TRANSACTION_ORIGINAL_COMMIT_TIMESTAMP: 0000-00-00 00:00:00.000000
LAST_QUEUED_TRANSACTION_IMMEDIATE_COMMIT_TIMESTAMP: 0000-00-00 00:00:00.000000
LAST_QUEUED_TRANSACTION_START_QUEUE_TIMESTAMP: 0000-00-00 00:00:00.000000
LAST_QUEUED_TRANSACTION_END_QUEUE_TIMESTAMP: 0000-00-00 00:00:00.000000
QUEUEING_TRANSACTION:
QUEUEING_TRANSACTION_ORIGINAL_COMMIT_TIMESTAMP: 0000-00-00 00:00:00.000000
QUEUEING_TRANSACTION_IMMEDIATE_COMMIT_TIMESTAMP: 0000-00-00 00:00:00.000000
QUEUEING_TRANSACTION_START_QUEUE_TIMESTAMP: 0000-00-00 00:00:00.000000
--------------------------
There is no Channel name, but the thread still tried to start and fails.
How can I remove or disable the default thread from running when the server reboots? Or is there another step I am missing here?
Thanks!
Subject
Views
Written By
Posted
Channel based replication thread conflicts with Default Channel.
1081
November 15, 2018 03:12PM
864
November 15, 2018 03:15PM
Sorry, you can't reply to this topic. It has been closed.
Content reproduced on this site is the property of the respective copyright holders.
It is not reviewed in advance by Oracle and does not necessarily represent the opinion
of Oracle or any other party.