- developers - lists.mariadb.org

[Maria-developers] [GSoC] Week Seven!
by sriram patil 07 Jul '14

07 Jul '14

Hi all, Following is the blog link about my seventh week into GSoC. http://goo.gl/jBeubY Suggestions and/or reviews are welcome! Thanks, Sriram

1 0

[Maria-developers] comments on parallel applying
by Jonas Oreland 04 Jul '14

04 Jul '14

hi there, disclaimer: i haven't followed all turns and details on this task so sorry if my comments are outdated (or generally uninteresting). --- i've been glancing on the review comments on the parallel applying, and have some comments to make. i think it will be well invested time to add infrastructure to be able to restrict when parallel applying will be performed. typically i think it would be nice to - only allow parallel transaction in same engine - decrease parallelism when … [View More]

3 4

[Maria-developers] Review request for MDEV-6020, MDEV-5914, MDEV-5941, and MDEV-5262
by Kristian Nielsen 04 Jul '14

04 Jul '14

Hi Serg, We discussed on IRC a review of the $subj bugs related to deadlocks in parallel replication and handling of automatic retry of transactions in case of deadlock. The patches are in my tree: lp:~maria-captains/maria/10.0-knielsen The complete diff can be obtained eg. with: bzr diff -rrevid:psergey@askmonty.org-20140429143317-tkmxrzu6y36hpi7t..revid:knielsen@knielsen-hq.org-20140610081315-o5nx3u32uvqaai7q Let me give some background for these bugs: When two transactions T1 … [View More]and T2 group-commit on the master, we assume that they have no lock conflicts (otherwise one would have had to wait for the other to commit). So we run them in parallel on the slave. But before we let T2 commit, we wait until T1 has committed first, so that we get the same binlog order on the slave as we had on the master. But if T1 and T2 somehow _do_ get a lock conflict on the slave, and T1 ends up waiting for some lock held by T2, we get a deadlock. This causes the replication to hang (the wait of T2 for T1 to commit is not part of InnoDB deadlock detection), which is quite bad. Elena's testing of the parallel replication in fact uncovered a number of cases where such deadlock issues occur: 1. MDEV-5914. It turns out that InnoDB gap locks can work in a non-symmetric way. If T1 is an INSERT, and T2 is a DELETE, then T1 can run first and not block T2. But if T2 runs first, then it may set a gap lock that blocks T1. Thus, depending on exact execution order, we can get T1 and T2 to group commit on the master, but T2 block T1 on the slave and cause a deadlock. 2. MDEV-5941. If eg. an UPDATE uses different execution plans on the master and slave, it might use index scan on the master, but table scan on the slave. Thus it may take more locks on the slave than on the master, causing it to conflict with another transaction that is run in parallel and cause a deadlock. 3. MDEV-6020. Here, there is a multi-value insert into multiple partitions of a table with auto-increment key. It appears that in this case InnoDB takes an auto-increment table lock on each partition. Since these locks are taken in the order of the inserted values, they can be taken in different order between different INSERT statements, and can cause a deadlock. Since these locks are released during the statement execution (before the commit), such deadlock can occur on the slave even though it did not occur on the master. (Note that this deadlock _is_ detected by InnoDB, and is not related to the commit order on the parallel slave). I know a way to prevent (1) on the slave (and it is implemented in the patches). I do not know if there is a way to prevent (3), it would require understanding better how innodb autoincrement and partitioning works. I do not see any way to prevent (2) from occuring on the slave, in the general case. It also seems to me that there are likely to be more corner cases lurking, and even if I somehow managed to fix the three above problems, there would be some other cases where an extra lock conflict can occur on the slave and cause the slave to hang. So I decided that a general solution is needed to such deadlocks. So the currently proposed patch does two things: A. It adds code to InnoDB, so that whenever T1 starts to wait inside InnoDB for a lock held by T2, this wait is reported to the upper server layer. The replication code will then check if T1 and T2 are part of parallel replication such that T1 must commit before T2. If so, we have a deadlock, and the code will terminate T2 with a deadlock error, allowing T1 to proceed. B. It implements code to handle deadlocks during parallel replication. When a transaction gets a deadlock error (normal, or provoked by the new deadlock detection code from (B)), it is rolled back, and re-executed. The result should be that even if there are other non-discovered cases where locks can conflict in different ways on the master from on the parallel slave, such conflicts will not cause replication to fail. Instead they will be detected, and handled automatically by resolving the deadlock. I think this will be important to ensure the reliability of parallel replication for users. I went through quite a few different ideas and attempts before ending with the present solution. So I wanted to give this background about how the patch relates to the basic problem that needs to be solved. I found a _lot_ of tricky issues during testing, and so I am somewhat unhappy about the complexity of this, even though the final patch may look simple enough on the surface. Maybe you can have some ideas for what could be done simpler, or at least question anything that looks incorrect or unnecessary. Thanks, - Kristian. [View Less]

