Marc Dirix wrote: > This is not the same. > >> 1) flush all pending writes and lock the database as read-only > > Postgres does not flush pending writes, and also does not set the > database read-only. >
Is this considered a good thing...? I mean I am about to save away the actual database binaries. >> 2) force a binlog rotation so you know exactly where the snapshot was taken >> 3) make a LV snapshot (takes care of all sync()s at fs level) >> 4) unlock everything (the lock persists while the snapshto is created, >> which lasts about half a second) >> >> Then I go ahead and slowly backup/compress/whatever I want the database >> files from the snapshot volume >> >> >> When shit hits the fan: >> =========================== >> >> 1) Stop the database >> 2) Unpack the mysql data directory saved from the latest snapshot (since >> the snapshot was made within a read-lock, the database is guaranteed to >> be consistent) > > With PITR you can recover to *any* point in time. Not just your snapshot > time. It is completely different. PITR is a query log which starts from > your snapshot onward. So sunday snapshot day (without locking or > read-only) then continueing with query logs up to crash day. Again - how do you take a consistent snapshot on Sunday without ensuring a lock? > However, I would not even think about using it with dbmail. Because it > slows down your database. For every INSERT and UPDATE query the data has > to be saved twice. Once in the database and once in the log. > Not sure about PG - the penalty in MySQL is in the low single digits. It's not like fsync() is called on every logwrite. _______________________________________________ DBmail mailing list DBmail@dbmail.org https://mailman.fastxs.nl/mailman/listinfo/dbmail
