トランザクションのCOMMIT時に、InnoDBログファイルへデータがディスクへ同期されるかどうかを指定。指定できる値は0,1,2でデフォルトは1。1の場合COMMITごとにログファイルへの書き込みとディスクへの同期が行われる。0の場合はCOMMIT時には何も行われず1秒ごとにログファイルへの書き込みとディスクへの同期が行われる。2の場合COMMITと同時にログファイルへの書き込みが行われるがディスクとの同期は1秒ごと。max_binlog_sizeとexpire_logs_daysはデフォルト値でも問題ないかと思います。sync_binlog=1,innodb_support_xa=1,innodb_flush_log_at_trx_commit=1のとき、バイナリログとInnoDBログファイルは完全に同期されます。sec)mysql>ちなみに、GRANTを利用してユーザを作ることは近々出来なくなるらしいです。TOコマンドをダンプの先頭に付加。ダンプする際に先頭にBEGINをつける(ダンプ時のデータのトランザクションの一貫性を保つことができる)。]【スレーブ】ダンプファイルをマスターからコピーSCPかなんかで。MASTER_LOG_POS=154;MASTER_LOG_FILEがバイナリログファイル名、MASTER_LOG_POGがログのポジションとなります。マスタへの再接続を行う間隔(秒)*先ほど確認したバイナリログファイル名とポジションを指定します。sec)「Slave_IO_Running」と「Slave_SQL_Running」がYesになっていれば正常です。ちなみにエラーが起きている場合は以下のような状態になります。「Connecting」となっており、「Last_IO_Error」にエラーメッセージが出力されています。実際にレプリケーションが動いているかどうかをzaikoテーブルにレコードを追加して確認してみます。sec)データの同期が取れているので、正常に動作しているようです。RHEL以前にこんな出来事がありました。同僚「あの~、サーバのcron設定が全部消えちゃったみたいなんですけど。私「ん?ちょっと見てみますね(そんなことないだろうな。何か勘違いなんだろう。同僚「crontabのオプションで-rオプション付けて実行しました。工工工エエエエエエェェェェェェ(゚Д゚)ェェェェェェエエエエエエ工工工とそんなときにやったことを残しておきます。復旧方法/var/log/cronには以下のようにcronの実行内容が出力されています。1)この情報をもとに実行間隔と実行コマンドを見たうえでcronに書いて復旧させました(地味^^;)。以後はcronを更新する際は専用のファイルを更新し、それをcrontabコマンドで読み込む運用にしました。/hogehoge/crontab.bakこれであればcronが消えても復旧はできるかなと。Tumblr広告を非表示にするもっと読むコメントを書く次のページプロフィールid:saosao_0706低レベルインフラエンジニアの忘備録です。読者になる検索リンクはてなブログブログをはじめる週刊はてなブログはてなブログPro最新記事Netdataが動かない。ブログを報告するスターをつけました引用をストックしましたストック一覧を見る閉じる引用するにはまずログインしてくださいログイン閉じる引用をストックできませんでした。再度お試しください閉じる限定公開記事のため引用できません。