I've restores a backup of my database from another environment into a test/development environment, but when starting the application up I get a checksum mismatch error
Sep 10, 2019 3:50:50 PM org.flywaydb.core.internal.command.DbValidate validate
INFO: Validated 146 migrations (execution time 00:00.193s)
Exception in thread "main" org.flywaydb.core.api.FlywayException: Validate failed. Migration Checksum mismatch for migration 2.20170627213900
I'm currently using an old version of flyway (3.2.1) (plan to upgrade in the near future but can't right now) and can't find docs for this version - so I'm not sure if any of the properties listed on the website are even valid.
What is the normal/recommended process for handling the restore between environments? I'm assuming the reason for failure is that the checksum for the migration file is being calculated on the 'dev' environment filesystem and then being compared to the checksum in the schema_version database table which was previously calculated as the checksum for the file on the other environment?
Related
I am running mysql as docker (mysql:8.0.20). Gradle task deployNodes fails with error :
Could not create the DataSource: Validation Failed:
1 changes have validation failures
columnDataType is required for renameColumn on mysql, migration/node-info.changelog-v3.xml::column_host_name::R3.Corda.
Can somebody help me with this error?
As you can see columnDataType is a required attribute for MySql. Corda does not support MySql and hence this is not tested against MySql so you could get these kinds of MySql specific errors.
If you are using Corda enterprise, you could set the runMigration flag to false(which will not run the schema automatically on the db), use the database management tool to manually generate the schema, make changes (add columnDataType to the schema), and then run it manually onto mysql db.
Below image is taken from https://www.liquibase.org/documentation/changes/rename_column.html
I am getting column "identity_value" is of type byte error while running the Corda node. I am trying to use one existing schema(party_a_schema) for one of my cordapp. I have updated the node.conf file for that node.
After basic analysis, I have found that to use a schema over multiple cordapp in Corda open-source platform, we must execute the below DDL statement.
CREATE SEQUENCE my_schema.hibernate_sequence INCREMENT BY 1 MINVALUE 1 MAXVALUE 9223372036854775807 START 8 CACHE 1 NO CYCLE;
At the time of script execution, I am getting this error
Above issue has been resolved. This happens when you do a clean deployNodes many times, in which case your node files are deleted (including the truststores,keys,certificates,nodeinfo files) but these are not deleted from the database. Eventually, you corrupt the database with a new entry being added each time you deploy the node, and hence eventually the node does not start properly.
Ideally in production when you deploy, when you deploy your cordapp for the first time all the required tables are created, node info files, identities , certificates etc. Later if you want to make any changes ideally what you do is upgrade your cordapp and perform database migrations (you dont clean up your entire database).
Hence, in development mode when you connect to an external database, whenever you do a clean deployNodes on the terminal also clean up your database.
I have created checkpoint table ggate for replicat rep1 but still I am getting following error:
2014-09-04 23:38:21 ERROR OGG-00446 Oracle GoldenGate Delivery for
Oracle, REP1.prm: Checkpoint table ggate.checkpoint does not exist.
Please create the table or recreate the REP1 group using the correct
table.
2014-09-04 23:38:21 ERROR OGG-01668 Oracle GoldenGate Delivery for
Oracle, REP1.prm: PROCESS ABENDING.
Can anyone tell me how to resolve it?
In this kind of situations you should:
Have you actually run the ADD CHECKPOINTTABLE? if not run it
Check if the checkpoint table actually exists in the database - if it has been created - try to drop it (DROP CHECKPOINTTABLE) and recreate it (ADD CHECKPOINTTABLE)
Check if the checkpoint parameter is correctly set in the GLOBALS config file
Restart the MGR and Extract/Replicat processes
Verify if the user has access on the database to the checkpoint table (insert, update, delete rights)
If nothing works, run 10046 flag on the target database and check what the GoldenGate Replicat process is executing on the database and when it actually fails (what it wants to do on the database and try to do the same commands by yourself)
This is a simple troubleshooting initiative:
Are you using a traditional non-CDB database or a PDB?
Are you using Classic Architecture or Microservices Architecture? - Different approaches when adding a checkpoint table.
How are you running ADD CHECKPOINTTABLE? From GGSCI/AdminClient or from HTML5 page?
In Classic Architecture, do you have CHECKPOINTTABLE parameter set in GLOBALS? (CHECKPOINTTABLE [container.] owner.table)
Who are you logged into the database as when using DBLOGIN USERIDALIAS?
What replicat are you using? - Classic, Coordinated, Integrated, Parallel?
Check the schema where the table is suppose to be? If not there, you can query the DBA_TABLES view for the name of the checkpoint table and see who owns it.
A lot of times when the checkpint table cannot be created it is due to not updating the GLOBALS file and/or connecting as the correct user to the database.
Recently upgraded to BizTalk 2013 CU2 and installed ESB.
This has had some side effects as we can no longer deploy without getting a database FK reference error.
Any one seen this before?
Here is the error when we try to deploy a new assembly to the DEV environment.
TITLE: BizTalk Server Administration
Failed to update resources in the application.
ADDITIONAL INFORMATION:
Failed to add resource(s). (mscorlib)
Change requests failed for some resources. (Microsoft.BizTalk.ApplicationDeployment.Engine)
BizTalkAssemblyResourceManager failed to complete end type change request. (Microsoft.BizTalk.ResourceManagers)
Removal of the assembly failed. Make sure that all items in the assembly you are trying to remove fulfill the following conditions:
Pipelines, maps, and schemas are not being used by Send Ports or Receive Locations in the same or referenced application(s).
Roles have no enlisted parties.
Database Error:
The DELETE statement conflicted with the REFERENCE constraint
bts_receiveport_transform_foreign_transformid. The conflict occurred
in database "BizTalkMgmtDb", table "dbo.bts_receiveport_transform",
column 'uidTransformGUID'. The DELETE statement conflicted with the
REFERENCE constraint "fk_bt_mapspec_bts_item". The conflict occurred
in database "BizTalkMgmtDb", table "dbo.bt_MapSpec", column 'itemid'.
The DELETE statement conflicted with the REFERENCE constraint
"bts_receiveport_transform_foreign_transformid". The conflict occurred
in database "BizTalkMgmtDb", table "dbo.bts_receiveport_transform",
column 'uidTransformGUID'. The statement has been terminated. The
statement has been terminated. The statement has been terminated.
(mscorlib)
I ran a SQL trace and found that this is the SP that breaks when it tries to delete from table dbo.bt_MapSpec.
exec dpl_DeleteAssembly
#Guid=N'00000000-0000-0000-0000-000000000000',#Name=N'theassemblynamegoeshere',#VersionMajor=1,#VersionMinor=0,#VersionBuild=0,#VersionRevision=0,#PublicKeyToken=N'89e32fae0caf808e',#Culture=N'neutral',#Type=N'2',#NoSchemasVerify=0
I am using Flyway with Postgres and I have noticed that if I have my tomcat server running, and I try to execute a DROP SCHEMA foo it does not work until tomcat shuts down. I am assuming that flyway has some mechanism to block modifications to the schema after it runs. How is the blocking of other clients modifying the schema accomplished in flyway.
Flyway doesn't lock the schema.
When it starts applying a migration, it begins a transaction. It then acquires a lock on the metadata table using SELECT * FROM metadatatable FOR UPDATE. This lock is released automatically after the migration completes when the transaction is commited or rolled back.