MySQL Master-Slave Replication Setupを作成してトラブルシューティングする最良の方法は何ですか?


14

私はデータベース管理を始めたばかりです。

mysqlマスター/スレーブレプリケーションのセットアップ中に多くの問題に直面します。

また、通常のmysqlレプリケーションのトラブルシューティングの問題に直面しています。

誰もがこれらすべてに対処する方法を理解するのに役立ちますか?


いくつかの質問:なぜレプリケーションを行う必要があるのですか、何を達成しようとしていますか?レプリケーションに参加している各コンピューターのOSは何ですか?各コンピューターのMySQLのバージョンは何ですか?テーブルはMyISAM、InnoDBなどですか?
クレイグエフライン

@CraigEfreinこれらのサーバーは本番環境で使用されるため、レプリケーションを設定する必要があります。各マシンでDebian / ubuntuを使用しています。vaersion.Primarilyテーブルとしてのmysql5.1はInnoDBです。
アブドゥルマナフ

OK、2つのdebianの間で使用した構成を少し投稿します。もちろん、すべてのコンピューターにMySQLがインストールされており、すべて同じコンピューターを使用しており、十分なディスク容量があることを前提としています。MySQLレプリケーションを使用する場合、binログをどこに配置するかを考える必要があります。これは、いくつかの要因に応じて非常に大きくなる可能性があります。私の投稿にその情報を含めます
クレイグエフレイン

回答:


19

チュートリアルへのリンクを提供しました。Ubuntuでは、my.cnfファイルはhowtoforgeチュートリアルのように/etc/my.cnfではなく/etc/mysql/my.cnfにあることに注意してください。私のセットアップでは、読み取りロック付きのフラッシュテーブルを使用しませんでした。マスターに。マスターサーバーに大量の書き込みアクティビティがある場合、バックアップする前にそのコマンドを実行してテーブルをロックする必要がある場合があります。FLUSH TABLES WITH READ LOCK;を使用している場合、バックアップ後にUNLOCK TABLESを実行する必要があります。問題が発生した場合は、お知らせください。

Redhat / CentOS用に作成されたhowto forgeで見つけたチュートリアルは、次のとおりです。http ://www.howtoforge.com/mysql_database_replication

Ubuntu http://www.srcnix.com/2010/10/14/simple-mysql-replication-with-ubuntu-master-to-slave/で大丈夫に見えた別のチュートリアル

私が使用した構成は次のとおりです。

MASTERサーバー上

マスターサーバーを構成します。

vi /etc/mysql/my.cnf

[mysqld]

# bind-address = 127.0.0.1 (comment this out)
server_id           = 1
log_bin             = /var/log/mysql/mysql-bin.log
log_bin_index       = /var/log/mysql/mysql-bin.log.index
max_binlog_size     = 100M
expire_logs_days    = 1

MySQLを再起動します。

/etc/init.d/mysql restart

mysqlのコンソールに接続します:mysql -u root -ppassword

複製ユーザーに権限を作成して付与します。

GRANT REPLICATION SLAVE ON *.* TO 'replication'@'ipaddressofslave' IDENTIFIED BY 'replicationuserpassword';

この情報をどこかにコピーするか、表示したままにしてください

SHOW MASTER STATUS \G;
mysql> show master status \G;
            File: mysql-bin.000001
        Position: 100
    Binlog_Do_DB: 
Binlog_Ignore_DB:

mysql> quit 

データベースをファイルにダンプします。

mysqldump -u root -p databasename > /tmp/databasename-backup.sql

scpを使用してデータベースダンプをスレーブサーバーにコピーするか、必要に応じてftpを使用します。

scp /tmp/databasename-backup.sql root@ipaddressofslave:/tmp/

SLAVEサーバー上

mysql構成を編集します。

vi /etc/mysql/my.cnf
[mysqld]

# slave server configuration
server_id           = 2

# this is optional, but I find it useful to specify where the relay logs go to control.  
# Don't forget to create the /var/log/mysql directory and give mysql rights to it.  
# chown mysql:mysql -R /var/log/mysql
# disk space
relay_log           = /var/log/mysql/mysql-relay-bin
relay_log_index     = /var/log/mysql/mysql-relay-bin.index
relay_log_space_limit = 2000M

MySQLを再起動します。 /etc/init.d/mysql restart

バックアップを復元します。

mysql -u root -ppassword nameofthedatabase < /tmp/databasename-backup.sql

MySQLに接続します。

mysql -u root -ppassword

stop slave;

# master log file and master_log_pos taken from show master status above
CHANGE MASTER TO master_host='ipaddressmaster', master_port=3306, master_user='replication', master_password='replicationuserpassword', master_log_file='mysql-bin.000001', master_log_pos=100;

start slave;

実行SHOW SLAVE STATUS\G

