MySQL Version Control - Subversion

Question

Wondering if it is possible to have a version control of a MySQL database.

I realize this question has been asked before however the newest is almost a year ago, and

Answer 1

Well we use Rails which keeps all the change in the migration files. I know that a couple of PHP frameworks do the same thing - Symphony for instance. So when all the changes are merged in our repository ( we user mercurial) - we can see all the changes in migrations that need to or were applied on database in development. Than the person responsible for production rolls out code to production after a full backup is made. However if you don't use a PHP framework that takes care of this than, awied's suggestion sounds very interesting - I haven't heard of liquidbase before but I will definitely check it out.

Answer 2

There is a tool called iBatis, now called MyBatis that handles versions of databases perfectly.

It takes a little work to have all your changes in script instead of with a graphical tool, but, if you are familiar with coding, it's not a problem.

When you have multiple databases (like dev-test-prod), you just make 3 environment files and you can update one environment with only one command-line instruction.

Answer 3

This is not a MySQL-related solution in itself, but we've had a lot of success with a product called liquibase. (http://www.liquibase.org/)

It's a migration solution which covers many different database vendors, allowing all database changes to be coded in configuration files, all of which are kept in Subversion. Since all configuration is kept in XML files, it's easy to merge other people's changes into the mainline script and it plays well with tags and branches.

The database can be brought up to the current revision level by running the "update database" command. Most changes also have the ability to roll-back a database change, which can be helpful too. I would recommend following the practice of making sure you get current before running the migration, as this would likely be easiest.

Finally, when it comes to a production delivery, you can choose to have all the database changes output as a full SQL script so it can allow DBAs to run it and maintain a separation of duties.

So far, it's worked like a charm.