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

[Rafal Somla]

Øystein Grøvlen wrote:
> 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.
>

You are right - I excluded DDLs from PTR scenario but they can be there. And as 
you note before, this is handled by the fact that DDLs are blocked during whole 
backup time.

>  > 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.
> 

By "arbitrary", I meant "any time during duration of BACKUP command" which, more 
correctly, should be "any time while DDLs are blocked".

I'll update the comment to include results of our discussion.

Rafal