On 04/10/2012 02:15 PM, Martin Simmons wrote:
> Sorry, I didn't mean mysqldump on its own.
>
> The MySQL documentation suggests that you can make a backup from the output of
> mysqldump plus later binlogs and then use them to restore a database, but what
> use is that if it doesn't work with temporary tables?
>
> For this to work, all transactions should either be entirely in the output of
> mysqldump or entirely in the later binlogs. This could probably work if
> temporary tables are used within a transaction, because hopefully mysqldump
> will wait for it to finish. It probably can't work if temporary tables are
> used without a transaction.
You shouldn't think of a temporary table as persistent DB data. Think
of them instead as part of the transient state of a single ongoing
transaction. Is it a reasonable expectation for a DB restore to be able
to restore any part of the transient state of a transaction that
happened to be running when the backup was made? Even if it could,
where would the results go?
There's no way to resume an interrupted transaction from the middle, and
so there's no point in backing up any of its state except to roll back
anything it's already partly done. If you want to repeat the
transaction, you have to restart it from the beginning, which will
recreate any temporary tables it was using anyway.
--
Phil Stracchino, CDK#2 DoD#299792458 ICBM: 43.5607, -71.355
ala...@caerllewys.net ala...@metrocast.net p...@co.ordinate.org
Renaissance Man, Unix ronin, Perl hacker, SQL wrangler, Free Stater
It's not the years, it's the mileage.
------------------------------------------------------------------------------
Better than sec? Nothing is better than sec when it comes to
monitoring Big Data applications. Try Boundary one-second
resolution app monitoring today. Free.
http://p.sf.net/sfu/Boundary-dev2dev
_______________________________________________
Bacula-users mailing list
Bacula-users@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/bacula-users
