274319 - New FAQ regarding how to move a Bugzilla installation

Status: RESOLVED FIXED

(Bugzilla :: Documentation, defect, P3)

Description

[Vlad Dascalu]

Dave replied to this one on the mailing list:

> we are migrating our actual bugzilla system intalled on a linux machine on
client requierment to windows platform, and we have had some problems, like that
database tables are no equals so we can't save old bug's and we need it.
>
> I wonder if any one of you has made this migration, and how do you solve this
problem. We think in use bugzilla 2.16 version, but it doesn't work in windows
platform and on client requierment we must use this platform.


Use mysqldump to make a backup of the bugs database on the Linux machine.  See
the MySQL docs for using mysqldump and how to restore it on the destination machine.

As long as you have no local customizations that you've made to the code, just
unpack the 2.18(rc?) tarball on the destination machine where you plan to
install it, and then copy the localconfig file and the data directory from the
old machine to the new one.

Make corrections to localconfig so it can find the new location of the database
(if needed -- if it was localhost anyway, it may be fine).

When you run checksetup.pl the first time, it will take care of upgrading the
database from 2.16 to 2.18 format.

This is getting to be a bit of a FAQ, maybe we'll have it there soon.

Comment 1

[Vlad Dascalu]

Attachment: v1

Jake, Shane: I agree that probably the phb chapter in the FAQ needs to be
divided in two: one part for BZ admins and one part for BZ PHBs. We currently
have both types of questions in equal proportion over there.

However, I think we can commit this FAQ now in there and move the split for
another patch.

Comment 2

[Vlad Dascalu]

Attachment: v1

Oops, wrong patch :)

Comment 3

[Jacob Steenhagen]

This patch should probably wait until after the FAQ overhaul is done. Also, the
best procedure for moving to another machine is really to backup from one
machine and restore it on the second. This seems to be getting more into backup
stradegies in general, so perhaps we should include more of that kind of
information (instead of just a link to MySQL's backup page).

Comment 4

[Shane H. W. Travis]

I'm with Jake; FAQ overhaul is (hopefully) very close to landing (new 
iteration/patch coming this afternoon), and this question will definitely be in 
another section after that's done. Also, I think it could use a bit of a re-
write rather than directly taking what Dave said, just so it's 100% clear what 
the focus of the question and answer are.

If you want me to take responsibility for this, Vladd, I will; just reassign it 
to me and I'll get it into the overhaul. If you want to do it yourself, then I 
request that you wait until that is done.

Comment 5

[Shane H. W. Travis]

Comment on attachment 168561 [details] [diff] [review]
v1

Okay, now that the FAQ overhaul has landed, I'll give this one the r- I knew
I'd have to. :(

* It needs to go in the faq-admin section, now that it exists
* Line length is > 80 chars in several places
* The Q is really vague; move it? Where? Why? 
* Paragraph 2: I'd recommend including a standard 'mysqldump' command
    to dump the bugs database. I know it's out-of-scope, but it's one 
    line to help them get it right, and you can still tell them to read 
    the docs for info on how to restore.
* Paragraph 3 could use some more specifics, IMHO. You only need to 
    change localconfig if the *location* of the SQL server has changed
    (I think), not merely the version (as the question implies). Also, 
    change *what* in the localconfig? Some guidance would be good.

Comment 6

[Shane H. W. Travis]

Vlad, I've seen this question come up a couple of times in the last few 
weeks... do you want to finish this one off, or do you want to hand it off to 
me to be polished up and polished off?

Comment 7

[Vlad Dascalu]

Shane: I won't be able to finish this up so you taking care of it would be
wonderful.

Comment 8

[Shane H. W. Travis]

Attachment: Doc changes for 2.18 and tip

Comment 9

[Colin Ogilvie [:cso]]

(In reply to comment #5)
> * Paragraph 2: I'd recommend including a standard 'mysqldump' command
>     to dump the bugs database. I know it's out-of-scope, but it's one 
>     line to help them get it right, and you can still tell them to read 
>     the docs for info on how to restore.

If you're telling them how to dump it, you might as well suggest how to restore
it too, IMO.

Comment 10

[Shane H. W. Travis]

(In reply to comment #9)

> If you're telling them how to dump it, you might as well suggest how
> to restore it too, IMO.

I disagree. Getting a dump wrong can't hurt anything; the database is still 
intact, and the worst that can happen is you end up with no data dumped... 
which will become apparent when you try and restore, or look at the file size. 
Screwing up a restore, however, could mess up an existing MySQL installation, 
so they should go and learn how to do it properly. This is MHO, and is why I 
did it as I did.

Comment 11

[Colin Ogilvie [:cso]]

Comment on attachment 176205 [details] [diff] [review]
Doc changes for 2.18 and tip

>+          <para>
>+            Use mysqldump to make a backup of the bugs database. For a
>+            typical Bugzilla setup, such a command might look like this:
>+            <programlisting>
>+/usr/bin/mysqldump -u(username) -p(password) --database bugs > bugzilla-backup.txt
>+            </programlisting>
>+            See the <ulink url="http://dev.mysql.com/doc/mysql/en/mysqldump.html">
>+            mysqldump documentation</ulink> for more information on using 
>+            the tool, including how to restore your copy onto the destination
>+            machine.
>+          </para>

For multi-user machines this could be considered a security risk. If the DB is
large enough such that mysqldump takes a while to run, the password may be
visible in `ps aux` - not sure if this is something that should be noted in the
docs or not, but I thought I'd mention it anyway.

r+ pending thoughts on this point.

Comment 12

[Colin Ogilvie [:cso]]

Travis,

You have a xref with the linkend intalling-bugzilla - it should be
installing-bugzilla. I won't r- the patch for it, but can you fix it on checkin?

Comment 13

[Dave Miller [:justdave]]

stick the password in ~/.my.cnf and then it won't show up in the ps ax listing.

[mysqldump]
user=bugs
password=mypassword

Then just leave the user and password params out of the command line.

Comment 14

[Shane H. W. Travis]

Attachment: Doc changes for 2.18 and tip, take 2

Getting sort of big for a FAQ entry... but we can figure out a better home for
it on a future re-org.

Comment 15

[Colin Ogilvie [:cso]]

Comment on attachment 177926 [details] [diff] [review]
Doc changes for 2.18 and tip, take 2

Thanks for addressing my security concern - I'll trust the mysqldump stuff that
Dave said as being accurate.

Comment 16

[Vlad Dascalu]

Checking in docs/xml/faq.xml;
/cvsroot/mozilla/webtools/bugzilla/docs/xml/faq.xml,v  <--  faq.xml
new revision: 1.27.2.7; previous revision: 1.27.2.6
done
Checking in docs/xml/faq.xml;
/cvsroot/mozilla/webtools/bugzilla/docs/xml/faq.xml,v  <--  faq.xml
new revision: 1.34; previous revision: 1.33
done