Re: bzr commit into mysql-6.0-backup branch (Rafal.Somla:2734) Bug#40262

[Øystein Grøvlen]

Rafal Somla wrote:
 > Hi Chuck,
 >
 > Thanks for review. See my explanations below.
 >
 > Chuck Bell wrote:

...

 >>  > +  /*
 >>  > +    If there no tables to backup, there is nothing to do in this
 >> function
 >>  > +    except for storing and reporting the validity point info.
 >>  > +    +    Note that since backup image contains no table data, any
 >> time is a good
 >>  > +    validity time -- there is no issue of synchronizing the data
 >> stored in +    the image with the data in the rest of the server.
 >>  > +  */
 >>
 >> [2] I am not certain of this. I think it does matter what time is used
 >> and it should be accurate. Consider a backup done when tables are
 >> empty, some data is added, then the system crashes. User wants to do
 >> PTR but if the VP is "any good time" then it won't be accurate. Please
 >> convince me that we are still setting the VP correctly in this
 >> scenario and if so, remove the comment that seems to indicate that we
 >> are arbitrarily choosing a VP time.
 >>
 >
 > Please note the difference between these two situations:
 >
 > 1. We backup some tables but these tables are empty.
 > 2. We do not backup any tables.
 >
 > In the first case you are right, VP must be constructed carefully using
 > the synchronization protocol and this is what will happen, because in
 > that case info.table_count() != 0 and the branch below will not be 
entered.
 >
 > However, in the second case VP time can be chosen arbitrarily because
 > there are no tables whose data could be not correctly aligned with the
 > VP. Note that a backup image which contains no tables can not be used
 > for PTR. Such image basically stores only metadata which will be used to
 > create global objects but not to restore any table data and thus not to
 > roll forward from the restored data.

I do not understand why a backup image with no tables can not be used
for PTR.  Are you saying that PTR can not contain DDL?  If it can, I
would imagine that PTR could involve creation of tables and insertion
of data.  In such a scenario, an arbitrary VP time could mean that PTR
would not create tables that should be created or try to drop tables
that has already been dropped.

 > Thus in case 2 VP can be chosen arbitrarily and this is what we are
 > doing. I think a comment is in place because readers of the code may ask
 > themselves the same question you asked.

As far as I can tell, you are not choosing an arbitrary VP time.  You
are choosing current time during backup.  This is OK since the DDL
blocker prevents tables from being dropped and created during backup.
Hence, using current time for VP time will specify a time when there
was no tables in the database, and that is what we want.

-- 
Øystein