Details
-
Type:
Bug
-
Status: Closed
-
Priority:
Critical
-
Resolution: Fixed
-
Affects Version/s: None
-
Fix Version/s: 5.5.32-galera
-
Component/s: None
-
Labels:
Description
I run a 2-node cluster with the following server command lines:
maria-5.5-galera//sql/mysqld --no-defaults --basedir=maria-5.5-galera/ --datadir=node0/data --lc-messages-dir=maria-5.5-galera//sql/share --character-sets-dir=maria-5.5-galera//sql/share/charsets --tmpdir=node0/tmp --core-file --max-allowed-packet=128Mb --port=19300 --socket=node0/mysql.sock --pid-file=node0/mysql.pid --general-log --general-log-file=node0/mysql.log --wsrep_sst_method=rsync --innodb_autoinc_lock_mode=2 --default-storage-engine=InnoDB --innodb_locks_unsafe_for_binlog=1 --binlog-format=row --wsrep_cluster_address=gcomm://?gmcast.listen_addr=tcp://127.0.0.1:4800 --wsrep-provider=/home/elenst/galera/libgalera_smm.so --log-bin --log-slave-updates
maria-5.5-galera//sql/mysqld --no-defaults --basedir=maria-5.5-galera/ --datadir=node1/data --lc-messages-dir=maria-5.5-galera//sql/share --character-sets-dir=maria-5.5-galera//sql/share/charsets --tmpdir=node1/tmp --core-file --max-allowed-packet=128Mb --port=19301 --socket=node1/mysql.sock --pid-file=node1/mysql.pid --general-log --general-log-file=node1/mysql.log --wsrep_sst_method=rsync --innodb_autoinc_lock_mode=2 --default-storage-engine=InnoDB --innodb_locks_unsafe_for_binlog=1 --binlog-format=row --wsrep_cluster_address=gcomm://127.0.0.1:4800?gmcast.listen_addr=tcp://127.0.0.1:4801 --wsrep-provider=/home/elenst/galera/libgalera_smm.so --log-bin --log-slave-updates
The status shows that the cluster is up and running:
| wsrep_local_state | 4 | | wsrep_local_state_comment | Synced | | wsrep_cert_index_size | 11 | | wsrep_causal_reads | 0 | | wsrep_incoming_addresses | 192.168.1.20:19300,192.168.1.20:19301 | | wsrep_cluster_conf_id | 2 | | wsrep_cluster_size | 2 |
Then I execute the following on the first node:
MariaDB [test]> create table t4 (pk int primary key, i int) engine=InnoDB partition by hash(pk) partitions 2; Query OK, 0 rows affected (0.41 sec) MariaDB [test]> insert into t4 values (1,100), (2,200); Query OK, 2 rows affected (0.11 sec) Records: 2 Duplicates: 0 Warnings: 0 MariaDB [test]> delete from t4; Query OK, 2 rows affected (0.04 sec) MariaDB [test]> select * from t4; Empty set (0.00 sec)
But on the 2nd node DELETE did not work:
MariaDB [test]> select * from t4; +----+------+ | pk | i | +----+------+ | 2 | 200 | | 1 | 100 | +----+------+ 2 rows in set (0.01 sec)
The status still shows that replication is up:
| wsrep_local_state | 4 | | wsrep_local_state_comment | Synced | | wsrep_cert_index_size | 14 | | wsrep_causal_reads | 0 | | wsrep_incoming_addresses | 192.168.1.20:19300,192.168.1.20:19301 | | wsrep_cluster_conf_id | 2 | | wsrep_cluster_size | 2 |
But further INSERTs don't work either.
revision-id: seppo.jaakola@codership.com-20130823092100-tumt1qvo3hbybhg3 revno: 3415 branch-nick: maria-5.5-galera
Server version: 5.5.32-MariaDB-debug-log Source distribution, wsrep_23.7.5.r3415 Galera library 23.2.6
Gliffy Diagrams
Attachments
Activity
- All
- Comments
- Work Log
- History
- Activity
- Transitions
seems to relate to handler::mark_trx_done, which remains always true for innodb engine
The mark_trx_done variable will be sticky TRUE for table handlers under partition engine. This prevents e.g. innodb transactions to be declared as read/write. And wsrep replication provider will trigger replication only if there has been innodb transactions with writes.
Fix has been pushed in revision #3417: http://bazaar.launchpad.net/~maria-captains/maria/maria-5.5-galera/revision/3417
The fix propagates handler::ha_start_of_new_statement() call for all table handlers controlled by partition engine.
Run some manual partition engine test loads. and turns out that partition engine replication is broken only in MGC, the MySQL version is not affected.