How do I migrate Bitbucket back to the embedded database?

I've recently upgraded from Stash to Bitbucket, carefully following all the Atlassian migration notes.  I even followed the instructions on how to connect to an external MySQL database, expecting to use the migration wizard to move our old stash database to the shiny new MySQL Bitbucket database.  But I've done too much manually and Bitbucket is already using the (empty) MySQL database and the embedded one is not available to be migrated.

Please could someone advise me as to which configuration file(s) I need to edit to undo the partial manual migration, so that I can use the migration wizard to do it properly?

Or is there some way I can tell the migration wizard to go back to using the embedded database (I didn't recognise it in any of the target DB options)?

4 answers

Hi Simon,

Before making any suggestions, please allow me to ask a few questions to clarify this further:

  • When saying "I've done too much manually", could you please clarify, in details, the steps you've executed?
  • By your description, could you please confirm you had data already in Bitbucket when you tried to move to MySQL? I'd like to confirm this since, if you performed the migration to the new DB via UI, all your data should have been carried over to the MySQL database.
  • Do you have a backup of your instance, prior to migrating to MySQL? With that, I believe the best way for now would be to restore this backup pointing it to use the embedded database, so you would be back to the previous state.

Regards,

Gustavo

  • I can't say in detail, I've spent hours fiddling with all kinds of things, including upgrading to a new version of MySQL.  Essentially I used the Bitbucket installer to replace the original Stash installation with the new version and it worked ok to begin.  Then I stated installing an evaluation version of Confluence, including using an external database, which meant that I had to update MySQL.  After doing this, our JIRA installation stopped working, which I fixed, but broke the Bitbucket installation at the same time.  The original Stash installation was using MySQL 5.5, but everything else is on 5.6 and this was causing issues, so I migrated the Stash database to 5.6 and changed the bitbucket.properties file accordingly, or so I thought.
  • Yes, I had data in Bitbucket, but...  I'm no longer sure whether it was in the Bitbucket embedded DB, or in the MySQL 5.5 database, I suspect it was actually the latter, but the physical files for that (including those in the backups) are missing the IDB files (FRM files are still present).  And that confuses me.
  • With regard to backups, I may have to resort to going to an old, off-site tape copy, as it appears that the more recent ones have not been working correctly (0 kByte SQL files are not a good sign and almost certainly down to the missing IDB data files).

My plan now is to try to restore the MySQL 5.5 Stash DB and see if I can get the migration wizard to move that to the new MySQL 5.6 Bitbucket DB.  I suspect that I've done something very wrong with the MySQL migration at some point.

(The easy answer to my original question is to remove the database configuration lines from the bitbucket.properties file.)

The actual answer is to remove the database configuration lines from the Bitbucket Server config properties file, specifically: jdbc.driver, jdbc.url, jdbc.user, jdbc.password (and jdbc.ignoreunsupported).

Without these settings Bitbucket doesn't have an external database to connect to and automatically falls back to using the internal HSQL database.

However, in my scenario, this was not the case, there was no HSQL database to fall back on; I had been misled into thinking that it wasn't using the MySQL database by invalid back-up files (incorrect port number specified in the back-up script).

The solution for me was to start an instance of the old MySQL server temporarily, using the data that was still lying around on the drive from before the original Stash to Bitbucket migration.  Another temporary modification of the bitbucket.properties file to point it at the old version of MySQL, with the my.ini file edited so that it had a different port from the new MySQL server.  I then had to drop the Bitbucket database from the new server and re-create it, because it had picked up empty tables from the failed migration.  I re-started Bitbucket and used the Migration Wizard to migrate the database from the old version of MySQL to the new one, stopped the old MySQL and, to my great relief, the new Bitbucket configuration works with the new MySQL database.  Win!

I've also fixed and tested the back-up scripts, so no more self-inflicted nightmares, and fixed the application links between JIRA and Bitbucket.  I can even see all my repositories and clone, pull, push from a remote.  Now all I need is for one of the other team members to tell me everything else I've missed.

Thanks for your help, your questions made me think about the problem properly and ultimately led me to a solution.  I've added an answer in case it helps someone else in the future.

Suggest an answer

Log in or Join to answer
Community showcase
Piotr Plewa
Published Dec 27, 2017 in Bitbucket

Recipe: Deploying AWS Lambda functions with Bitbucket Pipelines

Bitbucket Pipelines helps me manage and automate a number of serverless deployments to AWS Lambda and this is how I do it. I'm building Node.js Lambda functions using node-lambda&nbsp...

711 views 0 4
Read article

Atlassian User Groups

Connect with like-minded Atlassian users at free events near you!

Find a group

Connect with like-minded Atlassian users at free events near you!

Find my local user group

Unfortunately there are no AUG chapters near you at the moment.

Start an AUG

You're one step closer to meeting fellow Atlassian users at your local meet up. Learn more about AUGs

Groups near you
Atlassian Team Tour

Join us on the Team Tour

We're bringing product updates and pro tips on teamwork to ten cities around the world.

Save your spot