Applies to
- Liquibase Enterprise (Datical DB)
Conditions
- Any version of Liquibase Enterprise
Issue Summary
When running Packager, previous changesets attempt to deploy again. When checking the DATABASECHANGELOG table, there are no entries.
Error Message
The errors would depend on the first script in the changelog.xml file. If the first script is a create table statement, then an error like the following will be shown:
Table 'my_table' already exists [Failed SQL: CREATE TABLE my_table (id INT PRIMARY KEY, name VARCHAR(255))]
Potential Root Causes
There are two main root causes of this type of behavior where the DATABASECHANGELOG is empty.
- The Liquibase Enterprise project is pointing to a new or different reference database than expected.
- The backup and restore stage of Packager failed, and Packager was run again without resolving a previous backup and restore issue.
Troubleshooting
Verify the Database
Ensure that the Liquibase Enterprise project is connected to the expected database.
Step 1: Check connection information
In the datical.project file, there will be the information Liquibase uses to connect to the database. Verify that all of the information, such as host, port, and database names, is correct.
Step 2: Checking the database
Using the information gathered in Step 1. Manually connect to the database and verify if there are objects in the database. You can check the changelog.xml file to see what changesets should be in the reference database.
Error during the backup and restore
If an error occurs during the backup and restore phase of Packager, a .lock file will be created, which prevents Packager from running again until the .lock file is removed. This allows for the error during the backup and restore to be looked at and fixed before Packager runs again.
However, if the Packager is run again where the backup and restore failed before the issue is fixed, the backup file may be deleted or invalidated. Liquibase will then use the invalid backup to try to restore the database, which results in tables being empty or objects not fully being restored.
Step 1: Check if a .lock file was generated
Look at the previous jobs with Packager and check if any of them failed. If they did fail, check if a .lock file was generated.
Note: We have seen in some CI/CD processes that users have added the .lock file to the .gitignore. We strongly recommend not ignoring this file. In this case, the .lock file will get generated in the pipeline but isn't added to the project repository, which won't prevent Packager from running again.
Step 2: Check if there is still a valid backup file
Either have the DBA check for a valid backup of the database or look at the deployPackager.properties file to check where the backup files are stored. This directory will show all of the backups Liquibase has of the database.
Step 3: Restore the database
If the database has a valid backup file, use the backup file to restore it. You can check the DATABASECHANGELOG table, which should contain all of the entries for the changesets that have been deployed to the RefDB.
If there is no valid backup file, the RefDB must be restored based on one of the upstream databases (such as QA or Prod). Ensure that the DATABASECHANGELOG gets copied over as well.
Related Article(s)
N/A
Comments
0 comments
Article is closed for comments.