[Maria-developers] WL#132 New (by Knielsen): Transaction coordinator plugin
--- WORKLOG TASK -=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=- TASK...: Transaction coordinator plugin CREATION DATE..: Tue, 24 Aug 2010, 14:06 SUPERVISOR.: IMPLEMENTOR: Knielsen COPIES TO..: CATEGORY...: Server-Sprint TASK ID: 132 (http://askmonty.org/worklog/?tid=132) VERSION: Server-9.x STATUS.: Assigned PRIORITY...: 60 WORKED HOURS...: 0 ESTIMATE...: 0 (hours remain) ORIG. ESTIMATE.: 0 PROGRESS NOTES: DESCRIPTION: This worklog describes an API that allows a replication plugin to hook deep into the commit mechanism of transactions in mysqld and implement its own transaction coordinator (TC). The existing binary log already implements a TC. This is used to make writes to the binary log happen in 2-phase commit with transactional engines. It is also used during crash recovery to get the list of prepared-but-not-committed transactions from the binary log and ensure that those transactions are committed (and any others rolled back), to avoid inconsistencies between the contents of binary log and engines. Thus the TC needs to be part of a replication API that allows the existing binary log implementation to be written as a plugin, or to allow the implementation of a replacement binary log. In addition, something like Galera synchronous replication needs more control over the commit process. In particular, it needs to be able to control the order in which transactions are committed. This worklog extends the TC interface to also allow TC to control commit order. This part of the worklog builds on the work in MWL#116, in particular on the prepare_ordered() and commit_ordered() extensions to the storage engine API. ESTIMATED WORK TIME ESTIMATED COMPLETION DATE --- WorkLog (v4.0.0) ___ Mailing list: https://launchpad.net/~maria-developers Post to : maria-developers@lists.launchpad.net Unsubscribe : https://launchpad.net/~maria-developers More help : https://help.launchpad.net/ListHelp
Re: [Maria-developers] DS-MRR improvements patch ready for review
The tree is in launchpad and buildbot also:
https://code.launchpad.net/~maria-captains/maria/5.3-dsmrr-cpk
and all observed buildbot failures in the tree are known to occur without
the
new code as well.
The above mentioned tree has DS-MRR improvements that are ready for
testing.
Hi, thanks for the tree. I have already started testing it and filing bugs
for you.
Checking if new code is used
Execution passes through the new code if the EXPLAIN has tables that have
type=[eq_]ref, Extra has 'Using join buffer'.
I am afraid it is not sufficient to properly figure out which optimization
causes which issue, especially after your code is merged into the main tree.
It is very important that each 5.3 optimization has its own distinct comment
in the "Extra" field (or at the very least, in EXPLAIN EXTENDED). Can you
hack that quickly today or tomorrow?
- Run the query with bigger/smaller value of @@join_buffer_size (this is
where
I've found and fixed a big number of problems already).
- where the join buffer is exhausted at various stages of accessing table
t1 (need
to try with different key sizes, join buffer sizes, and many-table joins)
What values would you suggest? Currently I am running with
join_buffer_size={1,100,1K,10K,100K} . There are 3 to 5 tables per query,
with 1 to 1000 rows per table.
Unfortunately, I am hitting quite a few MRR/DSS/BKA bugs that are also
present in maria-5.3 Some of them have been filed in the past in the MySQL
tracker and some have been fixed by the MySQL guys. Others however appear to
not be known, since BKA testing was never completed back in the day.
So, how are we going to handle this? Essentially you have created new
optimizations on top of a foundation that is still buggy and unstable from
the 6.0-codebase days. Who and when will be able to fix the foundation and
make it stable?
Philip Stoev
___
Mailing list: https://launchpad.net/~maria-developers
Post to : maria-developers@lists.launchpad.net
Unsubscribe : https://launchpad.net/~maria-developers
More help : https://help.launchpad.net/ListHelp
Re: [Maria-developers] Ipv6
Hi, ipv6 INET_ATON and INET_NTOA would be mainly usefull to application compatibility, and painless ipv6 migration. For example, in my PHP script I'm using almost everywhere INET_ATON to store $_SERVER['REMOTE_ADDR']. If INET_ATON and NTOA are supported, I only have to change the column type storing my IP values to be able to store 128-bit integers, without changing anything else in the code. Thanks, Jocelyn Le 23/08/2010 18:53, Sergei Golubchik a écrit : Hi, Jocelyn! On Aug 23, Jocelyn Fournier wrote: Hi Sergei, What about INET_ATON / INET_NTOA ipv6 support ? (there's a feature request opened on mysql since jan 2008 : http://bugs.mysql.com/bug.php?id=34037 ) They would need to convert to and from DECIMAL. It's doable. If you mean 128-bit integers, adding them is more complex, I guess, than adding a native ipv6 type (which is implemented on top of binary(16) internally). Why one would need INET_NTOA6 and INET_ATON6 ? INET_ATON can be used to convert an ip address to store it in the table, to save storage space. INET_ATON can be used to convert an ip address to a number to check against a subnet mask. Anything else ? Because if there is IPv6 native type there will be no need to convert for storage and no need to convert for a mask check. Regards, Sergei ___ Mailing list: https://launchpad.net/~maria-developers Post to : maria-developers@lists.launchpad.net Unsubscribe : https://launchpad.net/~maria-developers More help : https://help.launchpad.net/ListHelp ___ Mailing list: https://launchpad.net/~maria-developers Post to : maria-developers@lists.launchpad.net Unsubscribe : https://launchpad.net/~maria-developers More help : https://help.launchpad.net/ListHelp
