mdev_6740.sh
test_galera_sync.py
[MDEV-6740] Galera crash in rpl_sql_thread_info/cached_charset_compare Created: 2014-09-13 Updated: 2014-09-22 Resolved: 2014-09-22 |
|
| Status: | Closed |
| Project: | MariaDB Server |
| Component/s: | Galera |
| Affects Version/s: | 10.0.13-galera |
| Fix Version/s: | 10.0.14-galera |
| Type: | Bug | Priority: | Blocker |
| Reporter: | Kolbe Kegel (Inactive) | Assignee: | Nirbhay Choubey (Inactive) |
| Resolution: | Fixed | Votes: | 0 |
| Labels: | None | ||
| Environment: |
RHEL 6.5 x86-64 |
||
| Attachments: |
mdev_6740.sh
test_galera_sync.py
|
| Description |
|
I'm doing INSERT on one node and UPDATE on another. It often leads to a crash on the node where I'm executing UPDATE. Thread pointer: 0x0x7f711aff3008 Trying to get some variables. Optimizer switch: index_merge=on,index_merge_union=on,index_merge_sort_union=on,index_merge_intersection=on,index_merge_sort_intersection=off,engine_condition_pushdown=off,index_condition_pushdown=on,derived_merge=on,derived_with_keys=on,firstmatch=on,loosescan=on,materialization=on,in_to_exists=on,semijoin=on,partial_match_rowid_merge=on,partial_match_table_scan=on,subquery_cache=on,mrr=off,mrr_cost_based=off,mrr_sort_keys=off,outer_join_with_cache=on,semijoin_with_cache=on,join_cache_incremental=on,join_cache_hashed=on,join_cache_bka=on,optimize_join_buffer_size=off,table_elimination=on,extended_keys=on,exists_to_in=on Tail of general log: 140912 17:02:44 1 Query INSERT INTO t1 (k,j) VALUES (29,11) |
| Comments |
| Comment by Nirbhay Choubey (Inactive) [ 2014-09-18 ] |
|
kolbe I have tried to come up with a simple test which does INSERT and UPDATE on 2 nodes. But it doesn't lead to crash. Can you try this with perhaps a modified table structure & queries and see it reproduces the issue? |
| Comment by Kolbe Kegel (Inactive) [ 2014-09-18 ] |
|
In what way would you like me to modify the table structure or queries? I was easily able to reproduce this issue when doing my original testing ... so I'm not very inclined to modify my test unless you can give me some guidance about what you'd like me to do and why. Can I help you gather additional information about what is happening here? I did this testing in 3 ec2 instances and repeating the problem has been very easy. I can give you access to the ec2 instances if you'd like. Here's the table structure: CREATE TABLE `t1` ( |
| Comment by Kolbe Kegel (Inactive) [ 2014-09-18 ] |
|
test program. give an integer as 1st positional parameter and it'll be used as the value for wsrep_sync_wait. |
| Comment by Nirbhay Choubey (Inactive) [ 2014-09-18 ] |
|
I was referring to the test script that I uploaded. |
| Comment by Kolbe Kegel (Inactive) [ 2014-09-18 ] |
|
For one thing your table doesn't have a primary key, which is not good for Galera... and you create a new connection for each statement you send to the server, which adds a lot of overhead and slows it down so much that maybe that alone avoids the problem. Plus your test program does all the inserts and then does the updates which is definitely different from what I was doing... sorry for the confusion. You'll see I've attached my test program so you can get a better view of what I was doing. |
| Comment by Nirbhay Choubey (Inactive) [ 2014-09-18 ] |
|
Ok, will try your script. |
| Comment by Nirbhay Choubey (Inactive) [ 2014-09-19 ] |
|
http://lists.askmonty.org/pipermail/commits/2014-September/006606.html |
| Comment by Jan Lindström (Inactive) [ 2014-09-22 ] |
|
Ok to push. |
| Comment by Nirbhay Choubey (Inactive) [ 2014-09-22 ] |
|
Pushed to maria-10.0-galera. |