詳細なMySQLのログ（続きます）

序文

MySQLのMySQLデータベースのログは、毎日の操作やエラーメッセージを記録します。MySQLのログファイルの種類は、MySQLデータベース、ユーザの操作、誤った情報の操作からのログを照会することができます（ログの各店舗の異なる種類）があります。

次の4つのカテゴリにログインMYSQL：

エラーログ：レコードは、mysqlのサービスを開始し、実行するときに発生するか、MySQLサービスの問題を停止します。

クエリログ：文と確立クライアント接続の実行を記録。

バイナリログ：データをコピーするために使用することができ文のデータへのすべての変更の記録。

スロークエリログ：long_query_time上で実行されたすべての時間のインデックスを使用せずに、すべてのクエリまたはクエリの記録。

デフォルトでは、すべてのログをMySQLデータディレクトリに作成され、ログを更新し、ログ・ファイルをクローズにMySQLを強制し、再度開くことができ、フラッシュログは、ログを更新するか、MySQLのレプリケーション機能を使用している場合、mysqladminはフラッシュ・ログを実行し、複製サーバー上で維持することができます私たちは、ログは、ログを成功呼び出す以上のログファイルについて。スタートロギングは、MySQLデータベースのパフォーマンスを損なうことがあります。

1）システム設定を表示します

<!--查看全局的系统状态-->
mysql> show global variables\G
mysql> show global variables like '%log%';
<!--查看当前会话的系统状态-->
mysql> show session variables\G
mysql> show session variables like '%log%';

binlog_cache_size = 1M：上記のパラメータのうち、ビューを変更するには、フィールドのように、mysqldのMySQLのメインの設定ファイルに書き込むことができます。または一時的にMySQLデータベースに変更することがあります。一時的にMySQLを変更設定されたグローバルbinlog_cache_size = 1048576は、再起動後に期限切れになります。

2）実行中の状態を確認

<!--查看全局的运行状态-->
mysql> show global status\G
<!--查看当前会话的运行状态-->
mysql> show session status;
<!--查看MySQL的版本-->
[root@mysql ~]# mysql -V
mysql> status;
mysql> select version();

1、エラーログ

MySQLのデータベースでは、エラーログはデフォルトで有効になっています。デフォルトでは、エラーログは、データディレクトリのmysqlデータベースに格納されています。エラーログファイルは、通常hostname.errの名前です。ここで、hostnameはサーバのホスト名を表します。エラーログ情報自体を構成することができ、記録されたエラーログは、エラー・ログ、およびエラーログ機能の格納場所を有効にするかどうかをログエラーが定義されているログ・エラーおよびログ警告、対数によって定義することができます。警告は、警告メッセージが、エラーログに定義されるかを定義することです。次のデフォルトの側面についての情報を記録するエラーログ：サーバーの起動とシャットダウンのプロセス情報（例えばMySQLのInnoDBテーブルスペースファイルを起動する方法として必ずしも間違った情報を、独自のストレージエンジンなどを初期化する方法）、サーバが実行されているエラーメッセージ、イベントスケジューラがイベントを実行する際に生成された情報は、サーバプロセスがサーバから開始されたときに生成された情報は、MySQLの、システム変数の設定が異なって設定することができ、多くのシステム変数があり、それは、状態を実行するためのシステムの原因となります異なります。だから、mysqlのコマンドは、2つのセット、それぞれ、表示システム設定や動作状態を提供します。

一般的には、ログレベル定義なしセッション状態変数は、単にエラーログがグローバルレベルで定義されています。

mysql> show global variables like '%log_error%';
+---------------------+----------------------------------+
| Variable_name       | Value                            |
+---------------------+----------------------------------+
| binlog_error_action | ABORT_SERVER                     |
| log_error           | /usr/local/mysql/data/mysqld.err |
| log_error_verbosity | 3                                |
+---------------------+----------------------------------+
3 rows in set (0.01 sec)

意味は次のエラー・ログ・ファイルのパス、log_error_verbosityの価値があるように定義されてLOG_ERROR：

多弁	メッセージ
1	唯一のエラー
2	エラーと警告
3	エラー、警告、およびノート（デフォルト）

