Migration job metrics

Restore lag

The Restore lag diagram uses the migration_job/max_replica_sec_lag metric to represent the time difference between the backup file epoch (derived from the file name), and the moment when that file is fully restored in your Cloud SQL destination instance. This metric monitors all types of backup and transaction log files that you use for a migration job (that is, a full backup, a differential backup, or a transaction log file). You can use this information to estimate your average data replication speed, or to troubleshoot possible issues with continuous data replication.

This metric is available for each database included in your migration job, and in the aggregated view where it shows restore lag across all databases included in your migration job.

Transaction log backup upload lag

The Transaction log backup upload lag diagram uses the migration_job/sqlserver/transaction_log_upload_sec_lag metric to show how much time (in seconds) has passed between now and the timestamp of the last transaction log file you uploaded to Cloud Storage. You can use this metric to monitor possible issues with automated uploads of transaction log files: a big time difference could indicate that your transaction log files aren't being uploaded to the Cloud Storage bucket.

This metric is available for each database included in your migration job, and in the aggregated view where it shows the highest lag across all databases included in your migration job.

Processed transaction log backups

The Processed transaction log backups diagram uses the migration_job/sqlserver/processed_file_count metric to represent how many transaction log backup files Database Migration Service has processed and imported to Cloud SQL. This information updates after a transaction log is fully processed, so the line displayed on the diagram moves in bigger jumps rather than gradual decreases.

You can monitor this metric to track the progress of the incremental load phase. A value greater than 0 indicates that your migration job finished the initial load phase and is now in the incremental load phase.

This metric is available for each database included in your migration job, and in the aggregated view where it shows a summary for all databases included in your migration job.

Processed transaction log backups size

The Processed transaction log backups size diagram uses the migration_job/sqlserver/processed_file_bytes_count metric to show how much transaction log data (in bytes) Database Migration Service has replicated to your Cloud SQL destination instance. This information updates after a transaction log is fully processed, so the line displayed on the diagram moves in bigger jumps rather than gradual decreases.

This metric is available for each database included in your migration job, and in the aggregated view where it shows a summary for all databases included in your migration job.

Unprocessed transaction log backups

The Unprocessed transaction log backups diagram uses the migration_job/sqlserver/unprocessed_files metric to represent how many transaction log backup files Database Migration Service has detected in your source Cloud Storage bucket but has not yet replicated to your Cloud SQL destination instance. This information updates after a transaction log is fully processed, so the line displayed on the diagram moves in bigger jumps rather than gradual decreases.

You can watch this metric when you want to determine when to finalize your migration job. A good time to promote the migration job would be when the value of Unprocessed transaction log backups reaches zero and you don't have more transaction log files to upload to Cloud Storage.

This metric is available for each database included in your migration job, and in the aggregated view where it shows a summary for all databases included in your migration job.

Unprocessed transaction log backups size

The Unprocessed transaction log backups size diagram uses the migration_job/sqlserver/unprocessed_file_bytes metric to show how much data (in bytes) Database Migration Service has detected in your source Cloud Storage bucket but has not yet replicated to your Cloud SQL destination instance. This information updates after a transaction log is fully processed, so the line displayed on the diagram moves in bigger jumps rather than gradual decreases.

You can watch this metric when you want to determine when to finalize your migration job. A good time to promote the migration job would be when the value of Unprocessed transaction log backups size reaches zero and you don't have more transaction log files to upload to Cloud Storage.

This metric is available for each database included in your migration job, and in the aggregated view where it shows a summary for all databases included in your migration job.

Total destination storage usage

The Total destination storage usage diagram uses the Cloud SQL database/disk/bytes_used metric to show how much data (in bytes) is stored in all the databases in your destination Cloud SQL instance. You can use this information to estimate the progress of your migration job.

This metric is only available in the aggregated view. You can't filter the total disk usage per database.

Replication delay

The Replication delay diagram uses the Cloud SQL per_database/postgresql/external_sync/replication_byte_lag metric to show the difference (in bytes) between the time an operation was executed on the source and when it was applied to the destination instance.

You can use this information to ensure data consistency between the source and the destination instance.

This metric is available for each database included in your migration job, and in the aggregated view where it shows a summary for all databases included in your migration job.