Sorry but I can't catch your meaning. Calling bitmap_set_all() in
binlog_log_row() has nothing to do with read_set, and the engine read
just the columns needed in read_set. So calling bitmap_set_all() will
write all columns in before_record. However, those columns that are
not denoted in read_set is already missing in before_record, for the
engine just doesn't read them. So you will write out some NULLs or
Is that right?
On Wed, Nov 25, 2009 at 6:45 AM, Mats Kindahl <mats@stripped> wrote:
> Hi Yuan!
> Sorry for the late reply, I'm trying to juggle too many things currently.
> It is good that you managed to solve your problem, but there is still something
> that seems strange that I would like to make you aware of.
> Yuan Wang wrote:
>> Hi Mats
>> I have checked the code of 5.1 (current head version of 5.1 branch in
>> launchpad), and it don't seem to fill missing attributes automatically
>> when RBR is used.
>> The patch (http://lists.mysql.com/commits/40151) of bug 33055
>> (http://bugs.mysql.com/bug.php?id=33055) does the following change to
>> - if (file->ha_table_flags() & HA_PRIMARY_KEY_REQUIRED_FOR_DELETE)
>> + if (file->ha_table_flags() & HA_PRIMARY_KEY_REQUIRED_FOR_DELETE
>> + mysql_bin_log.is_open() && in_use &&
>> + in_use->current_stmt_binlog_row_based)
>> This patch has been pushed into 6.0. However,
>> st_table::mar_columns_needed_for_update don't have this change.
> That is correct, and the reason is because there were a patch pushed to 6.0 to
> make Falcon work correctly that made row-based replication only replicate the
> columns that are explicitly marked, but no other.
> However, for 5.1, the full row is written to the binary log regardless of what
> columns that are marked in the write_set.
> You can see this in the binlog_log_row function, where the columns are set in
> the following code (I marked the line):
> If there are no table maps written to the binary log, this is
> the first row handled in this statement. In that case, we need
> to write table maps for all locked tables to the binary log.
> if (likely(!(error= bitmap_init(&cols,
> use_bitbuf ? bitbuf : NULL,
> (n_fields + 7) & ~7UL,
> if (likely(!(error= write_locked_table_maps(thd))))
> error= (*log_func)(thd, table,
> &cols, table->s->fields,
> before_record, after_record);
>> It seems that if my storage engine mark the
>> HA_PRIMARY_KEY_REQUIRED_FOR_DELETE flag in table_flags, then the
>> server will add primary key to binlog automatically, which is just
>> what we need.
> Yes, that is correct, but I am still surprised that it affects replication, for
> the reason given above.
> Just my few cents,
> Mats Kindahl
>> On Fri, Nov 20, 2009 at 4:04 PM, Mats Kindahl <mats@stripped> wrote:
>>> Hi Yuan,
>>> In 5.1, the full row is sent over to the slave, so I am a little surprised
>>> there is anything missing at all.
>>> Do you have an example I can look at?
>>> Best wishes,
>>> Mats Kindahl
>>> Yuan Wang wrote:
>>>> We are developed a storage engine using row based replication. During
>>>> the test we found that primary key values will not be included in the
>>>> binlog event. So the slave is impossible to identify which row to
>>>> Is this a bug or is there a flag to tell MySQL to include primary key?
>>>> We are based on 5.1.33 currently.
>>> Mats Kindahl
>>> Senior Software Engineer
>>> Database Technology Group
>>> Sun Microsystems
> Mats Kindahl
> Senior Software Engineer
> Database Technology Group
> Sun Microsystems