mysql> show slave status\G;
             Slave_IO_State: Waiting for master to send event
                Master_Host: ipaddressmaster
                Master_User: replication
                Master_Port: 3306
              Connect_Retry: 60
            Master_Log_File: mysql-bin.0000001
        Read_Master_Log_Pos: 100
             Relay_Log_File: mysql-relay-bin.000001
              Relay_Log_Pos: 1
      Relay_Master_Log_File: mysql-bin.000001
           Slave_IO_Running: Yes
          Slave_SQL_Running: Yes
            Replicate_Do_DB: 
        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: 17324288
            Relay_Log_Space: 17324425
            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
1 row in set (0.02 sec)

その後、さまざまな理由でレプリケーションが失敗する可能性があることに注意してください。スレーブでは、コマンドSHOW SLAVE STATUS \ Gを実行してステータスを監視できます。または、cronジョブを設定してステータスを監視し、失敗した場合に電子メールを送信します。このコマンドの出力をよく理解してください。レプリケーションが正常に実行されている場合は、「Slave_IO_State:マスターがイベントを送信するのを待機しています」と表示されます。

この設定を正しく取得したら、その複製を監視するスクリプトを提供できます。

MySQLのエラーログを監視するスクリプトを次に示します。行を追加する場合

[mysqld]

ログエラー= /var/log/mysql/mysql.err

mysqlの再起動:/etc/init.d/mysql restart

その後、次のスクリプトを使用してログファイルを監視できます。ログが何らかの方法で変更された場合、スレーブサーバーでエラーが発生したことを通知するメールを受け取ります。エラーログを定期的にチェックする場合は、このスクリプトをcrontabに追加する必要があります。

サンプルスクリプトは次のとおりです。/somepath/monitor_mysql_log.sh

#! /bin/sh
MAIL_TO="addressemail@something.com"

# This is the log that will be monitored.
# If any changes occur to this, then take appropriate action.
MONITORED_LOG=/var/log/mysql/mysql.err

# We will need this log to see whether any changes occured to /tmp/goreb.log
TEMP_LOG=/tmp/.mysql.err.1

# This is a 1-time command i.e. create the log file if it does nto exist.
[ ! -f $TEMP_LOG ] && touch -r $MONITORED_LOG $TEMP_LOG

[ $MONITORED_LOG -nt $TEMP_LOG ] && echo "an error occurred in mysql" | mail -s "Error on MySQL" $MAILTO

# Update $TEMP_LOG with the new modified date of $MONITORED_LOG
touch -r $MONITORED_LOG $TEMP_LOG

crontabに追加します。

スクリプトを実行可能にします。

chmod +x /somepath/monitor_mysql_log.sh

crontabを更新します。

crontab -e

* * * * * /somepath/monitor_mysql_log.sh

そして、スクリプトは毎分実行されます。

私が提供したスクリプトは、すぐにまとめたスクリプトです。また、サーバーがメールを送信できるようにするには、postfixやsendmailなどをインストールする必要があります。


おかげでたくさん...私はこのようにやったと私はレプリケーションを設定することができました
アブドゥルManaf

レプリケーションを監視するためのスクリプトを教えてください。
アブドゥルマナフ

簡単なメモですが、追加したスクリプトは、スレーブサーバーにインストールするものです。マスターサーバーにインストールすることもできますが、スレーブサーバーのエラーログは、質問に基づいて最も関心のあるログになります。
クレイグエフレイン

あなたの注意に感謝します。しかし、基本的には、レプリケーションエラーのトラブルシューティングに興味がありました。このスクリプトは、設定するエラーログの変更を監視すると思います。
アブドゥルマナフ

スレーブサーバーはデータを受信するだけで更新はしないため、エラーログに記録される情報のほとんどは複製に関するものです。たとえば、マスター上のテーブルが破損した場合、スレーブはテーブルを複製せず、基本的に複製を停止します。スレーブサーバーのエラーログにエラーが表示される場合。通常、レプリケーションに何らかの問題があることを示す非常に良い兆候です。
クレイグエフレイン

7

Mysqldumpは高速ですが、大きなDBではダンプの復元が非常に遅くなる可能性があり、稼働中のサイトではテーブルのロックは受け入れられません。スレーブを設定するはるかに優れた高速な方法は、PerconaのXtraBackupを使用することです。XtraBackupはマスターにほとんど負荷をかけず、ロックを必要とせず、スレーブの復元は非常に高速です。このメカニズムは、ユーザーテーブルのようなものを含むデータベース全体の完全なクローンを作成します。これは、必ずしも悪いことではないdebian-sys-maintユーザーなど、ストックインストールによって設定されるものを破壊します。 !

