Adding a database after the fact.

[westpfahl]

So I know I should not have done this, but I did I'm dumb.

I did the rookie mistake of creating our entire confluence platform and only using the internal database. Were having a few weird problems with Confluence so I wanted to run a upgrade anyways and I figured this would be a good time to migrate from the embedded database to an actual one.

I have seen this article however it requires you to have set up a 2nd server to migrate the data to? I'm currently running 6.12.3 and would also like to upgrade to 6.15.7. Would it be possible to just set up a database and when I run the upgrade copy the data that way?  

And for anyone that might have an opinion, there are several options for databases that work with Confluence. Which one do you think would be the easiest to work with, especially given that our environment isnt huge. Its maybe 50 total pages and 90% text.

[Nic Brough -Adaptavist-]

I would do it the other way around. 

• Set up an empty database.  If you have no preference, the order we usually recommend is Postgres first, as that's what Atlassian use most, then MySQL, Oracle third and MS-SQL last.  BUT, if you have any "looking after a type of database" expertise in your organisation, use the one they are happiest to support for you.  Having experts around to help is far more important than which one of the four might be "best".
• Export your data to XML
• Reconfigure Confluence to use the new database - it's in <confluence home>/confluence.cfg.xml file, and if you're unsure of the details to put in for the new database, a quick cheat is to run a new install somewhere else, select the new database and then check what has gone into the file on the database lines
• Import the data from XML into the new system

Then look at the upgrade!

[westpfahl]

When you go through the upgrade procedure will it ask if you want to connect to database like when you first installed?

[Nic Brough -Adaptavist-]

No, the upgrade assumes the database will not move.

That's why I suggest moving database first - an upgrade is an intensive thing to do, and the internal database is not good at being loaded heavily!

[Bill Bailey]

@Nic Brough -Adaptavist- is right. Best to do the DB migration first, and I would move step 2 to step 1 --  take a snapshot backup before doing anything. With that backup, you can always set up a new instance correctly on another server and import your backup (in case disastor strikes).