Details
-
Bug
-
Status: Closed (View Workflow)
-
Major
-
Resolution: Won't Do
-
2.2.11
-
MaxScale host: Debian 8.11, MaxScale version 2.2.11
DB hosts: Debian 9.4, Server version: 10.2.16-MariaDB-10.2.16+maria~stretch-log
-
MXS-SPRINT-72, MXS-SPRINT-73
Description
Hello!
My setup is 3 virtualbox machines on the same host. One with MaxScale another two with MariaDB Master-Slave replication which use GTID.
For the first time I had tried to use setup when the master-host writes all changes to binary log and slave-host replicate separate databases using replicate_do_db=maxscale_schema. It didn't work. Monitor user created db on master and successfully INSERT/UPDATE timestamps there. Slave-host only created maxscale_schema and there wasn't any data in db. Than I found solution in mysql bug tracker. I set replicate_wild_do_table=maxscale_schema.replication_heartbeat ( also tried maxscale_schema.%). In that case db was successfully replicated with timestamps but there were some notice in maxscale.log:
2018-07-26 15:59:28 warning: [mariadbmon] 'replicate_wild_do_table' is defined on server 'slave' and 'maxscale_schema.replication_heartbeat' does not match it. |
2018-07-26 15:59:28 warning: [mariadbmon] Problems were encountered when checking if 'maxscale_schema.replication_heartbeat' is replicated. Make sure that the table is replicated to all slaves. |
and
2018-08-01 08:20:23 error : [mariadbmon] Error updating maxscale_schema.replication_heartbeat table: [UPDATE maxscale_schema.replication_heartbeat SET master_timestamp = 1533111622 WHERE master_server_id = 10 AND maxscale_id = 0], Lost connection to MySQL server during query |
What is the proper way to replicate maxscale_schema?
Monitor user's grants:
GRANT RELOAD, SUPER, REPLICATION CLIENT ON *.* TO 'max_mon'@'192.168.33.10' IDENTIFIED BY PASSWORD *836B8268CD89F477F0B18359214FDF18C901E292' REQUIRE SSL |
GRANT SELECT, INSERT, UPDATE, DELETE, CREATE ON `maxscale_schema`.* TO 'max_mon'@'192.168.33.10' |