6.15. Performing Database or OS Maintenance

When performing database or operating system maintenance, datasources should be temporarily removed from the dataservice and the replicator should be disabled. Follow these rules for the best results. Detailed steps are provided below for different scenarios.

Important

If you are upgrading MySQL from any 5.x release to version 8.0, then it is important that you first enabled the dropsqlmode filter. This will ensure replication between new and old version of MySQL will succeed.

After ALL nodes are running the same release of MySQL this filter can be removed.

The need for this filter is due to new and old SQL modes no longer being recognised in the older/newer versions of MySQL. Without the filter in place the replicator will go into an error state with a message similar to:

java.sql.SQLSyntaxErrorException: Variable 'sql_mode' can't be set to the value of 'NO_AUTO_CREATE_USER'

See Section 11.4.17, “dropsqlmode.js Filter” for more information on the use of the filter.

  • For maintenance operations on a Primary, the current Primary should be switched, the required maintenance steps performed, and then the Primary switched back.

  • Disable a datasource using the datasource shun command.

  • Put the replicator offline using trepctl offline.

  • If you are using the Multi-Site/Active-Active topology, put the extra replicator offline using mm_trepctl offline. The mm_trepctl alias will only work if you configured Tungsten Replicator with the --executable-prefix=mm option.

  • When making changes to a MySQL system the binary log should be disabled for your session. This will prevent corrective actions from replicating to other servers. Ignore this suggestion if you are making changes to a Primary that should be replicated.

    mysql> SET SESSION SQL_LOG_BIN=0;
  • Restart replication and recover the datasource after maintenance is complete using datasource recover, trepctl online and optionally mm_trepctl online.