Liquibase checksum failure after upgrade

After a CMA parcel upgrade, service roles might report bad health when Liquibase detects checksum mismatches against a lower embedded schema version.

Symptom: After a Cloudera Migration Assistant parcel upgrade, one or more roles display healthSummary: BAD. The application log contains the following validation exception:

liquibase.exception.ValidationFailedException: Validation Failed:
     N changesets check sum

Cause: The new version modified database schema files. The existing database stores checksums from the previous build that no longer match.

For more information on how Liquibase runs across embedded H2 and external databases, see CMA database backends .

Determine whether you need to preserve your existing metadata or wipe embedded databases.

Production clusters require data preservation, which you achieve by resetting checksum rows. Development or throwaway environments might tolerate full wipes.

To preserve metadata, reset Liquibase checksum entries.
note

Use this procedure only when you must keep existing plans and metadata.
1. Stop the failing service role.
2. Replace the sample IDs with the failing changesets reported by Liquibase.
```
java -cp /opt/cloudera/parcels/cma/lib/h2-*.jar org.h2.tools.Shell \
  -url 'jdbc:h2:/var/lib/cma/data/db/cma-server;IFEXISTS=TRUE;AUTO_SERVER=TRUE' \
  -user admin -password s3cret \
  -sql "UPDATE DATABASECHANGELOG SET MD5SUM = NULL WHERE ID IN ('<changeset-id-1>', '<changeset-id-2>');"
```
3. Restart the service role. On startup, Liquibase recalculates the checksums.
To wipe embedded databases (destructive), remove all local database files for CMA Master, CMA Auth Server, and CMA Agents.
warning

This action permanently deletes all Cloudera Migration Assistant data, including migration plans, execution history, cluster registrations, and scan results.

Use this procedure only if the embedded database records can be safely destroyed.
1. Stop all Cloudera Migration Assistant services. You must stop CMA Agents first, followed by the CMA Master.
2. On the CMA Master host delete the server and authentication database files.
```
sudo -u cma rm -f /var/lib/cma/data/db/cma-server.* /var/lib/cma/data/db/cma-auth.*
```
3. On each CMA Agent host clear the local agent database files.
```
rm -f /var/lib/cma-agent/data/db/cma-agent.*
```
4. Start CMA Master first, then start every CMA Agent service.
important

If you wipe the CMA Master database, you must also wipe all CMA Agent databases. CMA Agents store references to cluster and credential records that no longer exist in a fresh CMA Master database.
When upgrading multiple clusters, restart CMA Agents before restarting the CMA Master.

For deployment topology guidance, see Deploying the CMA server with parcels.