You are viewing an old version of this page. View the current version.

Compare with Current View Page History

« Previous Version 4 Next »

Introduction and Prechecks

If there is a request to move DualShield Replication cluster to a new set of servers the best approach would be to Clone just one dualshield/mysql node in the cluster using the instructions as written here...

How to move DualShield to a new machine with the same Windows OS System Type

Then create a new replication cluster using the DualShield Assistant tool to clone from the new server and set up a new replication cluster.

However, this may not be 100% straightforward as there are a couple of factors to consider, such as the size of the audit log table , eg

And the amount and total size of the existing binary log files from the current replication cluster.

Ideally, you should have a few..

..but, if you have a large amount, dating back a long time, together with a large audit log table, cloning will take too long, or may even fail.

Check Audit logs

The easiest way to check the size of your audit log table is to go to C:\Program Files\Deepnet DualShield\mysql\data\dualshield and search for the log.idb file

In the screenshot posted above 3Gb is acceptable and should not hamper the cloning, but if you have 10, 20, or 30 Gbs or more it is advisable to cut this down.

If you are not concerned with keeping the audit logs, then the fastest approach is to stop DualShield service, log into your Mysql console via command prompt or MySQL Workbench and drop the log table..

drop table log;

Please note that for DualShield v5 you also need check the size of the log_field.idb and drop this table first.

If you are not confident with MySQL queries you can use the Truncate audit trail task in the admin console to do the same thing.







  • No labels