I have a database setup for replication. I used mysqldump --opt db > db.dmp
to do the initial backup of the primary database (after doing a flush tables
with read lock in a seperate session).
I checked the dump file, and all drop table create table statements are in
the file. When I did a restore to the second database with a mysql
--on-database db < db.dmp, it appears that the tables were not dropped and
recreated. No errors were displayed during this process. After the
restore, I was able to start replication, and replication ran fine, until it
encountered an object which was not in the secondary database which was in
the primary.
The schema looks to be the old schema (pre database restore), and table
drops/creates appear to have been done from the dump file. Any ideas
why/how this would be? My dump file is about 14 Gig.
Joe:
Did you make sure to do RESET MASTER/RESET SLAVE trick, or otherwise adjust the replication log coordinates for the slave to start at the right place?
--one-database should not be necessary, and having it could possibly be triggering some weird bug or a poorly documented feature. mysql db < dump.sql should be sufficiet to restore.
P.S. If you are using MyISAM, binary snapshot would work better for this much data. For InnoDB, hotbackup utility is a good investment.
-- Sasha Pachev Create online surveys at http://www.surveyz.com/
-- MySQL General Mailing List For list archives: http://lists.mysql.com/mysql To unsubscribe: http://lists.mysql.com/[EMAIL PROTECTED]