それは次のようにエラー・ログ保存パスは、メインの設定ファイルmy.cnfファイルで指定されました：

詳細なMySQLのログ（続きます）

メンテナンスの必要性を容易にするために、時々バックアップのためのエラー・ログの内容を欲しいと再び録音を開始、あなたはMySQLのFLUSHログコマンドを利用することができ、この時間は、MySQLのバックアップ古いログファイルを伝え、新しいログファイルを生成します。バックアップファイル名の末尾に「.OLD」へ。

エラーログを削除します
mysql5.5.7前：データベース管理者は、サーバのMySQLのハードディスク容量ことを保証するために、長い前に、エラーログを削除することができます。mysqlデータベースは、新しいエラーログを開くためのmysqladminコマンドを使用することができます。次のようにはmysqladminコマンドの構文は次のとおりです。mysqladminは-uルート-pフラッシュ・ログはまた、新しいエラーログを開くには、FLUSH LOGSのステートメントを使用してMySQLデータベースにログインすることができます。mysql5.5.7後：サーバーは、この機能を無効にします。手動で次のように、新しいを作成するために、ログをフラッシュし、唯一のオリジナルのエラー・ログ・ファイルの名前を変更使用します。

[root@mysql ~]# cd /usr/local/mysql/data/
[root@mysql data]# mv mysqld.err{,.old}
[root@mysql data]# mysqladmin -uroot -p flush-logs
Enter password:

2、バイナリログ

MySQLのバイナリログは、効率的なバイナリログ形式でデータベースに大きな変化を記録し、使用可能なログに含まれる情報を更新するトランザクションセーフな方法です。バイナリログは、すべてのデータが更新されている含まれていたり、データを更新する可能性を秘めています。また、それは任意のデータを変更しない文が含まれていない各アップデートデータベースの実行時間に関する記述が含まれています。バイナリログを使用しての主な目的は、データベースを復元する可能性が最も高いです。

1）（デフォルトでは、バイナリログがオフになっている）バイナリログを開始します

[root@mysql data]# vim /etc/my.cnf      #编辑主配置文件

[mysqld]
basedir=/usr/local/mysql
datadir=/usr/local/mysql/data
port=3306
server_id=1
socket=/usr/local/mysql/mysql.sock
log-error=/usr/local/mysql/data/mysqld.err
log-bin=/usr/local/mysql/data/binary_log      #指定二进制日志的路径及名称
expire_logs_days=10         #清除日志的天数
max_binlog_size=100M      #单个日志文件的大小限制，超出会新建一个日志文件
[root@mysql data]# systemctl restart mysqld      #重启MySQL使配置生效
[root@mysql data]# ll | grep binary         #会在指定的路径下生成以下两个文件
-rw-r----- 1 mysql mysql      154 12月 30 20:59 binary_log.000001
-rw-r----- 1 mysql mysql       40 12月 30 20:59 binary_log.index

次のようにログはデータベースにも、表示することができます。

詳細なMySQLのログ（続きます）

2）バイナリログをチェックしてください

MySQLの情報の変更のすべてのバイナリログの店舗は、MySQLバイナリログが使用されることが多いです。MySQLのバイナリログファイルを「ファイル名」を作成するために、まず、作成されると「.INDEX」接尾辞のファイルへの名前です; 『ファイル名』を作成するために、ファイルに「0.000001'接尾辞に名前です。ときに一度の」0.000001'接尾辞増加するファイルと拡張子プラス1つのMySQLサービスを再起動
刻み。ログの長さを超える場合は上限max_binlog_sizeは、新しいログが作成されます。バイナリログを表示します。あなたは現在のバイナリログファイル名とファイル数を表示することができます。バイナリログを直接見ることができない、あなたは、ログの内容を表示したい場合は、

mysqlbinlogはコマンドを表示できます。

mysql> show binary logs;             <!---->
+-------------------+-----------+
| Log_name          | File_size |
+-------------------+-----------+
| binary_log.000001 |       154 |
+-------------------+-----------+
1 row in set (0.00 sec)

また、コマンドラインでexit MySQLのmysqlbinlogはコマンドを使用することができます。

[root@mysql data]# mysqlbinlog binary_log.000001

3）バイナリログを削除

