MySQL binlogの削除 - weblog of key_amb
PURGE MASTER LOGS構文を使う。 以下の手順でやればよい。 手順 1. どこまでbinlogを削除していいか調べる。 Slave側でSHOW SLAVE STATUSを実行する。Master_Log_Fileが現在参照中のbinlog。 mysql > SHOW SLAVE STATUS; : Master_Log_File: mysql00-bin.000010 : ちなみに、Master側でSHOW MASTER STATUSを実行すると、Masterのbinlog情報が取得できる。 mysql > SHOW MASTER STATUS; +--------------------+----------+--------------+------------------+ | File | Position | Binlog_Do_DB | Binlog_Ignore_D
MySQLでバイナリログを削除したら立ち上がらなくなったので直す。
と書いてやれば、バイナリログはデフォルトディレクトリに保存され、7日前より古いログは順次消去されます。これはこれで問題なし。 で、手動でバイナリログを削除したいとき。正式には、コマンドラインから root ユーザとして mysql を立ち上げて、
MySQL + ioDrive + XFSにおけるbinlogローテート問題 | 外道父の匠
前回の問題とはまた別件で、今度はbinlogのローテート切り替わりタイミングに更新クエリが停滞する、という問題を調べることになりました。 調査の過程で何を誤ったか、Twitterという魔法陣から最強クラスの重鎮魔神を召喚してしまい、恐れ多くも原因の特定と対応方針の決定ができてヘコヘコな感じでございます。 binlogローテート時の障害 数十分に１回、更新クエリが停滞してアプリケーションにエラーログが残るということから、他のエンジニアが、どうもbinlogの切り替わり時にそれが起きているっぽいことを特定してくれました。発生時は1～3秒は更新機能が停止するので、結構なレベルの障害ということでした。 binlogは1GBでローテートするように設定していたのですが、dstat -d でwrite容量を見ていると、確かに切り替わり時に800～900MBの書き込みを確認できました。 このことから、bi
MySQL 5.6 でのレプリケーション遅延は危険 : DSAS開発者の部屋
MySQL 5.6 の検証中に MySQL 5.5 とは違うタイプのレプリケーション遅延を見つけたので紹介します。 MySQL のレプリケーションのおさらい MySQL のレプリケーションは次のような仕組みで動作しています。 マスターの更新トランザクションが binlog を書く スレーブの I/O スレッドがマスターに接続し、 binlog を取得し、 relaylog を書く. マスター側はスレーブからの接続を受け付けると(dump スレッド)、指定された場所から最新までの binlog を転送する binlog が追記されるのを待ってさらにスレーブに送る スレーブのSQLスレッドが relaylog を再生する MySQL 5.5 でよくあったレプリケーション遅延 マスターは並列してトランザクションを処理して、最終的にコミットした順で反映されれば問題ないようになっています。 一方、ス
1
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
処理を実行中です
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