2 3

[Maria-developers] Debian packaging - option to enable feedback plugin
by Colin Charles 04 Jul '14

04 Jul '14

Hi! This is probably a great idea: https://answers.launchpad.net/maria/+question/248639 Let's ask dpkg to optionally enable feedback plugin? This could be good for us Just to be clear: I'm referring to this for the packages at mariadb.org I don't know if Debian upstream would like that -- Otto, any thoughts? cheers, -colin -- Colin Charles, Chief Evangelist, SkySQL - The MariaDB Company blog: http://bytebot.net/blog/| t: +6-012-204-3201 | Skype: colincharles

5 5

Re: [Maria-developers] Review request for MDEV-6020, MDEV-5914, MDEV-5941, and MDEV-5262
by Kristian Nielsen 04 Jul '14

04 Jul '14

Jan Lindström <jan.lindstrom(a)skysql.com> writes: > 1) In innodb deadlock detection it is not certain that there is actually a > deadlock, deadlock detection is done when a lock request is issued. At that > point yes, we can see from lock manager that there is a deadlock, however > if waiting transaction is rolled back e.g. by user request concurrently, > the deadlock detected is not valid anymore. Hm, interesting. It was my impression that the deadlock detection … [View More]algorithm only considers transactions that are already waiting for a row lock. That is, if we detect a simple deadlock between two transactions T1 and T2, then it is because T2 is waiting for a row lock held by T1 while executing some user query, and T1 is executing another user query that requests another row lock held by T2. So since both T1 and T2 are already executing user queries, and will not complete until the deadlock is resolved, how could the user roll either of them back concurrently? > 2) It is fine to roll back all transactions participating to deadlock, this > is correct. Note that there are some preferences which transaction is > rolled back on normal InnoDB server and this could be different when we > have Galera > 3) How this new needs to wait work with Galera where we have so called > brute force transactions that may not wait anything ? Note that this is only for resolving deadlocks between replicated transactions from a single master. If T1 and T2 are both replicated from the same master, we might decide to kill T2 to let T1 commit first. If I understand correctly, "brute force" transactions are only for transactions that are replicated from other Galera nodes, and which _must_ be committed in a specific order to preserve correctness. Thus, a brute-force transaction would not be affected by a deadlock kill from parallel replication. Galera code might cause a parallel replication transaction to be rolled back and retried, but this should be fine. Note also that in general for MySQL/MariaDB style replication, it is assumed (and it is the user's responsibility to ensure it) that replicated transactions will not conflict with anything done on the local node. This might also help to provide that Galera and parallel replication will not conflict. If Galera had been written with a proper general high-level API that could work with different storage-engines, then we could probably have used the "brute force transaction" mechanism to solve this problem in parallel replication also. But when I checked it, it seemed that it was hardcoded inside InnoDB with lots of Galera-specific code and data structures. If work were to start to fix this lack of proper API in Galera, then perhaps it would be interesting to work together to design a general API for enforcing a specific commit order... - Kristian. [View Less]

1 0

[Maria-developers] [GSoC] optimize mysql-test runs - Preparing next steps
by Pablo Estrada 04 Jul '14

04 Jul '14

Hello Elena, I understand that the recall that we are achieving so far should still be improved; nonetheless, since we are already in the second half of the summer, I was wondering if we should spend some time designing the interfaces for the implementation of the project; such that I can start building them (even though the research phase can't be marked off as completed yet). Regards Pablo

2 1

Re: [Maria-developers] MDEV-5756 CMake option to build without thread pool
by Sergei Golubchik 03 Jul '14

03 Jul '14

Hi, Holyfoot! On Jul 01, holyfoot(a)askmonty.org wrote: > revno: 4270 > revision-id: holyfoot(a)askmonty.org-20140701104158-4gj5ztnjqlr1alwa > parent: holyfoot(a)askmonty.org-20140630193024-56wpcvwwy24kuzt4 > committer: Alexey Botchkov <holyfoot(a)askmonty.org> > branch nick: mdev-5756 > timestamp: Tue 2014-07-01 15:41:58 +0500 > message: > MDEV-5756 CMake option to build without thread pool. > Check if the threadpool is available on the system and … [View More]

1 0

[Maria-developers] [GSoC] Optimize mysql-test-runs - Analyzing some data
by Pablo Estrada 02 Jul '14

02 Jul '14

Hello Elena and all, I have spent a couple of days writing up some scripts to analyze the data, and try to find good candidates for metrics to improve recall, or some vices in the way the relevance is calculated for tests, such that they are not close enough in the priority queue to be spotted and run. Here's a writedown of some of the findings: *Of the failures that we miss, how many of them come from tests that have never failed before?* I added a small function in the simulator.py code, to … [View More]keep diagnostics data of the test failures that we missed. I made a few charts regarding missed failures of tests that have never failed before (and, in the current model, we can't calculate a relevancy for them, because we have no data about them). In the next chart, we observe the percentage of missed failures that come from tests that had never failed before increases with time (as expected): By the way, this info comes from a standard run with 3000 learning cycles and 2000 prediction cycles. I feel that this is an important area. If we can figure a way to predict failures of tests that have not failed before, then we can predict subsequent failures of these tests, and thus improve recall significantly, specially over the long term. On the next section I analyze the option that I considered. *Is there a relationship between a test file being modified and the test failing any soon?* I figured that a good idea to catch failures of tests that had never failed before could be using the test file changes. If a test file is changed, I figured that the test itself would change behavior and might fail soon, and thus we could gather some data about that failure. I coded a small script that computes the number of test runs between a test file being edited, and the same test failing sometime in the future. The relationship, unfortunately is not very strong. I have attached the chart with the cummulative histogram of number of test runs that occurred between a test file being edited, and the next failure of that test. Unfortunately, the results were not too exciting. It turns out that tests don't tend to fail too soon after they have been changed (I guess this also makes sense). The following figures present the data (and a zoom in of the part of the graph we care most about), showing that failures are not very subsequent to test file editions. Not even 10% of failures occur in the first 100 runs. As we can see from the charts, there is not a very significant relationship between test file edition and subsequent failure. It seems this indicator won't be too useful. I am* still looking for ideas* on how to catch tests failing for the first time. They are all welcome : ) This is all the data that I collected so far. I am also trying to answer the following question: Failures of tests with non-zero relevance. How come we are missing those that we are missing? I have collected and charted some data, but I still haven't found anything that feels conclusive or revealing. I expect to write an email with that info soon as well, but I decided to send this out first. In conclusion: - I am thinking about how to predict first failures of a test. Any ideas? - I tested the relation between edition of a test result file and subsequent test failure. It was not a good predictor. Regards Pablo [View Less]

1 0

[Maria-developers] [GSoC] Week Six!
by sriram patil 30 Jun '14

30 Jun '14

Hi all, Following is the blog link about my sixth week into GSoC. http://goo.gl/1dzgHe Suggestions and/or reviews are welcome! Thanks, Sriram

3 2

Re: [Maria-developers] [Commits] Rev 3855: Bumping server version. (10.0.13-galera) in lp:~maria-captains/maria/maria-10.0-galera
by Roberto Spadim 30 Jun '14

30 Jun '14

=] nice nirbhay 2014-06-30 10:33 GMT-03:00 Nirbhay Choubey <nirbhay(a)skysql.com>: > Hi, > > On Mon, Jun 30, 2014 at 9:13 AM, Roberto Spadim <roberto(a)spadim.com.br> > wrote: >> >> this will be a production ready version? > > > 10.0.12-galera (released over weekend) is the first 10.0-galera stable > release. This 'patch version bump' is > for preparation towards the next release. > > Best, > Nirbhay > >> >> >> … [View More]

1 0