MySQL的二进制文件可以配置自动删除，同时MySQL提供了手动删除二进制文件的方法：
RESET MASTER：删除所有的二进制日志文件；
PURGE MASTER LOGS：只删除部分二进制日志文件；
Reset master：删除所有二进制日志；
Purge master logs to ‘二进制名’ ：删除单个二进制日志之前的。

mysql> purge master logs to "binary_log.000003";   <!--删除...03之前的二进制日志文件-->
mysql> purge master logs before '20180101';    <!--删除2018-01-01之前的日志文件-->

4）通过二进制日志还原MySQL数据

关于通过二进制日志还原的具体过程，还是参考我之前的博文吧！如下：
MySQL的备份与恢复详解

3、事务日志

事务日志（InnoDB特有的日志，因为只有Innodb支持事务）可以帮助提高事务的效率。使用事务日志，存储引擎在修改表的数据时只需要修改其内存拷贝，再把修改行为记录到持久在硬盘上的事务日志中，而不用每次都将修改的数据本身持久到磁盘。事务日志采用追加的方式，因此写日志的操作是磁盘上一小块区域内的顺序I/O，而不像随机I/O需要在磁盘的多个地方移动磁头，所以采用事务日志的方式相对来说要快得多。事务日志持久以后，内存中被修改的数据在后台可以慢慢的刷回到磁盘。目前大多数的存储引擎都是这样实现的。如果数据的修改已经记录到事务日志并持久化，但数据本身还没有写回磁盘，此时系统崩溃，存储引擎在重启时能够自动恢复这部分修改的数据。具有的恢复方式则视存储引擎而定。

1）查看事务日志的定义

mysql> show global variables like 'innodb_lo%';

在上述指令输出的部分内容解释如下：

| innodb_flush_log_at_trx_commit | 1 #在事务提交时innodb是否同步日志从缓冲区到文件
中，当这个值为1（默认值）之时，在每个事务提交时，日志缓冲被写到日志文件，对日志文件做到磁盘操作的刷新，性能会很差造成大量的磁盘I/O但这种方式最安全；如果设为2,每次提交事务都会写日志，但并不会执行刷的操作。每秒定时会刷到日志文件。要注意的是，并不能保证100%每秒一定都会刷到磁盘，这要取决于进程的调度。每次事务提交的时候将数据写入事务日志，而这里的写入仅是调用了文件系统的写入操作，而文件系统是有缓存的，所以这个写入并不能保证数据已经写入到物理磁盘。设置为0，日志缓冲每秒一次地被写到日志文件，并且对日志文件做到磁盘操作的刷新，但是在一个事务提交不做任何操作。
注：刷写的概念
刷写其实是两个操作，刷（flush）和写（write），区分这两个概念是很重要的。在大多数的操作系统中，把Innodb的log buffer（内存）写入日志（调用系统调用write），只是简单的把数据移到操作系统缓存中，操作系统缓存同样指的是内存。并没有实际的持久化数据。

所以，通常设为0和2的时候，在崩溃或断电的时候会丢失最后一秒的数据，因为这个时候数据只是存在于操作系统缓存。之所以说“通常”，可能会有丢失不只1秒的数据的情况，比如说执行flush操作的时候阻塞了。总结设为1当然是最安全的，但性能页是最差的（相对其他两个参数而言，但不是不能接受）。如果对数据一致性和完整性要求不高，完全可以设为2,如果只最求性能，例如高并发写的日志服务器，设为0来获得更高性能。		innodb_locks_unsafe_for_binlog	OFF		innodb_log_buffer_size	16777216		innodb_log_checksums	ON
innodb_log_compressed_pages	オン
innodb_log_file_size	50331648＃ログファイルのサイズ
innodb_log_files_in_group	2＃DBは、トランザクション・ログのいくつかのグループを設定し、デフォルトは2です
innodb_log_group_home_dir	./定義された位置＃は、トランザクション・ログ・グループInnoDBは、この位置は、MySQLのdatadirのためのデフォルトとして設定されています。

各トランザクションログは、50メガバイト（mysqlの差の異なるバージョン）のファイルサイズである：デフォルトib_logfile0に、ib_logfile1名は、MySQLに存在します。

<！---->