Barkeep may use MyISAM tables on older MySQLs about barkeep

[edanaher]

According to http://dev.mysql.com/doc/refman/5.5/en/alter-table.html, you can just

ALTER TABLE t1 ENGINE = InnoDB;

to switch to InnoDB. This wouldn't fix existing brokenness due to triggers/constraints not being enforced, but neither would dumping data and restoring it...

[cespare]

Why wouldn't dumping and restoring fix (or at least reveal) brokenness in constraints? The process I'm imagining is

• mysqldump all the tables (with the option to not create the tables first)
• Blow away the DB and run the migrations from scratch (now they will be InnoDB and have constraints)
• Import all the .sql files.

[edanaher]

You're right - dumping/restoring would show issues with constraints,
though not with transaction trigger failures that don't have associated
constraints. I have no idea how they're used, so I don't know the
balance of what would be helped or not.

On Thu, Sep 01, 2011 at 04:51:35PM -0700, cespare wrote:

Why wouldn't dumping and restoring fix (or at least reveal) brokenness in constraints? The process I'm imagining is

• mysqldump all the tables (with the option to not create the tables first)
• Blow away the DB and run the migrations from scratch (now they will be InnoDB and have constraints)
• Import all the .sql files.

Reply to this email directly or view it on GitHub:
#20 (comment)

[philc]

Innodb is now being used for all tables going forward as of 0f58f63.

[dmac]

Closing per philc's comment.

[cespare]

Reopened until we switch prod to use InnoDB

[cespare]

Actually, we still have all the work left to do on this issue. We still need to modify the old migrations to use InnoDB, and we still need to fix the old migrations to not be broken when using InnoDB. Then we need to make the prod switch.

[cespare]

OK, I think I've done the bulk of the necessary work here. I've pushed major migrations changes to the branch innodb_switch. I can now bring up a mysql db from scratch with InnoDB and run Barkeep. Tomorrow I will work with someone else to make the switch in prod; until then, I will leave this change unmerged.

[cespare]

Alright, I dumped the prod DB and imported on my own local MySQL that had previously had the InnoDB-ified migrations applied to it.

We'll merge that branch and push to prod tonight; for reference, here are the steps:

1. Dump the database:

   mysqldump -u<user> -p<pw> --no-create-db --no-create-info --ignore-table=barkeep.schema_migrations barkeep > barkeep.sql
   

2. Manually edit the SQL file to delete the user entry "demo" (primary key 1) from around line 108. (The migration inserts this for us).

3. Drop the DB and create it again:

   mysql -<user> -p<pw> -e "drop database barkeep; create database barkeep;"
   

4. Push the new code with the fixed migrations.

5. Run the migrations.

6. Verify that we're now using InnoDB by examining the output of this command from the mysql prompt:

   show create table table_name \G
   

7. Import the data:

   mysql -u<user> -p<pwd> barkeep < barkeep.sql
   

8. Start up barkeep and verify that the data is there.

[cespare]

Fixed in prod.

[cespare]

OK, the fixed migrations have been merged in and pushed. I think we're good to go now.