Details
-
Type:
Bug
-
Status: Closed
-
Priority:
Minor
-
Resolution: Fixed
-
Affects Version/s: None
-
Fix Version/s: 5.5.34-galera
-
Component/s: None
-
Labels:None
Description
120808 22:26:23 [Note] WSREP: Running: 'wsrep_sst_rsync 'donor' '192.168.1.5:4444/rsync_sst' 'galera:galera' '/home/elenst/galera-5.5/data1/' '' '871ddeac-e186-11e1-0800-3ba72ed0465d' '0' '0'' 120808 22:26:23 [Note] WSREP: sst_donor_thread signaled with 0 120808 22:26:23 [Note] WSREP: Flushing tables for SST... 120808 22:26:23 [ERROR] mysqld got signal 11 ;
#3 <signal handler called>
#4 0x000000000060544f in lex_one_token (arg=0x7fd2db252b70, yythd=0x29f9640) at sql/sql_lex.cc:1036
#5 0x000000000060526a in MYSQLlex (arg=0x7fd2db252b70, yythd=0x29f9640) at sql/sql_lex.cc:975
#6 0x0000000000777a33 in MYSQLparse (yythd=0x29f9640) at sql/sql_yacc.cc:18129
#7 0x0000000000626632 in parse_sql (thd=0x29f9640, parser_state=0x7fd2db254740, creation_ctx=0x0)
at sql/sql_parse.cc:8642
#8 0x000000000062029d in mysql_parse (thd=0x29f9640, rawbuf=0xd7e683 "FLUSH TABLES WITH READ LOCK", length=27,
parser_state=0x7fd2db254740) at sql/sql_parse.cc:6163
#9 0x0000000000771cf5 in run_sql_command (thd=0x29f9640, query=0xd7e683 "FLUSH TABLES WITH READ LOCK")
at sql/wsrep_sst.cc:685
#10 0x0000000000771ea3 in sst_flush_tables (thd=0x29f9640) at sql/wsrep_sst.cc:705
#11 0x000000000077269d in sst_donor_thread (a=0x7fd30171a190) at sql/wsrep_sst.cc:808
#12 0x00007fd30dce5efc in start_thread (arg=0x7fd2db255700) at pthread_create.c:304
#13 0x00007fd30d49559d in clone () at ../sysdeps/unix/sysv/linux/x86_64/clone.S:112
Trying to get some variables. Some pointers may be invalid and cause the dump to abort. Query (0xd7e683): FLUSH TABLES WITH READ LOCK Connection ID (thread ID): 0 Status: NOT_KILLED
Server command lines:
/home/elenst/galera-5.5/sql/mysqld --no-defaults --datadir=/home/elenst/galera-5.5/data1 --wsrep_provider=/home/elenst/galera-23.2.1-src/libgalera_smm.so --wsrep_sst_method=mysqldump --core --binlog-format=row --log-bin=master-bin --default-storage-engine=InnoDB --innodb_autoinc_lock_mode=2 --innodb_locks_unsafe_for_binlog=1 --innodb_flush_log_at_trx_commit=0 --innodb_doublewrite=0 --log-error=log.err --wsrep_sst_auth=galera:galera --basedir=/home/elenst/galera-5.5/ --port=8306 --loose-lc-messages-dir=/home/elenst/galera-5.5/sql/share --loose-language=/home/elenst/galera-5.5/sql/share/english --socket=/tmp/elenst-galera-1.sock --wsrep_cluster_address=gcomm:// --character-set-server=utf16 --tmpdir=/home/elenst/galera-5.5/data1/tmp --wsrep_slave_threads=4 --general-log=1 /home/elenst/galera-5.5/sql/mysqld --no-defaults --datadir=/home/elenst/galera-5.5/data2 --wsrep_provider=/home/elenst/galera-23.2.1-src/libgalera_smm.so --wsrep_sst_method=mysqldump --core --binlog-format=row --log-bin=master-bin --default-storage-engine=InnoDB --innodb_autoinc_lock_mode=2 --innodb_locks_unsafe_for_binlog=1 --innodb_flush_log_at_trx_commit=0 --innodb_doublewrite=0 --log-error=log.err --wsrep_sst_auth=galera:galera --basedir=/home/elenst/galera-5.5/ --port=8307 --loose-lc-messages-dir=/home/elenst/galera-5.5/sql/share --loose-language=/home/elenst/galera-5.5/sql/share/english --socket=/tmp/elenst-galera-2.sock --wsrep_cluster_address=gcomm://127.0.0.1:4567?gmcast.listen_addr=tcp://127.0.0.1:4566 --character-set-server=utf16 --tmpdir=/home/elenst/galera-5.5/data2/tmp --wsrep_slave_threads=4 --general-log=1
Executing FLUSH TABLES WITH READ LOCK on an already running server (e.g. if it was started with wsrep_sst_method=mysqldump) does not cause the crash.
bzr version-info (maria-5.5-galera)
revision-id: jani@work-20120723081559-lcsbsui4dl9vsfbu date: 2012-07-23 11:15:59 +0300 build-date: 2012-08-08 18:36:09 +0400 revno: 3342
Build options: -DCMAKE_BUILD_TYPE=Debug -DWITH_WSREP=ON -DWITH_INNODB_DISALLOW_WRITES=1
galera-23.2.1
How to reproduce:
- start a new node with --wsrep_sst_method=rsync and --character_set_server=utf16; - wait till it started; - start another node with the same parameters, pointing at the first one; - check the status of the first node (it crashes)
Gliffy Diagrams
Attachments
Activity
- All
- Comments
- Work Log
- History
- Activity
- Transitions
Switched to Minor temporarily, as I think it can be tolerated for the first alpha release.
wsrep_sst.cc directly sends a SQL to the parser. Maybe the best way is to temporally set such a character set that is supported by the parser if current character set is part of the unsupported ones.
In SST Galera directly calls parser using current client character
set. Similarly in BF Galera uses client character set to apply. However,
there are character sets that are not currently supported by the parser.
Fix: If currenct client character set is one of those that is not supported
by the parser, temporally set character set to latin1 before we enter
parser and restore it after we have parsed.
See http://dev.mysql.com/doc/refman/5.5/en/server-system-variables.html#sysvar_character_set_client about ucs2, utf16, and utf32 not allowed to "be used as a client character set, which means that they also do not work for SET NAMES or SET CHARACTER SET." – it might be somehow related.