That's a good challenge. Have you tested semi-synchronous replication yet?
So, after a COMMIT, the binlog file will receive the new stetament. You can
verify new stmts on the file and make it unique based on eng_log_pos. What
do you think?
2010/12/1 Niv Dalal <niv.dalal@stripped>
> Actually my question was a bit different, yet may be even more complex than
> I thought based on your answer below.
> I want to have some external mechanism that will allow an application to
> keep track of its commits and verify that a specific one is already
> available in the replication DB before it submits a query over there.
> Can I associate the Xid in the log to a specific commit that I'm doing from
> the client?
> On Wed, Dec 1, 2010 at 7:25 AM, Johan De Meersman <vegivamp@stripped>wrote:
>> Yes, I see what he means. My first thought was "but the binlog records the
>> thread IDs of each statement, doesn't it" - but I find that it doesn't
>> output it for commits (or even any non-SQL/DML), for some reason.
>> Regular statement:
>>> # at 145848
>>> #101201 8:16:02 server id 4 end_log_pos 145961 Query
>>> thread_id=285357510 exec_time=0 error_code=0
>>> SET TIMESTAMP=1291187762;
>>> DELETE FROM flood WHERE timestamp < 1291184162;
>>> # at 185354
>>> #101201 8:19:35 server id 4 end_log_pos 185381 Xid = 22794780179
>> Note the absence of a thread_id in the latter - it has the XA transaction
>> ID instead, but the Xid is also not specified by any specific statements
>> belonging to that transaction as far as I can see.
>> The information must be in there, or replication couldn't work; but
>> mysqlbinlog doesn't show it, apparently.
>> An interesting question indeed, and one I'd like to know the answer to.
>> Bier met grenadyn
>> Is als mosterd by den wyn
>> Sy die't drinkt, is eene kwezel
>> Hy die't drinkt, is ras een ezel