On 2011-03-03 15:36, Alfranio Correia wrote:
> Hi Magnus,
>
> The patch looks fine. However, I need some context to understand what
> are your goals. Please, file a bug report and I will take another look
> at it and approve it.
Thanks a lot for your quick review. Will write a bug report describing
this functionality.
Maybe something like the manual writes at
http://dev.mysql.com/doc/refman/5.1/en/mysql-cluster-replication-starting.html
will do? :)
"
Beginning with MySQL Cluster NDB 6.2.3, it is possible to improve
cluster replication performance by enabling batched updates. This can be
accomplished by setting the slave_allow_batching system variable on the
slave mysqld processes. Normally, updates are applied as soon as they
are received. However, the use of batching causes updates to be applied
in 32 KB batches, which can result in higher throughput and less CPU
usage, particularly where individual updates are relatively small.
Note
Slave batching works on a per-epoch basis; updates belonging to more
than one transaction can be sent as part of the same batch.
All outstanding updates are applied when the end of an epoch is reached,
even if the updates total less than 32 KB.
Batching can be turned on and off at runtime. To activate it at runtime,
you can use either of these two statements:
SET GLOBAL slave_allow_batching = 1;
SET GLOBAL slave_allow_batching = ON;
If a particular batch causes problems (such as a statement whose effects
do not appear to be replicated correctly), slave batching can be
deactivated using either of the following statements:
SET GLOBAL slave_allow_batching = 0;
SET GLOBAL slave_allow_batching = OFF;
"
/ Magnus
>
> See minor comments in-line.
>
> Cheers.
>
> On 02/21/2011 01:18 PM, Magnus Blåudd wrote:
>> #At file:///data0/magnus/mysql/5.5-telco-7.0/ based on
> revid:magnus.blaudd@stripped
>>
>> 3217 Magnus Blåudd 2011-02-21
>> ndb
>> - add MCP patch for WL3733 slave_allow_batching
>> - update sys_vars.slave_allow_batching testcase
>>
>> @@ -7821,7 +7827,11 @@ int Rows_log_event::do_apply_event(Relay
>> }
>> } // if (table)
>>
>> -
>> +#ifndef MCP_WL3733
>> + /* reset OPTION_ALLOW_BATCH as not affect later events */
>> + thd->variables.option_bits&= ~OPTION_ALLOW_BATCH;
>> +#endif
>> +
>
> I think this is not necessary.
>
>
>
>> if (error)
>> {
>> slave_rows_error_report(ERROR_LEVEL, error, rli, thd, table,
>> @@ -9152,6 +9162,24 @@ int Rows_log_event::find_row(const Relay
>> table->s->reclength) == 0);
>>
>> */
>> +
>> +#ifndef MCP_WL3733
>> + /*
>> + Ndb does not need read before delete/update (and no updates are sent)
>> + if primary key specified
>> +
>> + (Actually uniquekey will also do, but pk will be in each
>> + row if table has pk)
>> +
>> + Also set ignore no key, as we don't really know if row exists...
>> + */
>> + if (table->file->ht->db_type == DB_TYPE_NDBCLUSTER)
>> + {
>> + table->file->extra(HA_EXTRA_IGNORE_NO_KEY);
>> + DBUG_RETURN(0);
>> + }
>> +#endif
>
> Sorry but I did not get what you are trying to achieve with this part of the patch.
> Maybe, due to lack of some context. Can you file a bug report and improve your
> comments?
