2016-11-15 6 views
0

私は、Red Hat Linux上でMySQL Ver 14.14、Distrib 5.1.16をホストしている2つの異なるサーバでマスターからマスターへの複製セットアップを行っています。サーバーの1つを再起動すると、スレーブは起動しません。/var/lib/mysqlディレクトリのリストを実行すると、master.infoファイルがゼロ長に切り捨てられ、レプリケーションがセットアップされていないとMySQLが判断することがわかりました。master.infoファイルが途切れていた

ここ

サーバー1用のmy.cnfです:

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

[mysqldump] 
quick 
max_allowed_packet = 16M 

[mysql] 
no-auto-rehash 

[isamchk] 
key_buffer = 20M 
sort_buffer_size = 20M 
read_buffer = 2M 
write_buffer = 2M 

[myisamchk] 
key_buffer = 20M 
sort_buffer_size = 20M 
read_buffer = 2M 
write_buffer = 2M 

[mysqlhotcopy] 
interactive-timeout 

[mysqld] 
port = 3306 
socket = /var/lib/mysql/mysql.sock 
key_buffer = 16M 
max_allowed_packet = 1M 
table_cache = 64 
sort_buffer_size = 512K 
net_buffer_length = 8K 
myisam_sort_buffer_size = 8M 
log-bin = mysql-bin 
relay-log = mysqld-relay-bin 
relay-log-index = mysqld-relay-bin.index 
server-id = 101 
binlog-format = STATEMENT 
replicate-do-db = foo 
replicate-do-db = bar 
binlog-do-db = foo 
binlog-do-db = bar 
auto_increment_increment = 2 
auto_increment_offset = 1 
master-connect-retry = 2 
sync_binlog = 1 
log-error = mysqld.log 
log-warnings = 2 
wait_timeout = 31536000 
expire_logs_days = 45 

そして、ここでは、サーバ2のためのmy.cnfです:

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

[mysqldump] 
quick 
max_allowed_packet = 16M 

[mysql] 
no-auto-rehash 

[isamchk] 
key_buffer = 20M 
sort_buffer_size = 20M 
read_buffer = 2M 
write_buffer = 2M 

[myisamchk] 
key_buffer = 20M 
sort_buffer_size = 20M 
read_buffer = 2M 
write_buffer = 2M 

[mysqlhotcopy] 
interactive-timeout 

[mysqld] 
port = 3306 
socket = /var/lib/mysql/mysql.sock 
key_buffer = 16M 
max_allowed_packet = 1M 
table_cache = 64 
sort_buffer_size = 512K 
net_buffer_length = 8K 
myisam_sort_buffer_size = 8M 
log-bin = mysql-bin 
relay-log = mysqld-relay-bin 
relay-log-index = mysqld-relay-bin.index 
server-id = 102 
binlog-format = STATEMENT 
replicate-do-db = foo 
replicate-do-db = bar 
binlog-do-db = foo 
binlog-do-db = bar 
auto_increment_increment = 2 
auto_increment_offset = 2 
master-connect-retry = 2 
sync_binlog = 1 
log-error = mysqld.log 
log-warnings = 2 
wait_timeout = 31536000 
expire_logs_days = 45 

Iセットアップそうのような各サーバー上のスレーブ:

STOP SLAVE ; RESET SLAVE ; CHANGE MASTER TO MASTER_HOST='other_sys', MASTER_USER='repl', MASTER_PASSWORD='super_secret_password', MASTER_PORT=3306, MASTER_LOG_FILE='mysql-bin.000001', MASTER_LOG_POS=14048 ; 

MASTER_LOG_FILEとMASTER_LOG_POSは、上記の例では任意です。これを実行した後、私は、MySQLのスレーブの状態については、次を得る:

mysql> show slave status \G 
*************************** 1. row *************************** 
       Slave_IO_State: Waiting for master to send event 
        Master_Host: other_sys 
        Master_User: repl 
        Master_Port: 3306 
       Connect_Retry: 2 
       Master_Log_File: mysql-bin.000002 
      Read_Master_Log_Pos: 14048 
       Relay_Log_File: mysqld-relay-bin.000002 
       Relay_Log_Pos: 251 
     Relay_Master_Log_File: mysql-bin.000002 
      Slave_IO_Running: Yes 
      Slave_SQL_Running: Yes 
       Replicate_Do_DB: foo,bar 
      Replicate_Ignore_DB: 
      Replicate_Do_Table: 
     Replicate_Ignore_Table: 
     Replicate_Wild_Do_Table: 
    Replicate_Wild_Ignore_Table: 
        Last_Errno: 0 
        Last_Error: 
       Skip_Counter: 0 
      Exec_Master_Log_Pos: 14048 
       Relay_Log_Space: 407 
       Until_Condition: None 
       Until_Log_File: 
       Until_Log_Pos: 0 
      Master_SSL_Allowed: No 
      Master_SSL_CA_File: 
      Master_SSL_CA_Path: 
       Master_SSL_Cert: 
      Master_SSL_Cipher: 
       Master_SSL_Key: 
     Seconds_Behind_Master: 0 
Master_SSL_Verify_Server_Cert: No 
       Last_IO_Errno: 0 
       Last_IO_Error: 
       Last_SQL_Errno: 0 
       Last_SQL_Error: 
1 row in set (0.00 sec) 

私は、コマンドrebootを使用して、サーバーの再起動を行います。再起動すると、MySQLスレーブが中断した場所から自動的に起動することがあります。それ以外の場合は、MySQLスレーブがまったく起動せず、show slave status \Gが空集合を返し、/var/lib/mysql/master.infoファイルが長さゼロに切り捨てられていることがわかります。再起動時にLinuxがファイルバッファをinodeにフラッシュしていないので、スレーブ情報が保存されないようです。

スレーブの設定に関して何か不足していますか?

問題は、Linuxのファイルのバッファリングした:

答えて

0

念のために誰もが、私はこれを、固定方法を知りたいです。私はrebootと呼ばれる前にsyncと呼ぶ以外は上記と同じ手順を実行し、10回の試行で100%の時間をかけました。 syncがなければ、テストで10回中9回失敗しました。なぜLinuxがシャットダウン時にファイルキャッシュを同期していないのか分かりませんが、syncを呼び出すか、rebootを発行する前に1分間待って問題を修正しました。

+0

これは奇妙です。 Unix上の 'shutdown'スクリプトは35年前に3つまたは4つの' sync'スクリプトを実行していました。 – EJP

+0

これは実際に私たちの生産システムにとってより大きな問題であることが判明しました。これは、Linuxシステム上のすべてのファイルを使って行います。このサイトに問題を掲載しましたが、unix.stackexchange.comサイトに移動しています。もしかしたら私たちの店がこれを壊してしまった構成があるかどうかわかるかもしれません。 –

関連する問題