In my adventures over the last few days, I've learned a few things the
hard way. When doing a complete dump and restore of the dbmail
database (I'm running 2.2.15), never use "--skip-opts"
That's a bad thing. It causes all kinds of problems. I found
that the following works quite nicely. My dbmail database is around
2.2GB.
mysqldump --password=<your password here>
--add-drop-table --add-locks --create-options --disable-keys --set-charset
--extended-insert --databases dbmail
The dump happens fairly quickly.
compress file for transfer, a little longer.
transfer 1.1GB from a server in Maine to a server in Boston,
longer.
decompress file for import, a little faster.
drop dbmail database on 2nd server then restore from dump, longer
still. (about 1/2 hour or so.)
binlog setup that I've started to use.
Master
/etc/mysql/my.cnf
server-id
= 1
log_bin
= /var/log/mysql/mysql-bin.log
expire_logs_days = 10
max_binlog_size =
100M
binlog_do_db
= dbmail
Slave /etc/mysql/my.cnf
#log_bin
= /var/log/mysql/mysql-bin
#expire_logs_days
= 10
#max_binlog_size
= 100M
#bin_log_do_db
= dbmail
server-id
= 2
If running from the backup, I would then un-comment
the the binary log options and restart mysql prior to starting
dbmail. then I can restore from a point in time to the primary.
There is more to getting replication set up, the documentation is
on the mysql website. If there is any interest in a How-
To,
I'll be happy to write one. There are a few queries that have to be
run and all of it needs to be started with identical database
snapshots.
--Curtis
_______________________________________________
DBmail mailing list
[email protected]
http://mailman.fastxs.nl/cgi-bin/mailman/listinfo/dbmail
