私はデータベース管理を始めたばかりです。
mysqlマスター/スレーブレプリケーションのセットアップ中に多くの問題に直面します。
また、通常のmysqlレプリケーションのトラブルシューティングの問題に直面しています。
誰もがこれらすべてに対処する方法を理解するのに役立ちますか?
私はデータベース管理を始めたばかりです。
mysqlマスター/スレーブレプリケーションのセットアップ中に多くの問題に直面します。
また、通常のmysqlレプリケーションのトラブルシューティングの問題に直面しています。
誰もがこれらすべてに対処する方法を理解するのに役立ちますか?
回答:
チュートリアルへのリンクを提供しました。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/で大丈夫に見えた別のチュートリアル
私が使用した構成は次のとおりです。
マスターサーバーを構成します。
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/
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などをインストールする必要があります。
Mysqldumpは高速ですが、大きなDBではダンプの復元が非常に遅くなる可能性があり、稼働中のサイトではテーブルのロックは受け入れられません。スレーブを設定するはるかに優れた高速な方法は、PerconaのXtraBackupを使用することです。XtraBackupはマスターにほとんど負荷をかけず、ロックを必要とせず、スレーブの復元は非常に高速です。このメカニズムは、ユーザーテーブルのようなものを含むデータベース全体の完全なクローンを作成します。これは、必ずしも悪いことではないdebian-sys-maintユーザーなど、ストックインストールによって設定されるものを破壊します。 !
おまけとして、これを行う方法を知ったら、毎日のバックアップにまったく同じメカニズムを使用できます。バックアップはmysqldumpよりも遅くなりますが、リストアは非常に高速です。これは、パニックに陥ってバックアップをリストアする必要がある場合に必要なことです。重大な複製エラーが発生した場合は、この手順を使用してスレーブをトラッシュし、再構築してください。それほど長くはかかりません。
ディストリビューション用にPerconaのapt / yumリポジトリを設定してxtrabackup
から、マスターとスレーブの両方にパッケージをインストールする必要があります。バックアップ速度に大きな違いをもたらすため、pizz圧縮ユーティリティ(ほとんどの標準リポジトリで利用可能な並列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
ライブクライアントのネットワーク帯域幅のマスターを枯渇させないために使用)service mysql stop
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がある場合、これには時間がかかります。/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
service mysql start
cat xtrabackup_binlog_info
。それは次のようなことを言うでしょうmysql-bin.000916 13889427
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;
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のツールキットには、サイレントな破損を発見するためのチェックサム、ラグ測定などを支援するあらゆる種類の機能があります。binlog_format = MIXED
my.cnfに設定することにより、レプリケーションの破損の最も一般的な形式を回避できます。とはいえ、私の経験では、レプリケーションは一般的に面倒ではありません。