Module 1 - Prepare the source MySQL database

DTS needs a database account, row-based binary logs and stable row identifiers. Validate each requirement before you create the migration task.

Step 1 - Connect to the source

1. In the ECS console, find wsNN-source and choose Connect > Workbench > Sign in now.
2. Log in as root: Password-Free if offered, otherwise Terminal with the root password from your credential sheet (private IP if asked).
3. Confirm the bootstrap completed and MySQL is active:

   test -f /opt/workshop/.setup-complete && echo "setup complete"
   systemctl is-active mysqld
   mysql -e "SELECT VERSION();"

Step 2 - Validate binary logging

Incremental migration reads every committed change from MySQL binary logs. DTS requires ROW events with the complete before/after row image and at least seven days of local retention.

mysql -N -e "SELECT @@log_bin AS log_bin, @@binlog_format AS binlog_format, @@binlog_row_image AS binlog_row_image, @@server_id AS server_id, @@binlog_expire_logs_seconds AS retention_seconds; SHOW MASTER STATUS;"

If a value differs, stop and ask your facilitator. The settings are in /etc/my.cnf.d/zz-workshop.cnf; changing them may require a MySQL restart.

Step 3 - Confirm that every table has a key

Each migrated table must have a primary key or a UNIQUE constraint whose values are unique. Without one, DTS cannot identify rows reliably and duplicate records may appear.

mysql shopdb -e "SHOW TABLES; SHOW INDEX FROM customers WHERE Key_name='PRIMARY'; SHOW INDEX FROM products WHERE Key_name='PRIMARY'; SHOW INDEX FROM orders WHERE Key_name='PRIMARY';"
mysql shopdb -e "SELECT COUNT(*) customers FROM customers; SELECT COUNT(*) products FROM products; SELECT COUNT(*) orders FROM orders;"

You should see a PRIMARY index for each table and counts of 1000 customers, 50 products and approximately 10000 orders.

Step 4 - Create a dedicated source account

Create a random password, then grant only the permissions DTS needs: read tables and views, read the binary log, and create its heartbeat/test database.

DTS_SOURCE_PASSWORD="$(openssl rand -hex 10)aA1!"
printf '%s\n' "$DTS_SOURCE_PASSWORD" > /root/.dts-source-password
chmod 600 /root/.dts-source-password
mysql <<SQL
CREATE USER IF NOT EXISTS 'dts_user'@'%' IDENTIFIED BY '$DTS_SOURCE_PASSWORD';
ALTER USER 'dts_user'@'%' IDENTIFIED BY '$DTS_SOURCE_PASSWORD';
GRANT SELECT ON *.* TO 'dts_user'@'%';
GRANT SHOW VIEW, REPLICATION CLIENT, REPLICATION SLAVE ON *.* TO 'dts_user'@'%';
GRANT CREATE ON *.* TO 'dts_user'@'%';
FLUSH PRIVILEGES;
SQL
echo "DTS source account: dts_user"
echo "DTS source password: $(cat /root/.dts-source-password)"

Step 5 - Verify the grants

mysql -e "SHOW GRANTS FOR 'dts_user'@'%';"
mysql -udts_user -p"$(cat /root/.dts-source-password)" -e "SELECT COUNT(*) AS orders FROM shopdb.orders; SHOW MASTER STATUS;"

The first command should show SELECT, SHOW VIEW, REPLICATION CLIENT, REPLICATION SLAVE and CREATE grants. The second should return the order count and current binary-log file/position. It also prints Using a password on the command line interface can be insecure; that warning is expected here.

Why does DTS need CREATE?

DTS periodically runs CREATE DATABASE IF NOT EXISTS test on the source to advance the binary-log position and measure latency. For full-database migration it can also use heartbeat writes. This is why a read-only account is not sufficient for incremental migration.