今日、一緒に私の同僚と私たちはこの問題に対処するから、奇妙な異常MySQLのスペースの問題に対処する問題のいくつかに対処する方法で見つけることができます。
背景の問題は、利用可能なスレーブの状況は、脇に設定する時間によって、これらの日は、ちょうど次の仕上げや櫛を行うことを保証するために、調査の数回の後、常にインスタンス障害のバックアップがあるということです。
バックアップ失敗のエラーメッセージは次のとおりです。
innobackupex: Error writing file '/tmp/xbtempevLQbf' (Errcode: 28 - No space left on device)
xtrabackup: Error: write to logfile failed
xtrabackup: Error: xtrabackup_copy_logfile() failed.
ルックスともっと簡単な問題、スペースまあの欠如、問題はスペースの設定ではありません。
しかし、時にローカルでシミュレーションテスト、マシンのテストをオンにするために、次のスクリプトを使用します。
/usr/local/mysql_tools/percona-xtrabackup-2.4.8-Linux-x86_64/bin/innobackupex --defaults-file=/data/mysql_4308/my.cnf --user=xxxx --password=xxxx --socket=/data/mysql_4308/tmp/mysql.sock --stream=tar /data/xxxx/mysql/xxxx_4308/2020-02-11 > /data/xxxx/mysql/xxxx_4308/2020-02-11.tar.gz
我々は、/ tmpディレクトリは、異常な状況のためのスペースがない場所を見つけましたが、代わりに、ルートディレクトリのスペースを使用しているショットのテストはスペースを傍受異例である、異常があらわれました。
そして、例外をスローした後、バックアップが失敗し、スペースの使用量はすぐに回復しました。
現在入手可能な総合的な情報は、私の質問は、一見、直感的な感触と/ tmpにすぎないの直接リンクで、それは他のディレクトリのルートディレクトリの過程でなければなりませんが、例外を発生させます。
第二の試験を開始しました、私が最後に見てどのディレクトリ、ルートディレクトリの全体的な使用に焦点を当て、この時間が異常である私は、そう、それは、スクリプトの彼らの急速な買収にもかかわらず、でも私たちの共通点が見つからない恥ずかしいです宇宙異常ディレクトリ。
332K ./home
411M ./lib
26M ./lib64
16K ./lost+found
4.0K ./media
4.0K ./misc
4.0K ./mnt
0 ./net
184M ./opt
du: cannot access `./proc/40102/task/40102/fd/4': No such file or directory
du: cannot access `./proc/40102/task/40102/fdinfo/4': No such file or directory
du: cannot access `./proc/40102/fd/4': No such file or directory
du: cannot access `./proc/40102/fdinfo/4': No such file or directory
0 ./proc
2.3G ./root
56K ./tmp
。。。
そのため、現在の状況から、それが異常に関連付けられている/ procディレクトリの下のスペースにする必要があります。
この時点までのものは、利用可能な方法が不足しているようです。
私は（明らかな環境やその他の問題に比べて全体として、スクリプトを使用して調査ファイルのパラメータを行ったが、私の注意を引いた1つの詳細があり、そしてそれは、この例のメモリが6Gを使用して見て、トップを使用することですしていますサーバーのメモリは8G）があるが、バッファプールの設定は、環境からのライブラリであり、3G、についてです、そこにあまりにも多くの接続、リソースの消費量があることはほとんどありませんので、何のアプリケーション接続は、ありませんので、全体、およびサーバーである必要がありますメモリ異常。
今回は、オンラインリサイズを試みるのはスペースの縮小を認めませんでした。それは図書館サービスからなので、私は図書館からサービスを再開し始めました。
しかし、予想外のとき立ち往生、私はプランBにしようとして始めたので、ちょうどいくつかの小数出力、二行のおおよそ出力、まだ無応答、無背景のチェック、ログ出力を確認するために、おそらく2分後に、データベースを再起動することですキル・プロセスへの準備ができて、サービスを再起動します。
今回は、殺傷効果に操作し、後はサービスが起動している間。しかし、ライブラリーからの異常なコピーを報告しました。
Last_IO_Error: Got fatal error 1236 from master when reading data from binary log: 'The slave is connecting using CHANGE MASTER TO MASTER_AUTO_POSITION = 1, but the master has purged binary logs containing GTIDs that the slave requires.'
。。。
Master_Server_Id: 190
Master_UUID: 570dcd0e-f6d0-11e8-adc3-005056b7e95f
。。。
Slave_SQL_Running_State: Slave has read all relay log; waiting for more updates
Master_Retry_Count: 86400
Master_Bind:
Last_IO_Error_Timestamp: 200211 14:20:57
Retrieved_Gtid_Set: 570dcd0e-f6d0-11e8-adc3-005056b7e95f:821211986-2157277214
Executed_Gtid_Set: 570dcd0e-f6d0-11e8-adc3-005056b7e95f:1-820070317:821211986-2157277214
このエラーメッセージは、より明白である失敗したライブラリからアプリケーションをコピーするための時間で、その結果、失われたメインライブラリbinlogのパージです。
メインライブラリのbinlogデフォルトまたは日数のいくつかの数を保持し、削除前に1時間BINLOG入れないので、なぜ、このような奇妙な質問が、あります。
次のように変数の数にGTIDの値は次のとおりです。
Retrieved_Gtid_Set：570dcd0e-f6d0-11e8-adc3-005056b7e95f：821211986から2157277214
Executed_Gtid_Set：570dcd0e-f6d0-11e8-adc3-005056b7e95f：1から820070317：821211986から2157277214
gtid_purged：570dcd0e-f6d0-11e8-adc3-005056b7e95f：1から820070317：821211986から2131381624
マスター側はとしてGTID_Purged：
gtid_purged：570dcd0e-f6d0-11e8-adc3-005056b7e95f：1から2089314252
手段、このスレーブがGTIDにつながったいくつかの操作を行って前に、ビューの包括的な情報ポイント、スレーブGTIDのメインライブラリーの終わりと完全にリンクアップの不在は、マスターとスレーブの最後には、いくつかの偏差を生産しました。
および変更のこの欠けている部分570dcd0e-f6d0-11e8-adc3-005056b7e95f：821 211 986は、バイナリログは確かに予約されていない前に控えめに推定するには、月です。
私たちは、一時的に複製の問題を修正するためにここにいます。
ストップスレーブが問題を期待していなかった、一見単純なストップスレーブ動作は、実際には1分続きました。
>>停止スレーブ;
クエリOK、影響を受けた0行（1分1.99秒）
遅延が問題ではなく、バッファプールの関係は、この方向に除外し、比較的大きなGTID関係することができますので、この操作は、非常に遅いまだ、バッファプールの設定、再起動、停止スレーブを減らしてみてください。
スレーブ側の修正は、次の手順：
reset master;
stop slave;
reset slave all;
SET @@GLOBAL.GTID_PURGED='570dcd0e-f6d0-11e8-adc3-005056b7e95f:1-2157277214';
CHANGE MASTER TO MASTER_USER='dba_repl', MASTER_PASSWORD='xxxx' , MASTER_HOST='xxxxx',MASTER_PORT=4308,MASTER_AUTO_POSITION = 1;
どのGTID_PURGED設定キーです。
修理後、解決し、いなくてもスペースの消費量のルートディレクトリに、再びバックアップしようとするスレーブ側を遅らせます。
要約：
このプロセスは、主に問題を迅速に解決するために、いくつかのステップのクロールログが豊富で詳細な、問題の分析から、それはまだ、より説得力の事のいくつかを十分に欠けていないが、問題の原因のため、本質的に、それは無理があります（等の異常バグや構成など）の問題が異常につながりました。
この1で我々はまだ分析の全体的なアイデアではなく、問題自体から学ぶことができます。
手術をせずに適切な方法ので、患者があってもよく、手術方法がない、手術を越えて
懸念へようこそJavaの道公開番号
良い記事、私は見て ❤️
