MySQLマスター/スレーブレプリケーションセットアップを作成してトラブルシューティングするための最良の方法は何ですか？
データベース管理は初めてです。
Mysqlマスター/スレーブレプリケーションの設定中に多くの問題に直面します。
また、定期的なmysqlレプリケーションのトラブルシューティングの問題にも直面しています。
誰もがこれらすべてにどのように対処すべきかを理解するのに役立ちますか？
チュートリアルへのリンクを提供しました。 Ubuntuでは、my.cnfファイルが/etc/mysql/my.cnfにあり、howtoforgeチュートリアルのように/etc/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：Waiting for master to send event」が表示されます。
この設定を正しく取得したら、その複製を監視するスクリプトを提供できます。
MySQLのエラーログを監視するスクリプトは次のとおりです。行を追加すると
[mysqld]
log-error = /var/log/mysql/mysql.err
mysqlを再起動します。/etc/init.d/mysql restart
その後、次のスクリプトを使用してログファイルを監視できます。ログが何らかの形で変更されると、スレーブサーバーでエラーが発生したことを通知するメールが届きます。エラーログを定期的にチェックする場合は、このスクリプトをcrontabに追加する必要があります。
次にスクリプトの例を示します。/somepath/monitor_mysql_log.sh
#! /bin/sh
MAIL_TO="[email protected]"
# 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などをインストールする必要があります。
Mysqldumpは高速ですが、大きなDBの場合、ダンプの復元はvery遅くなる可能性があり、ライブサイトではテーブルのロックは受け入れられません。スレーブを設定するはるかに良い、より速い方法は PerconaのXtraBackup を使用することです。 XtraBackupはマスターにほとんど負荷をかけず、ロックを必要とせず、スレーブでの復元は非常に高速です。このメカニズムは、ユーザーテーブルなど、データベース全体の完全なクローンを作成します。これにより、debian-sys-maintユーザーなど、ストックインストールによって設定されたいくつかのものが壊れますが、これは必ずしも悪いことではありません。 ！
おまけとして、これを行う方法を知ったら、毎日のバックアップにまったく同じメカニズムを使用できます。バックアップはmysqldumpよりも低速ですが、復元ははるかに高速です。これは、パニックが発生してバックアップを復元する必要がある場合に必要なことです。重大なレプリケーションエラーが発生した場合は、この手順を使用してスレーブを破棄して再構築します。本当に時間がかかりません。
ディストリビューション用に Perconaのapt/yumリポジトリ を設定してから、マスターとスレーブの両方にxtrabackupパッケージをインストールする必要があります。 pigz 圧縮ユーティリティ（並列gzip、ほとんどの標準リポジトリで利用可能）を使用することを強くお勧めします。バックアップ速度が大幅に異なるためです。
プロセスは次のようになり（Ubuntuでは、他のディストリビューションは少し異なる場合があります）、MySQLがスレーブにすでにインストールされていることを前提としています。
- まず、マスターでバックアップを作成します：
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（スロットルの値を調整して、ライブサービスへのバックアップの影響を制限します） - バックアップファイルをスレーブにコピーします（ライブクライアントのネットワーク帯域幅のマスターを枯渇させないために
scp -l 400000を使用してください） - スレーブでmysqlを停止します：
service mysql stop - 古いMySQLデータディレクトリを邪魔にならない場所に移動します：
mv /var/lib/mysql /var/lib/mysql2（または、ディスク領域が不足している場合は、どこかに圧縮します） - 新しいデータディレクトリを作成してそこに移動します：
mkdir /var/lib/mysql; cd /var/lib/mysql - バックアップファイルを
tar xvzif /path/to/backup/mysql.tgzという新しいフォルダに解凍します。 tar操作のiオプションに注意してください-これがないと機能しません。大きなDBがある場合、これにはしばらく時間がかかります。 - 抽出したファイルに対してInnobackupexツールを実行します：
/usr/bin/innobackupex --apply-log --use-memory=6G --ibbackup=xtrabackup /var/lib/mysql。これにより、バイナリログのファイルに対してクラッシュリカバリが効果的に実行されます。これには数秒しかかかりません。サーバーが小さい場合は、使用するメモリ量を減らします。 - これが正常に完了したと想定して、バックアップを削除し、ファイルの所有権を設定します：
rm /path/to/backup/mysql.tgz; chown -R mysql:mysql /var/lib/mysql - Mysqlを開始します：
service mysql start - バックアップのマスターログファイル名と位置を取得します（xtrabackup_slave_infoの情報ではないことに注意してください）：
cat xtrabackup_binlog_info。mysql-bin.000916 13889427のようになります - MySQLに接続し、そこにあることを確認します。
- ログについて取得した詳細を使用してレプリケーション設定をリセットします：
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サーバーの詳細と一致するように変更） - スレーブを再起動します：
START SLAVE; - スレーブが 'seconds_behind_master'が0になるまでマスターに追いつくように、スレーブのステータスを確認します。
SHOW SLAVE STATUS\G
これで、スレーブがすべてセットアップされました。必要に応じて、循環レプリケーションを設定できます。
- スレーブ：
FLUSH TABLES WITH READ LOCK; SHOW MASTER STATUS;ログファイルの名前と位置（mysql-bin.000031や17244785など）をメモします。 - マスター：
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;、今見たスレーブから値を挿入します。 - マスター：
START SLAVE; - スレーブ：
UNLOCK TABLES;
これで、循環レプリケーションがすべて設定されました。
トラブルシューティングに関する限り、 Perconaのツールキット には、サイレントな破損を見つけるためのチェックサム、遅延測定など、あらゆる種類のものが含まれています。 my.cnfでbinlog_format = MIXEDを設定すると、最も一般的なレプリケーションの破損を回避できます。とはいえ、私の経験では、複製は一般的に面倒ではありません。