quoting Alan Williamson <[EMAIL PROTECTED]> ..
>> This recipe is intended to minimize the impact on ongoing database
>> operations by inhibiting writes only during a relatively speedy
>> operation (creating a snapshot). The long dump operation can ...
>
>This seems to be a rather long winded way of doing this. Why not
>replicate the database and therefore not have to bring it down ever.
>
>I wrote a blog entry about this very thing, and had some interesting
>comments back on
> http://blog.spikesource.com/mysql_hotbackup.htm
>
>Hope this helps,
Thanks for the input.
It does seem more complicated than it ought to be, doesn't it?
The reason for trying to do it that way
(eg:
flush tables with read lock, create snapshot, unlock
mount snapshot & run 2nd mysqld, mysqldump,
kill 2nd mysqld, umount snap, remove snap,
whew!)
is that I have only one server, and believe that the snapshot was
invented just for such a purpose -- namely: quickly capture a point-in-
time image of the database for a leisurely backup.
In more words, locking is deemed required to achieve a consistent db
state for a backup operation, but the lock need only be held during the
short time required to create the snapshot. Then the much longer backup
(dump) operation can proceed by reading from the (effectively static) db
contained in the snapshot.
Your suggestion is appreciated, Alan, but if I have only one server, it
seems that my question still remains: Am I missing something? Is there
something silly or unwise about this strategy? Do I have misconceptions
about making the database consistent in preparation for backup?
..jim
--
MySQL General Mailing List
For list archives: http://lists.mysql.com/mysql
To unsubscribe: http://lists.mysql.com/[EMAIL PROTECTED]
