crash with HA_ERR_FOUND_DUPP_KEY when PRIMARY KEY contains UTF8
Affects | Status | Importance | Assigned to | Milestone | ||
---|---|---|---|---|---|---|
MySQL patches by Codership | Status tracked in 5.6 | |||||
5.5 |
Fix Released
|
Medium
|
Seppo Jaakola | |||
5.6 |
Fix Committed
|
Medium
|
Seppo Jaakola | |||
Percona XtraDB Cluster moved to https://jira.percona.com/projects/PXC | Status tracked in 5.6 | |||||
5.5 |
Fix Released
|
Undecided
|
Unassigned | |||
5.6 |
Fix Released
|
Undecided
|
Unassigned |
Bug Description
OS: Debian 6.0
Software: Percona XtraDB Cluster 5.5.30-30.2
Cluster: Two mysqld (db-test-1 & db-test-2) & one garbd (db-test-3)
my.cnf in db-test-1: https:/
Sometimes we've got HA_ERR_
130513 11:15:25 [ERROR] Slave SQL: Could not execute Write_rows event on table t.tag_raw; Duplicate entry '0-61-53-中文測試' for key 'PRIMARY', Error_code: 1062; handler
error HA_ERR_
130513 11:15:25 [Warning] WSREP: RBR event 2 Write_rows apply warning: 121, 137399
130513 11:15:25 [ERROR] WSREP: Failed to apply trx: source: 6aaa649a-
09 seqnos (l: 80461, g: 137399, s: 137398, d: 137066, ts: 136841492547658
130513 11:15:25 [ERROR] WSREP: Failed to apply app buffer: seqno: 137399, status: WSREP_FATAL
at galera/
at galera/
130513 11:15:25 [ERROR] WSREP: Node consistency compromized, aborting...
130513 11:15:25 [Note] WSREP: Closing send monitor...
130513 11:15:25 [Note] WSREP: Closed send monitor.
130513 11:15:25 [Note] WSREP: gcomm: terminating thread
130513 11:15:25 [Note] WSREP: gcomm: joining thread
130513 11:15:25 [Note] WSREP: gcomm: closing backend
130513 11:15:25 [Note] WSREP: view(view_
} joined {
} left {
} partitioned {
})
130513 11:15:25 [Note] WSREP: New COMPONENT: primary = no, bootstrap = no, my_idx = 0, memb_num = 1
130513 11:15:25 [Note] WSREP: view((empty))
130513 11:15:25 [Note] WSREP: gcomm: closed
130513 11:15:25 [Note] WSREP: Flow-control interval: [16, 16]
130513 11:15:25 [Note] WSREP: Received NON-PRIMARY.
130513 11:15:25 [Note] WSREP: Shifting SYNCED -> OPEN (TO: 137399)
130513 11:15:25 [Note] WSREP: Received self-leave message.
130513 11:15:25 [Note] WSREP: Flow-control interval: [0, 0]
130513 11:15:25 [Note] WSREP: Received SELF-LEAVE. Closing connection.
130513 11:15:25 [Note] WSREP: Shifting OPEN -> CLOSED (TO: 137399)
130513 11:15:25 [Note] WSREP: RECV thread exiting 0: Success
130513 11:15:25 [Note] WSREP: recv_thread() joined.
130513 11:15:25 [Note] WSREP: Closing slave action queue.
130513 11:15:25 [Note] WSREP: /usr/sbin/mysqld: Terminated.
Aborted
130513 11:15:25 mysqld_safe Number of processes running now: 0
130513 11:15:25 mysqld_safe WSREP: not restarting wsrep node automatically
130513 11:15:25 mysqld_safe mysqld from pid file /var/lib/
Database schema & two scripts to reproduce (running these two scripts at the same time):
> SHOW CREATE TABLE tag_raw \G
*******
Table: tag_raw
Create Table: CREATE TABLE `tag_raw` (
`obj_type` varchar(16) NOT NULL DEFAULT '' COMMENT 'obj_type',
`obj_id` varchar(20) NOT NULL COMMENT 'obj_type編號',
`tag` varchar(255) NOT NULL,
`msno` bigint(20) NOT NULL DEFAULT '0' COMMENT 'user id',
`terr_id` int(11) NOT NULL COMMENT '地區編號',
PRIMARY KEY (`obj_type`
KEY `obj_id` (`obj_id`),
KEY `tag` (`tag`),
KEY `msno` (`msno`)
) ENGINE=InnoDB DEFAULT CHARSET=utf8 ROW_FORMAT=
1 row in set (0.00 sec)
gslin@goingmarry [~/work/galera] [11:22] cat ti.php
<?php
$db = new PDO('mysql:
$pi = $db->prepare(
for ($i = 0;; $i++) {
$obj_type = 0;
$obj_id = rand(1, 100);
$tag = '中文測試'; // UTF-8
$msno = rand(1, 100);
$terr_id = 0;
$pi-
if (0 == $i % 1000) {
}
}
gslin@goingmarry [~/work/galera] [11:22] cat td.php
<?php
$db = new PDO('mysql:
$ps = $db->prepare(
for ($i = 0;; $i++) {
$ps->execute();
list($c) = $ps->fetch(
if ($c > 100) {
$sql = sprintf('DELETE FROM `tag_raw` ORDER BY `obj_type`, `obj_id`, `tag`, `msno` LIMIT %d;', $c / 2);
printf("%d: %s\n", $i, $sql);
}
sleep(1);
}
Changed in codership-mysql: | |
status: | Confirmed → In Progress |
Changed in percona-xtradb-cluster: | |
status: | New → Fix Released |
Looks like a combination of parallel applying AND COMPRESSED table. Most probably not all keys collected correctly. So in multi-master case this should lead to inconsistency.