Alexi1952 <Alexi1952@yandex.ru> 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.