maria-developers team mailing list archive

[Kristian Nielsen <knielsen@xxxxxxxxxxxxxxx>]

Alexi1952 <Alexi1952@xxxxxxxxx> writes:

> The Query event binary format is extended with a tables info, i.e. the list of
> tables involved in the query execution. More precisely, two following fields are
> added to the Query event header:
>
>   * Query length (2 bytes). (Reason: in usual format, Query event doesn't include
>     this field because the query is considered to extent to the end of the event
>     what is not the case for the extended format).
>
>   * Tables info length (2 bytes). Length of tables info contained in the data
>     part of the event.
>
> and the following data is added to the Query event data part:
>
>   * Tables info (tables_info_len bytes). List of 4-tuples
>     (db_len, db, table_name_len, table_name) for each table involved in the
>     execution of the query described by this event.
>     db_len may be zero meaning that this is the default db.

This sounds somewhat dangerous. We need to consider the effect on
compatibility with other servers which do not have this change.

As far as I understand, MySQL replication is backwards and forwards
compatible. This means that an old slave can replicate from a new master, and
a new slave can replicate from an old master. I guess there must be some kind
of limitations for this, but I remember seeing lots of code in the replication
sources to handle such issues.

Therefore, when proposing changes to the event format, we need a full analysis
of the consequences for replicating from/to different server versions. We also
need to consider replication to/from Sun MySQL, which probably means some kind
of coordination with Sun replication engineers. (I'm not saying that we cannot
change replication event formats, just that we need to do it really
carefully).

Also, don't know if this worklog is being actively worked on, just wanted to
remark this to be sure it is not forgotten.

Hope this helps,

 - Kristian.