Bug #1379

更新処理時のbinlog誤データの記入

Added by Kentoku SHIBA about 6 years ago. Updated about 6 years ago.

Status:完了チェック待ちStart date:05/26/2012
Priority:NormalDue date:
Assignee:Kentoku SHIBA% Done:

50%

Category:-
Target version:-

Description

今回、全文検索エンジンとしてmroongaを採用させて頂きましたが、
掲題の件でスレーブのレプリケーションが正しく行われない事態に遭遇しております。

レプリケーションの障害について下記の報告を拝見しておりますが、
クラッシュではなくbinlogの誤りとそれに伴う誤更新、停止という点で、
差異を感じておりますため、報告させていただいております。
http://redmine.groonga.org/issues/1361

■把握している症状
・general_logのSQLは発行したSQLの通りである。
・bin_logの値は格納されている値と異なる値を参照して発行されている
・relay_logでは与えられたbin_logの誤った値をそのまま参照している
・マスター側では正しく処理されており、スレーブ側ではbin_logに記された通りの誤った値が反映される
・mroongaのエンジンを採用している全3テーブルの全更新処理にて再現を確認しております

■対策の方針
当座はマスター側をinnodbエンジンとし、
スレーブ側のみmroongaとすることで対応を検討しております。

詳細を下記に列挙いたします。

■ サンプルSQL
UPDATE trn_post SET comment_count = comment_count + 1 ,update_timestamp
= '2012-05-24 18:21:48' WHERE id = '13'

■ テーブル定義
=======================================================
CREATE TABLE trn_post
(
id int unsigned NOT NULL AUTO_INCREMENT,
fk_user_id int unsigned NOT NULL,
body text,
has_image tinyint unsigned,
has_link tinyint unsigned NOT NULL,
black_flag tinyint unsigned DEFAULT 0 NOT NULL,
draft_flag tinyint unsigned DEFAULT 0 NOT NULL,
comment_count int unsigned DEFAULT 0 NOT NULL,
push_count int unsigned DEFAULT 0 NOT NULL,
status_code tinyint unsigned DEFAULT 0 NOT NULL,
create_datetime datetime NOT NULL,
update_timestamp timestamp DEFAULT CURRENT_TIMESTAMP NOT NULL ON UPDATE
CURRENT_TIMESTAMP,
PRIMARY KEY (id)
) ENGINE = mroonga DEFAULT CHARACTER SET utf8;
/* Create FulltextIndexes */
SET GLOBAL mroonga_default_parser = TokenMecab;
CREATE FULLTEXT INDEX ix_full_trn_post_01 ON trn_post(body);
=======================================================

■my.cnf
=======================================================
[mysqld]
datadir=/var/lib/mysql
socket=/var/lib/mysql/mysql.sock
user=mysql
# Disabling symbolic-links is recommended to prevent assorted security risks
symbolic-links=0
innodb-flush-log-at-trx-commit=2
innodb_buffer_pool_size=256M
innodb_log_buffer_size=16M
innodb_log_file_size=64M
sort_buffer_size=2M
read_rnd_buffer_size=1M
join_buffer_size=256K
innodb_additional_mem_pool_size=20M
innodb_thread_concurrency=16
innodb_commit_concurrency=8
innodb_flush_method=O_DIRECT
innodb_file_per_table
innodb_data_file_path=ibdata1:1G
character-set-server=utf8
collation-server=utf8_general_ci
skip-character-set-client-handshake
expire_logs_days=1

max_connection=1024
thread_concurrency=300
log_bin=mysql-bin
#binlog_format=STATEMENT
#binlog_format=MIXED
binlog_format=ROW
server_id=1
slow_query_log=ON
slow_query_log_file=mysql-slow.log
max_binlog_size=512M
log_output=FILE
long_query_time=0.5
default-storage-engine=innodb
lower_case_table_names=1
thread_cache_size = 300

port=33306
server-id=1
log-bin=/var/lib/mysql/blog/blog

[mysqld_safe]
log-error=/var/log/mysqld.log
pid-file=/var/run/mysql/mysqld.pid
syslog
port=33306
socket=/var/lib/mysql/mysql.sock

[client]
port=33306
socket=/var/lib/mysql/mysql.sock
=======================================================

現象のお心当たりに関しまして、
アドバイスいただけますと幸いです。

History

#1 Updated by Kentoku SHIBA about 6 years ago

  • Status changed from 新規 to 完了チェック待ち
  • % Done changed from 0 to 50

本問題は、5.6では発生せず、5.5以前のバージョンで、行ベースレプリケーションを 利用している場合に発生します。

mroongaは、更新処理の際にカラムストアである利点を生かすために、 更新に必要がないカラムは見ないようにしていたのですが、 MySQL 5.5までの行ベースレプリケーションが更新に必要な カラム以外に限定せず全てのカラムをレプリケーションする 仕様となっているため、更新に利用しないカラムについて 予期しない値がレプリケーションされている状況となっておりました。

MySQL 5.6からはこの点が改善され、更新に必要なカラムのみ レプリケーションされるようになったため、修正前の状態でも この問題は発生しません。

このため、MySQL 5.5以前でmroongaが利用される場合で、 行ベースレプリケーションが利用されている場合について、 更新に必要がないカラムもレプリケーション用に補てんする ように修正しました。

Also available in: Atom PDF