6 节点 galera 集群冲突证书失败
6 node galera cluster conflict cert failure
我们有一个 6 节点的 galera 集群,下面是 table:
mysql> show create table sessions;
| Table | Create Table
+----------+--------------
| sessions | CREATE TABLE `sessions` (
`id` int(11) NOT NULL AUTO_INCREMENT,
`session_id` varchar(255) NOT NULL,
`data` text,
`created_at` datetime DEFAULT NULL,
`updated_at` datetime DEFAULT NULL,
PRIMARY KEY (`id`),
KEY `index_sessions_on_session_id` (`session_id`),
KEY `index_sessions_on_updated_at` (`updated_at`)
) ENGINE=InnoDB AUTO_INCREMENT=260176483 DEFAULT CHARSET=utf8 |
mysql> desc sessions;
+------------+--------------+------+-----+---------+----------------+
| Field | Type | Null | Key | Default | Extra |
+------------+--------------+------+-----+---------+----------------+
| id | int(11) | NO | PRI | NULL | auto_increment |
| session_id | varchar(255) | NO | MUL | NULL | |
| data | text | YES | | NULL | |
| created_at | datetime | YES | | NULL | |
| updated_at | datetime | YES | MUL | NULL | |
+------------+--------------+------+-----+---------+----------------+
5 rows in set (0.00 sec)
我们在这样的节点上看到很多 wsrep_local_cert_failures
:
SHOW status like '%wsrep%';
| wsrep_local_cert_failures | 165419
galera 调试显示很多冲突:
THD: 251130, mode: local, state: executing, conflict: cert failure, seqno: 92044718
二进制日志记录已禁用。我可以在一般日志文件中使用线程 ID 识别查询:
251130 Query SHOW FIELDS FROM sessions
251130 Query SELECT sessions.* FROM sessions WHERE sessions.session_id =
'3d1d7f8638dbfd12ee58fa78d4f0998c' LIMIT 1
251130 Query BEGIN
251130 Query INSERT INTO sessions (session_id, data, created_at,
updated_at) VALUES ('3d1d7f8638dbfd12ee58fa78d4f0998c',
'BAh7BkkiDnJldHVybl90bwY6BkVGIgYv\n', '2016-01-04 10:48:52', '2016-01-04
10:48:52')
251130 Query COMMIT
应用程序生成会话 ID。有什么想法吗?
会话 ID 有什么问题以及如何解决冲突。
谢谢
A good description of "local cert failure"
session_id 是从哪里来的?它非常长,看起来是十六进制,所以不应该是 utf8,也可能不是 varchar(255)。 UNHEX()
并放入 BINARY(16)
以显着缩小数据大小。
SELECT
是否正在尝试查看记录是否已经存在?在你有机会做之前,另一个节点可以是 INSERTing
那 session_id
吗?有多种解决方法,每种都有问题。另一个节点会将其他列设置为相同的值吗?
交换主机是原因。设置正确 innodb_buffer_pool_size 并重新启动后我们没有错误。
感谢您的帮助。
我们有一个 6 节点的 galera 集群,下面是 table:
mysql> show create table sessions;
| Table | Create Table
+----------+--------------
| sessions | CREATE TABLE `sessions` (
`id` int(11) NOT NULL AUTO_INCREMENT,
`session_id` varchar(255) NOT NULL,
`data` text,
`created_at` datetime DEFAULT NULL,
`updated_at` datetime DEFAULT NULL,
PRIMARY KEY (`id`),
KEY `index_sessions_on_session_id` (`session_id`),
KEY `index_sessions_on_updated_at` (`updated_at`)
) ENGINE=InnoDB AUTO_INCREMENT=260176483 DEFAULT CHARSET=utf8 |
mysql> desc sessions;
+------------+--------------+------+-----+---------+----------------+
| Field | Type | Null | Key | Default | Extra |
+------------+--------------+------+-----+---------+----------------+
| id | int(11) | NO | PRI | NULL | auto_increment |
| session_id | varchar(255) | NO | MUL | NULL | |
| data | text | YES | | NULL | |
| created_at | datetime | YES | | NULL | |
| updated_at | datetime | YES | MUL | NULL | |
+------------+--------------+------+-----+---------+----------------+
5 rows in set (0.00 sec)
我们在这样的节点上看到很多 wsrep_local_cert_failures
:
SHOW status like '%wsrep%';
| wsrep_local_cert_failures | 165419
galera 调试显示很多冲突:
THD: 251130, mode: local, state: executing, conflict: cert failure, seqno: 92044718
二进制日志记录已禁用。我可以在一般日志文件中使用线程 ID 识别查询:
251130 Query SHOW FIELDS FROM sessions
251130 Query SELECT sessions.* FROM sessions WHERE sessions.session_id =
'3d1d7f8638dbfd12ee58fa78d4f0998c' LIMIT 1
251130 Query BEGIN
251130 Query INSERT INTO sessions (session_id, data, created_at,
updated_at) VALUES ('3d1d7f8638dbfd12ee58fa78d4f0998c',
'BAh7BkkiDnJldHVybl90bwY6BkVGIgYv\n', '2016-01-04 10:48:52', '2016-01-04
10:48:52')
251130 Query COMMIT
应用程序生成会话 ID。有什么想法吗?
会话 ID 有什么问题以及如何解决冲突。
谢谢
A good description of "local cert failure"
session_id 是从哪里来的?它非常长,看起来是十六进制,所以不应该是 utf8,也可能不是 varchar(255)。 UNHEX()
并放入 BINARY(16)
以显着缩小数据大小。
SELECT
是否正在尝试查看记录是否已经存在?在你有机会做之前,另一个节点可以是 INSERTing
那 session_id
吗?有多种解决方法,每种都有问题。另一个节点会将其他列设置为相同的值吗?
交换主机是原因。设置正确 innodb_buffer_pool_size 并重新启动后我们没有错误。
感谢您的帮助。