Working with databases during transfer

When working with data transfers, you must take into account the specific features of databases.
While the transfer with replication is running (Replication and Snapshot and increment transfer types), the data on the source and target may differ, so during this time, errors may occur when reading data from the target database. After deactivating the transfer, all data on the source and target will be the same (eventual consistency).

MySQLMySQL

• For transfers in the Copying status, any changes to the data schema (ALTER) on the source or target will interrupt the transfer.

• For transfers in the Replicating status, you can change the data schema on the source. All ALTER operations recorded in the binary log (binlog) on the source will be automatically applied to the target. This process takes some time, so the transfer may slow down.

PostgreSQLPostgreSQL

For Snapshot and Snapshot and increment transfers:

• In the Copying status, changes to the data schema on the source and target are not allowed.

• In the Replicating status, any changes to the data schema on the source should be manually applied to the target, otherwise the transfer will not be able to continue.

  For example, suppose we added a new column to the test_table table on the source:

  ALTER TABLE test_table ADD COLUMN val2 TEXT;
  

  If writing to this table continues, the transfer will not be able to insert data on the target. For replication to continue, run a similar query to change the data schema on the target:

  ALTER TABLE test_table ADD COLUMN val2 TEXT;
  

  After that, the transfer can continue.

MongoDBMongoDB

• For transfers with the Copying status, you cannot perform any actions reducing the origin's operation log (oplog) time window. You should not add, delete, or reconfigure shards in any way during copying or perform any other actions resulting in a shorter operation log time window.

• In transfers in Replicating status, you may encounter the key duplication problem when a sharded MongoDB cluster with a sharding index other than _id is the target. While a transfer is underway, we caution against creating clusters with sharding indexes other than _id on the target.