おまけとして、これを行う方法を知ったら、毎日のバックアップにまったく同じメカニズムを使用できます。バックアップはmysqldumpよりも遅くなりますが、リストアは非常に高速です。これは、パニックに陥ってバックアップをリストアする必要がある場合に必要なことです。重大な複製エラーが発生した場合は、この手順を使用してスレーブをトラッシュし、再構築してください。それほど長くはかかりません。

ディストリビューション用にPerconaのapt / yumリポジトリを設定してxtrabackupから、マスターとスレーブの両方にパッケージをインストールする必要があります。バックアップ速度に大きな違いをもたらすため、pizz圧縮ユーティリティ(ほとんどの標準リポジトリで利用可能な並列gzip)の使用も強くお勧めします。

プロセスは次のようになり(Ubuntuでは、他のディストリビューションは若干異なる場合があります)、スレーブにMySQLが既にインストールされていることを前提としています。

  1. まず、マスターでバックアップを作成します:(mkdir -p /var/xtrabackup; /usr/bin/innobackupex --slave-info --stream=tar --throttle=1500 /var/xtrabackup 2> /tmp/xtrabackup.out | /usr/bin/pigz -p 4 -c --best -q > /var/backups/mysql.tgzスロットル値を調整して、ライブサービスへのバックアップの影響を制限します)
  2. バックアップファイルをスレーブにコピーします(scp -l 400000ライブクライアントのネットワーク帯域幅のマスターを枯渇させないために使用)
  3. スレーブでmysqlを停止します。 service mysql stop
  4. 古いMySQLデータディレクトリを邪魔にmv /var/lib/mysql /var/lib/mysql2ならない場所に移動します(またはディスク領域が不足している場合はどこかに圧縮します)
  5. 新しいデータディレクトリを作成し、そこに移動します。 mkdir /var/lib/mysql; cd /var/lib/mysql
  6. バックアップファイルを新しいフォルダーに展開しますtar xvzif /path/to/backup/mysql.tgztar操作のオプションに注意してくださいi-オプションがないと動作しません。大きなDBがある場合、これには時間がかかります。
  7. 抽出されたファイルでInnobackupexツールを実行します/usr/bin/innobackupex --apply-log --use-memory=6G --ibbackup=xtrabackup /var/lib/mysql。これにより、バイナリログのファイルでクラッシュ回復が効果的に実行されます。これには数秒しかかかりません。サーバーが小さい場合は、使用するメモリ量を少なくしてください。
  8. それが正常に完了したと仮定して、バックアップを削除し、ファイルの所有権を設定します。 rm /path/to/backup/mysql.tgz; chown -R mysql:mysql /var/lib/mysql
  9. mysqlを起動します。 service mysql start
  10. マスターログファイル名とバックアップの位置を取得します(xtrabackup_slave_infoの情報ではありません)cat xtrabackup_binlog_info。それは次のようなことを言うでしょうmysql-bin.000916 13889427
  11. MySQLに接続し、何かがあることを確認します。
  12. ログについて取得した詳細を使用してレプリケーション設定をリセットしますCHANGE MASTER TO MASTER_HOST='192.168.0.1', MASTER_USER='replica', MASTER_PASSWORD='r3plica', MASTER_LOG_FILE='mysql-bin.000916', MASTER_LOG_POS=13889427;(実際のDBサーバーの詳細に一致するように変更します)。
  13. スレーブを再起動します。 START SLAVE;
  14. 'seconds_behind_master'が0になるまで、マスターに追いつくスレーブの状態を確認します。 SHOW SLAVE STATUS\G

これで、スレーブがすべて設定されました。必要に応じて、循環レプリケーションを設定できるようになりました。

  1. スレーブ上:FLUSH TABLES WITH READ LOCK; SHOW MASTER STATUS;ログファイルの名前と位置(mysql-bin.000031や17244785のようなもの)に注意してください。
  2. マスター:でCHANGE MASTER TO MASTER_HOST='192.168.0.2', MASTER_USER='replica', MASTER_PASSWORD='r3plica', MASTER_LOG_FILE='mysql-bin.000031', MASTER_LOG_POS=17244785;、先ほど見たスレーブから値を挿入します。
  3. マスターで: START SLAVE;
  4. スレーブ上: UNLOCK TABLES;

これで、すべて循環レプリケーションが設定されました。

トラブルシューティングに関する限り、Perconaのツールキットには、サイレントな破損を発見するためのチェックサム、ラグ測定などを支援するあらゆる種類の機能があります。binlog_format = MIXEDmy.cnfに設定することにより、レプリケーションの破損の最も一般的な形式を回避できます。とはいえ、私の経験では、レプリケーションは一般的に面倒ではありません。


あなたの忠誠は何ですか?
Pacerier

満足しているユーザーとして以外。
シンクロ
弊社のサイトを使用することにより、あなたは弊社のクッキーポリシーおよびプライバシーポリシーを読み、理解したものとみなされます。
Licensed under cc by-sa 3.0 with attribution required.