using external database, mysql version 5.7.16, Liquibase version: 3.6.3
I set MB_DB_AUTOMIGRATE to false and got all the sqls to execute manually and see the sql to create table such as "core_user" or "core_organization". It seems that some sqls can't be executed which setup before v0.22.2
How can I do upgrade database manually without data lost from v0.22.2 to v0.40.2, I see some comments in the output sqls, such as "-- Added 0.25.0", shall I execute the sqls since v0.23.2 so that the upgrade will be OK and which sqls should I run?
Hi @qingdaojunzuo
It seems like your application database is missing the table DATABASECHANGELOG, since it's trying to generate the entire Metabase schema again.
Are you sure the connection allows ALTER and REFERENCE queries? Make sure Metabase has enough privileges to modify it's own application database.
I did the sql like "alter table rename to" before so that I think the privileges are OK and all the tables in current mysql were created by metabase itself
Can I skip the sqls till v0.22.2 manually if the app can't skip automatically? Which sqls should I run? I see the max number in DATABASECHANGELOG is 48, does this mean I can run the sql since 49 defined in the output text which I got from log when MB_DB_AUTOMIGRATE to false?
BTW, I notice that the table DATABASECHANGELOGLOCK is not empty, does this cause the issue?
// truncate this table doesn't work
mysql> select * from DATABASECHANGELOGLOCK;
+----+--------+-------------+----------+
| ID | LOCKED | LOCKGRANTED | LOCKEDBY |
+----+--------+-------------+----------+
| 1 | | NULL | NULL |
+----+--------+-------------+----------+
1 row in set (0.00 sec)
-- Changeset migrations/000_migrations.yaml::48::camsaul
CREATE TABLE metabase.collection_revision (id INT AUTO_INCREMENT NOT NULL, before TEXT NOT NULL COMMENT 'Serialized JSON of the collections graph before the changes.', after TEXT NOT NULL COMMENT 'Serialized JSON of the collections graph after the changes.', user_id INT NOT NULL COMMENT 'The ID of the admin who made this set of changes.', created_at datetime NOT NULL COMMENT 'The timestamp of when these changes were made.', remark TEXT NULL COMMENT 'Optional remarks explaining why these changes were made.', CONSTRAINT PK_COLLECTION_REVISION PRIMARY KEY (id), CONSTRAINT fk_collection_revision_user_id FOREIGN KEY (user_id) REFERENCES metabase.core_user(id)) COMMENT='Used to keep track of changes made to collections.' ENGINE InnoDB CHARACTER SET utf8mb4 COLLATE utf8mb4_unicode_ci;
ALTER TABLE metabase.collection_revision COMMENT = 'Used to keep track of changes made to collections.';
INSERT INTO metabase.DATABASECHANGELOG (ID, AUTHOR, FILENAME, DATEEXECUTED, ORDEREXECUTED, MD5SUM, DESCRIPTION, COMMENTS, EXECTYPE, CONTEXTS, LABELS, LIQUIBASE, DEPLOYMENT_ID) VALUES ('48', 'camsaul', 'migrations/000_migrations.yaml', current_timestamp(6), 94, '8:720ce9d4b9e6f0917aea035e9dc5d95d', 'createTable tableName=collection_revision', '', 'EXECUTED', NULL, NULL, '3.6.3', '8474407822');
-- Changeset migrations/000_migrations.yaml::49::camsaul
ALTER TABLE metabase.report_card ADD public_uuid CHAR(36) NULL COMMENT 'Unique UUID used to in publically-accessible links to this Card.';
I'm not familiar with clojure, does this code mean to execute the file migrations/000_migrations.yaml (containing all the sqls from initial version rather than get the max id from DATABASECHANGELOG to decide the start id?)directly when fresh-install is false?
@qingdaojunzuo You should absolutely not truncate the table DATABASECHANGELOG - then Metabase has no idea about which migrations has been executed.
The problem is that Metabase for some reason sees your setup as a fresh setup and tries to run all migrations again.
Check the query log on MySQL. For some reason Metabase does not seem to find the table.
Metabase does a check on every startup to execute missing migrations. That's what the file 000_migrations.yaml contains.
I would recommend that you try a step-by-step upgrade, so first to 0.23.x, then 0.24.x (which unified all migration yamls), then 0.32.x and then the latest 0.40.x
It would hopefully help figuring out if the problem is with some bad migration somewhere or if your application database has a corruption.
Thanks very much for your help The issue is resolved.
I compared the DATABASECHANGELOG between 40.2 and 22.2, metabase should find the table DATABASECHANGELOG when tracing the mysql's execution history log(SQL query history), the issue is that the value of column FILENAME is not correct for migration,
v0.22.2 migrations/001_initial_schema.json
v0.40.2 migrations/000_migrations.yaml
The files are separated in 22.2 rather than 1 file in 40.2 so that all the sqls in 000_migrations.yaml will be executed
I updated the value as 000_migrations.yaml, the upgrade continued to execute with legacy data
BTW, another issue encountered I think it's a legacy bug with the SQL fixed, the database deleted in metabase_database would not delete other data cascade, such as report_card and the related table, and the fk constraint related to this migrated failed, that's the data issue, we updated the relationship and resovled. And the table truncated mentioned above is not DATABASECHANGELOG, it's DATABASECHANGELOGLOCK:)
@qingdaojunzuo Excellent. I'm not entirely sure why the references wasn't updated, since all migrations were merged in 0.24.0.
It's correct that there were issues with cascading deletes not happening correctly in earlier versions, which was why constraints were added, but for a few setups, they already had out-of-sync data, which then meant the constraints wasn't added and this could lead to some really strange/annoying problems.
BTW, we try to move the auth from local to LDAP after upgrade, it seems OK except the group mapping, we are using groupOfUniqueNames as role in LDAP, such as,
dn: cn=Operator,ou=roles,dc=test,dc=com
cn: Operator
objectclass: groupOfUniqueNames
objectclass: top
uniqueMember: uid=operator@test.com,ou=people,dc=test,dc=com
I see the document, the group in LDAP defined by groupOfNames