mysql 服务日志 5.7.29
1MySQL日志种类
|
日志种类
|
描述
|
|
error log
|
mysqld 启动，运行，停止出现的错误
|
|
General query log
|
建立客户端连接及客户端的查询语句
|
|
Binary log
|
更新数据的语句或者用于集群
|
|
Slow query log
|
查询时间超过long_query_time设置秒数的语句
|
|
Relay log
|
集群中从主节点同步过来的变化数据
|
|
DDL log
|
元数据 ddl语句
|
默认情况下，除了错误日志其他日志都是关闭状态的。DDL log 没有用户配置选项。
打开所有的日志开关，服务端写日志，默认路径在数据文件夹下。二进制日志被刷新，当文件大小达到max_binlog_size设置。
中继日志只在集群备份节点，保存从主节点同步的变化数据，并且在从节点上执行。
2.常规日志及慢查询日志输出目标
MySQL提供灵活控制常规日志及慢查询日志的数据输出位置，如果日志打开。提供两种方式，日志输出文件和数据表，mysql.general_log和 mysql.slow_log。
2.1服务启动时日志控制
log_output 系统变量指出日志以何种方式输出。如果没有设置，log_output = FILE,如果在启动时设置log_output,这是值是个集合{TABLE,FILE,NONE}。
gengeral_log 系统变量控制查询常规日志的输出。设置general_log=1打开日志输出,默认情况下，general_log_file是日志输出路径。
同理slow_query_log控制慢查询，slow_query_log_file是日志输出的路径。
例如：
如果常规日志要写到log表及日志文件中，需要设置 -- log_output = TABLE,FILE ，--general_log =1 。
如果常规日志只写到日志表中， --log_output=TABLE,--general_log =1|ON。
如果慢日志只写到日志文件中，使用--log_output=FILE,--slow_query_log=1.默认log_output=FILE、只需要打开slow_query_log。
2.2运行时日志控制
日志表和文件系统变量可以再运行时控制。
log_output变量表明log以哪种方式输出。在运行时可以改变。
general_log 和 slow_query_log变量指出是否打开常规日志和慢查询日志，运行时可以修改。
general_log_file 和 slow_query_log_file变量指出常规日志及慢查询日志的文件名称，在运行时可以修改。
关闭或者打开当前会话的常规日志，可以设置sql_log_off=ON|OFF，确保常规日志查询是打开的。
set @@global.log_output='TABLE,FILE'; set @@global.slow_query_log=1;
2.3日志表好处及特征
2.3.1优势
日志表有标准的格式。查询表结构
show create table mysql.general_log; desc mysql.general_log;
日志内容只能通过Sql语句访问。安全性。
任何有权限的客户端都可以远程访问日志内容。没有必要登录数据库服务，直接访问文件系统。
2.3.2特征
- 根本上，日志表的主要意图是提供接口，客户端可以知道服务端的运行时异常，而不是接口的运行时异常。
- 创建表及修改表，删除表都是合法的操作，记录在日志表中。
- 默认，日志表用csv存储引擎，写数据使用常用的分隔符格式数据。用户访问.csv文件，很容易倒进其他的程序。
- 日志表可以修改使用MyISAM存储引擎。你不能使用alter table 修改正在使用日志表。日志必须先关闭。只能使用CSV或者MyISAM引擎。
- 日志表打开次数太多错误。如果使用日志表同时存储引擎使用csv存储引擎，运行中，你可能发现关闭或者打开常规日志，慢日志，导致产生大量.csv文件的文件描述符，可能会导致’too many open files ‘错误。为了解决这个问题，执行flush tables 或者 确保open_files_limit=5000的值比table_open_cache_instances=16的值大。
- 为了关闭日志，你可以修改或者删除日志表，你可以使用下面的策略。这个案例是常规查询日志；slow查询日志处理过程和这个相似但是你可以使用slow_log表和slow_query_log系统变量。
SET @old_log_state = @@GLOBAL.general_log; SET GLOBAL general_log = 'OFF'; ALTER TABLE mysql.general_log ENGINE = MyISAM; SET GLOBAL general_log = @old_log_state;
- truncate日志表是合法的操作， 可以清理过期的日志实体。
TRUNCATE TABLE general_log;
- 日志表重命名是合法的操作。
USE mysql;
DROP TABLE IF EXISTS general_log2;
CREATE TABLE general_log2 LIKE general_log;
RENAME TABLE general_log TO general_log_backup, general_log2 TO general_log;
- check table 是合法的操作。
CHECK TABLE general_log;
- LOCK TABLES 不可用的。
- INSERT,DELETE AND UPDATE 不能用于LOG表。这些操作只被服务自己允许。
- FLUSH TABLES WITH READ LOCK 和 READ_ONLY 系统变量状态 对日志表没有影响。服务端可以永远写入日志表。
- 实体被写入日志表不会写入二进制文件中，因此不能被从节点复制。
- 刷新日志表或者日志文件，分别使用FLUSH TABLES 或者 FLUSH LOGS .
- 日志表不能做分区。
- mysqldump dump文件包括脚本，可以用于重建表，所以在重载dump文件后不会出现丢失，但是log表不允许dump;
mysqldump -d mysql -uroot -pPASSWD --tables general_log slow_log > log.sql
3.1错误日志
讨论如何配置MySQL服务日志，判断错误日志信息。错误信息记录包括mysqld启动或者关闭，也包括诊断信息如错误，警告或者服务启动关闭阶段的Ntote信息。如果mysqld注意到一个表需要自动检测或者修复，会写消息到错误日志中。在一些操作系统中，如果mysqld异常退出，错误信息包括堆栈信息。这些信息用于决定mysqld何处退出。
3.1windows错误日志
windows系统中，mysqld使用--log-error,--pid-file,--console选项决定mysqld把错误信息写到控制台，或者文件。
- 如果使用--console，myqld写错误信息到控制台。如果同时使用--console,--log-error,--console优先于--log-error。在5.7之前的版本中，--log-error优先于--console。
- 如果没有使用--log-error,也没有给出文件名。mysqld 把错误信息写入到host_name.err文件中，在数据文件夹下。除非指明--pid-file。在这种情况下，pid文件名称是错误日志的前缀。
- 如果使用--log-error指定文件名，mysqld写错误日志到此文件中，位置在数据文件夹下，除非指定绝对路径。
3.2Unix系统错误日志
在unix系统中，mysqld使用--log-error选项决定是否将错误日志写到控制台或者文件中。
- 如果--log-error没有设置，mysqld将错误日志写到控制台。
- 如果提供--log-error，没有指定文件名，那么myqld将错误信息写到host_name.err文件，在data数据文件夹下。
- 如果提供--log-error并有文件名，mysqld将错误信息写到文件中，如果没有提供.err后缀，mysql后自动补充，在数据文件夹下。除非执行绝对路径名。
3.3系统日志错误信息
- log_syslog:打开此变量，发送错误日志到系统日志中。Windows默认打开。如果打开，以下系统变量也可用于更精细的控制。
- log_syslog_facility：默认的设备syslog消息是守护。
- log_syslog_include_pid:在每一行的syslog输出中，是否包括服务进程ID。
- log_syslog_tag:这个变量定义标签添加到服务ID在syslog消息。
在unix或者类似unix系统中，syslog控制输出也使用mysqld_safe，他可以捕获服务端错误输出并把错误信息发送给syslog.
3.4错误日志过滤
log_error_verbosity 系统变量控制服务冗余写错误信息，警告信息，通知信息。被准许的值是
- 1.只记录错误信息。
- 2.错误和警告信息。
- 3.错误警告通知消息
默认值是3，如果值超过3，服务端记录连接中断及连接拒绝错误。
3.5错误日志消息格式
错误日志中的ID是mysqld中负责写消息的线程ID。它指明服务端某一分部产生日志，这和常规日志及慢日志消息有一致性，其包括线程ID。log_timestamps 系统变量控制写入到日志的消息的时间格式。取值UTC(默认) 或者SYSTEM（本地系统时间区域）。
3.6错误日志文件刷新和重命名
如果要刷新错误日志使用flush error logs ，flush logs 或者 mysqladmin flush-logs，服务端关闭并且重新打开同一错误日志文件。刷新一个文件并重新生成同名的文件。
mv WenjiedeMacBook-Pro.local.err WenjiedeMacBook-Pro.local.err.old
mysqladmin -uroot -pduwenjie flush-logs;
如果错误日志所在的文件夹，服务器没有写权限，flush-logs操作会出现创建文件失败。
4常规查询日志
常规日志通常记录mysqld的操作。服务端写的信息当客户端连接或者断开连接，或者客户端接收到的sql脚本。常规查询日志在客户端错误和查询客户端发送脚本时有非常大的用处。
Time Id Command Argument 2020-04-05T09:55:23.896893Z 2 Query show tables 2020-04-05T09:55:40.779103Z 2 Query select * from fcm_bank_amount_ipt 2020-04-05T09:55:55.011581Z 2 Query select * from mysql.general_log 2020-04-05T09:57:19.064716Z 2 Query show variables like '%log_output%'
mysqld按照接受顺序将语句写入到查询日志中，可能会和客户端执行执行的有些不同。查询日志有序和二进制做个对比，二进制日志脚本在语句执行后在锁释放之前。常规日志只记录查询语句并且不会写入到二进制文件中。
当主节点使用基于statement二进制日志文件时，从服务器接受语句并将其写到查询日志中。如果客户端使用mysqlbinlog功能，并将语句传递给服务端，那么语句会被写入到主服务器的查询日志中。
当使用基于row二进制日志时，更新行被发送而不是sql语句，因此语句不会被写入到查询日志中，当binlog_format=ROW(默认值)。当binlog_format=MAIXED时，更新行可能不会写入到查询日志中，因为statement 作用。
set @@global.general_log = ON;#打开 set @@global.general_log = 0;#关闭
为关闭或者打开查询日志记录当前会话，设置sql_log_off = ON | OFF（前提是general_log = ON|1）.
密码会记录到查询日志中，同时会被服务端重写，不会出现明文。密码改写可以禁止，通过使用--log-raw选项。这个选项对诊断意图，收到的确切查询脚本是非常有用的，但是不推荐使用。
5二进制日志
二进制日志事件描述数据库的变化，例如创建表操作或者表数据修改。也包括语句事件，可能造成数据改变（如，没有匹配到任意行的删除操作），除非使用基于row模式（不会记录这些事件）。二进制日志也包括每条语句执行修改花费的时间。二进制文件的两个主要用途：
- 集群，集群主服务上的二进制文件记录数据的改变，发送到从节点。主服务发送包含事件的二进制文件给从节点，从节点执行这些事件。
- 确保数据恢复。在备份文件被存储后，二进制文件记录的事件需要被重新执行，这些事件是数据库从备份点开始更新。
二进制文件不保存不修改数据的操作，如select 或者 show。开启二进制日志的服务性能明显变慢，但是，二进制的好处是组建集群，同时从恢复操作来说，性能的降低的比重是很小的，可以忽略的。二进制文件会改写密码。
开启二进制日志，使用--log-bin=[base_name]启动服务，如果base_bane没有提供，默认名称是--pid-file设置的值，再跟上-bin。如果提供base_name，服务在数据文件夹路径下写文件，除非指定绝对路径。提倡指定base_name，而不是使用默认主机名称。
#sudo vi /etc/my.cnf
log-bin=mysql-bin
#/usr/local/mysql/data
如果提供扩展名，会被移除，忽略（--log-bin=base_name.extension）。mysqld在生成二进制文件，文件名是base_name加上数字型扩展名。数字递增在服务生成一个新文件时，因此创建有序的文件。服务在下面的事情发生时创建新文件：
- 服务启动或者重启
- 服务刷新日志
- 当前日志文件达到max_binlog_size设置值。
如果客户使用大事务，事务只会被写入到一个地方，不是分到两个文件，二进制文件可能会比max_binlog_size大。为了跟踪哪些二进制文件被使用，mysqld创建二进制索引文件，包含二进制文件名字。默认情况下，命名为base_name.index。使用--log-bin-index选项，可以改变二进制索引文件名称。在mysqld运行期间，不能手动手改此文件，这样做会使mysqld困惑。客户端如果有足够的权限可以关闭会话打印到二进制日志中，通过设置sql_log_bin=OFF|0。
默认情况下，服务端记录事件的长度用户校验事件写的正确性。你可以通过设置binlog_checksum系统变量来引导服务为事件写校验码。当读bin log备份时，主节点默认通过事件的长度，可以通过系统变量master_verify_checksum制造校验码。从节点的I/O线程也校验从主节点接受的二进制文件。你可以引导从节点SQL线程使用校验码验证中继日志通过设置slave_sql_verify_checksum系统变量。
二进制支持三种记录模式：
- 基于row
- 基于statement.
- 基于mixed。
集群从节点默认情况下自己不写关于任何数据修改二进制文件，只从主节点接受。为了记录这些修改，启动从节点时配置--log-slave-updates及--log-bin选项，在复制链中，从节点这么做像主节点一样。
reset master 以及 purge binary logs可以删除bin log。如果启动集群，待删除的二进制文件应该等到没有从节点使用时才能进行删除。例如，从节点不再落后三天，一天在主节点执行mysqladmin flush-logs，并且移除任何超过三天的日志。你可以手动的删除，但是倾向于使用 purge binary logs,除了清除日志，也会更新bin log 的索引文件。
mysqlbinlog 工具 展示二进制文件内容，在恢复操作中非常有用。mysqlbinlog 也可以展示从节点的中继日志，因为中继日志和二进制日志有相同的格式。
mysqlbinlog mysql-bin.000006
二进制日志在语句或者事务完成时后开始写，但是在任何锁释放或者任何事务提交前。这确保日志按照有序事务提交记录。非事务表更新操作在执行后立马被记录。在一个未提交的事务内，如innodb 事务表的所有的更新操作都被缓存直到从服务端接受到commit语句，与此同时，mysqld在commit 执行前，将完成的事务写入到二进制日志中（文件）。非事务表的修改操作不能进行回滚，如果回滚事务包含非回滚事务表的修改，在完整事务记录的尾部添加rollback 语句，用来确保复制这些表的修改。
当一个线程开始处理事务，分配缓存(binlog_cache_size=32k)去缓存语句，如果语句大于binlog_cache_size的大小，线程打开临时文件存储这个事务，在线程执行完成后会删除临时文件。Binlog_cache_use 状态变量显示事务的数据，这些事务使用缓存储存语句。Binlog_cache_disk_use状态变量显示实际有多少事务使用临时文件。这两个变量可以用来调整binlog_cache_size到足够大，避免使用临时文件。
show status like '%Binlog_cache%'; +-----------------------+-------+ | Variable_name | Value | +-----------------------+-------+ | Binlog_cache_disk_use | 0 | | Binlog_cache_use | 0 | +-----------------------+-------+ 2 rows in set (0.00 sec)
max_binlog_cache_size系统变量用来限制多语句事务缓存的大小。如果事务大于max_binlog_cache_size,操作失败，事务回滚。
max_binlog_cache_size=18446744073709547520
如果使用基于row格式的二进制日志，并发插入会转化为普通的插入，CREATE...SELECT 或者 INSERT ...SELECT 语句，这么做是为了确保你在备案操作期间可以使用日志重建精确的表拷贝。如果你使用基于statement格式日志，原始语句会被写入到二进制日志中。
如果MySQL服务不能写二进制日志，刷新二进制文件，或者同步二进制缓存到硬盘，那么集群主节点的二进制日志就会不一致，备份节点和主节点丧失一致性。binlog_error_action系统变量控制二进制日志错误行为。
- 默认设置ABORT_SERVER，服务终端二进制记录并且关闭服务。在这个时间点上，你可以诊断，改正错误的原因。重启。
- IGNORE_ERROR,这个设置向后兼容老版本mysql。通过这个设定，服务端继续执行事务，记录错误信息，暂停二进制日志记录，但是继续更新做操。这个时刻，可以诊断，改正错误。为重启二进制日志，log-bin必须再次开启，服务重新启动，如果你想向后兼容，只能用这个设置，二进制日志对于mysql服务实例是非必须的。例如，你可能只需要二进制文件作为审计或者排查服务端，不会用于集群复制或者依赖二进制文件执行时间点还原操作。
默认情况下，服务每次写后二进制日志从缓存同步到硬盘中(sync_binlog=1)。如果sync_binlog 没有开启，操作系统或者机器崩溃，最后一条二进制日志语句会丢失。打开sync_binlog系统变量同步二进制日志缓存到硬盘中，N条commited语句一起提交（sync_binlog=N）。sync_binlog=1是最安全的值，但是效率最低。
例如，使用InnoDB表，MySQL服务处理commited语句，服务有序的写已经准备好的事务到二进制日志，同步二进制日志，提交事务到InnoDB。如果在这两步之间服务崩溃，在服务重启时，InnoDB事务回滚，但是二进制日志继续保存。这个问题已经解决，假如innodb_support_xa=1（默认值）。尽管这个选项与InnoDB中对XA事务的支持有关，这个选项也能确保二进制日志和InnoDB数据文件之间的同步。这个选项提供更高安全等级，配置MySQL服务,在提交事务前，将bin log 和 InnoDB日志刷新到磁盘上。InnoDB默认是同步的，sync_bin_log=1用于二进制日志同步。这个选项的作用，在服务崩溃后重启，事务回滚之后，MySQL扫描最新的二进制日志文件收集事务xid值，计算二进制日志最终有效位置。MySQL服务告诉InnoDB完成所有已经准备好，成功写入二进制日志的事务，根据最终的有效位置截断二进制日志文件。这个确保二进制日志反映精确的innodb表数据，并且备份节点和主节点保持同步，因为没收到的语句已经被回滚。
NOTE: innodb_support_xa将会在之后的版本中被丢弃，InnoDB支持XA事务两阶段提交， innodb_support_xa默认开启的。
如果MySQL发现容灾恢复，二进制文件有效的长度短，缺少最后一个成功的InnoDB事务。如果sync_binlog=1和磁盘/文件系统在请求时执行实际同步（有些不执行），则不应发生这种情况。服务端打印错误信息，二进制文件 file_name比期望的短。这种情况下，二进制文件是不正确的，集群从主节点数据某一个新快照点重启。
5.1二进制日志格式
MySQL支持三种日志格式：
- MySQL原始集群能力依赖于SQL语句从主节点传播到备份节点。这种方式称为基于statement日志记录，你可以在服务启动时使用--binlog-format=STATEMENT使用这种格式。
- 基于row日志记录，主节点在二进制文件中写入事件，表明如何影响表中记录行。因此，这是十分重要的，表使用主键确保行记录可以有效的发现。在服务启动时使用--binlog-format=row使用这种格式。
- 第三种选项maxed 日志格式。在这种日志格式下，基于statement默认被使用，但是日志格式模式会自动转换为基于row在必须要的情况下。在服务启动是可以使用--binlog-format=MOIXED.
基于statement在集群复制中，具有不确定性，会导致
Statement may not be safe to log in statement format.
使用基于row日志格式来解决这些问题。
5.2设置二进制日志格式
可以在服务启动时设置--binlog_format=type,type=[STATEMENT,ROW,MIXED]
日志格式在运行时也可以设置
set @@global.binlog_format=ROW; set @@global.binlog_format=MIXED; set @@global.binlog_format=STATEMENT;
客户端也可以设置会话级别的日志格式
set session binlog_format=STATEMENT; SET SESSION binlog_format = 'ROW'; SET SESSION binlog_format = 'MIXED';
二进制日志缓存设置的几个理由：
- 会话如果设置基于row日志记录，对数据来说，改变比较小。
- 会话更新操作，使用where子句匹配到很多行记录，可能使用基于statement日志格式，因为记录很少的语句比记录很多行数据更高效。
- 有些语句需要大量的执行时间，但是最终只修改很少的数据行，因此可能使用基于row日志格式更高效。
运行时，不能调整集群模式时，会出现异常：
- 存储函数或者触发器。
- NDB存储引擎开启。
- 如果会话正使用基于row日志格式复制模式，同时已打开临时表
在这几种情况下转换日志模式都会导致错误。
当有任何临时表时，不提倡MySQL调整复制格式，因为只有使用基于statement日志日志复制模式，临时表才会被记录，使用基于row日志格式，不会被记录。在MIXED模式下，临时表通常是被记录的；使用自定义函数或者uuid函数会出现异常。
在进行复制时，转换复制模式会导致问题。每个MySQL服务可以设置且只能设置自己的日志格式（无论binlog_format设置全局或者会话级别）。主节点修改日志格式不会导致备份节点修改日志格式。当使用statement模式，binlog_format系统变量不会被复制的。当使用mixed或者row日志模式，会被复制，但是会被备份节点忽视。
备份节点从主节点接受二进制日志，备份节点二进制日志不能将从主节点接受的二进制日志从row日志格式转换为statement格式。因此备份节点必须使用row或者mixed格式如果主节点使用statements。将主节点二进制文件格式从statement修改为row或者mixed同时本分节点使用statement进行复制会导致集群复制失败，如下面的异常：
Error executing row event: 'Cannot execute statement: impossible to write to binary log since statement is in row format and BINLOG_FORMAT = STATEMENT.'
备份节点将二进制日志格式修改为statement当主节点使用mixed或者row格式时也会导致复制错误。为保证格式变更安全性，必须停止集群，确保主节点和备份节点做了相同的改变。
如果使用InnoDB表，事务隔离级别是read_commited或者read_uncommited，只能使用row模式。允许修改日志格式为statement,但是在运行时这么做会直接造成错误，因为Innodb不能执行inserts。
当二进制文件格式使用row,很多修改写入日志使用基于row日志格式，一些修改，仍然使用基于statement格式，包括DDL（Date definatiion language）语句如create table,alter table,or drop table。
--binlog-row-event-max-size选项提供基于row复制的能力。行以字节为单位存储在二进制日志块中，其大小不超过此选项的值。该值必须是256的倍数。默认值为8192。
警告
当使用基于statement 日志格式，可能导致主节点和备份节点的不一致性，如果在有些场景下， 数据修改的不确定性。
5.3Mixed 二进制日志格式
当使用mixed格式，服务端在下面的情况下从statement 自动转换到row格式：
- 当函数包括uuid().
- 当一个或者多个表自增长列被更新，触发或者存储函数调用。像其他所有不安全的语句，如果使用binlog_format=STATEMENT会产生警告⚠️。
- 当试图主体需要基于row复制，语句创建试图并使用。例如，当语句创建试图并调用uuid()函数。
- 当调用用户自定义函数时。
- 如果基于row模式记录语句，执行该语句的会话包括任何临时表，随后的任何语句（除了访问临时表语句）会基于row记录直到临时表被会话删除。无论是否任何临时表被记录着都是正确的。基于row格式不能记录临时表，因此，一旦基于row日志格式被使用，所有后续语句使用临时表都是不安全的。
- 当使用found_rows()或者row_count()。
- 当使用user(),current_user(),current_user 。
- 当下面一个或者多个系统变量被使用
例如，当与会话作用域（仅）一起使用时，以下系统变量不会导致日志格式切换：
auto_increment_increment
auto_increment_offset
character_set_client
character_set_connection
character_set_database
character_set_server
collation_connection
collation_database
collation_server
foreign_key_checks
identity
last_insert_id
lc_time_names
pseudo_thread_id
sql_auto_is_null
time_zone
timestamp
unique_checks
- 当涉及到表之一是mysql数据库的日志表。general_log ,slow_log。
- 当使用 load_file()函数。
如果语句本该使用row日志格式，但是使用statement日志格式，会生成警告信息。这部分信息不仅在客户端显示，也会记录在mysqld错误日志。
除了上面讨论的，个别的引擎也可以决定日志格式当表中信息被修改。单个引擎日志能力被定义如下：
- 如果一个引擎支持基于row日志格式，那么可以说这个引擎row日志能力。
- 如果一个引擎支持基于statement日志，那么可以说这个引擎具有statement日志能力。
一个存储引擎可以支持一个或者多个日志格式。下面列表显示每个引擎的的支持能力、
|
Storage Engine
|
Row Logging Supported
|
Statement Logging Supported
|
|
ARCHIVE
|
Yes
|
Yes
|
|
BLACKHOLE
|
Yes
|
Yes
|
|
CSV
|
Yes
|
Yes
|
|
EXAMPLE
|
Yes
|
No
|
|
FEDERATED
|
Yes
|
Yes
|
|
HEAP
|
Yes
|
Yes
|
|
InnoDB
|
Yes
|
Yes 只用隔离级别是rr 或者serializable。
|
|
MyISAM
|
Yes
|
Yes
|
|
MERGE
|
Yes
|
Yes
|
|
Yes
|
No
|
语句类型(safe,unsafe,binary injected),二进制日志格式(statement,row,mixed)，存储引擎日志能力（statement capable,row capable,both,neither)。（二进制注入是指记录必须使用行格式记录的更改）。
Type,binlog_format,slc,rlc 环境，error/warning，logged as 展示响应的动作。slc 支持语句日志记录，rlc支持行日志记录。
|
Type
|
SLC
|
RLC
|
Error / Warning
|
Logged as
|
|
|
*
|
*
|
No
|
No
|
Error: Cannot execute statement: Binary logging is impossible since at least one engine is involved that is both row-incapable and statement-incapable.
|
-
|
|
Safe
|
STATEMENT
|
Yes
|
No
|
-
|
STATEMENT
|
|
Safe
|
MIXED
|
Yes
|
No
|
-
|
STATEMENT
|
|
Safe
|
ROW
|
Yes
|
No
|
Error: Cannot execute statement: Binary logging is impossible since BINLOG_FORMAT = ROW and at least one table uses a storage engine that is not capable of row-based logging.
|
-
|
|
Unsafe
|
STATEMENT
|
Yes
|
No
|
Warning: Unsafe statement binlogged in statement format, since BINLOG_FORMAT = STATEMENT
|
STATEMENT
|
|
Unsafe
|
MIXED
|
Yes
|
No
|
Error: Cannot execute statement: Binary logging of an unsafe statement is impossible when the storage engine is limited to statement-based logging, even if BINLOG_FORMAT = MIXED.
|
-
|
|
Unsafe
|
ROW
|
Yes
|
No
|
Error: Cannot execute statement: Binary logging is impossible since BINLOG_FORMAT = ROW and at least one table uses a storage engine that is not capable of row-based logging.
|
-
|
|
Row Injection
|
STATEMENT
|
Yes
|
No
|
Error: Cannot execute row injection: Binary logging is not possible since at least one table uses a storage engine that is not capable of row-based logging.
|
-
|
|
Row Injection
|
MIXED
|
Yes
|
No
|
Error: Cannot execute row injection: Binary logging is not possible since at least one table uses a storage engine that is not capable of row-based logging.
|
-
|
|
Row Injection
|
ROW
|
Yes
|
No
|
Error: Cannot execute row injection: Binary logging is not possible since at least one table uses a storage engine that is not capable of row-based logging.
|
-
|
|
Safe
|
STATEMENT
|
No
|
Yes
|
Error: Cannot execute statement: Binary logging is impossible since BINLOG_FORMAT = STATEMENT and at least one table uses a storage engine that is not capable of statement-based logging.
|
-
|
|
Safe
|
MIXED
|
No
|
Yes
|
-
|
ROW
|
|
Safe
|
ROW
|
No
|
Yes
|
-
|
ROW
|
|
Unsafe
|
STATEMENT
|
No
|
Yes
|
Error: Cannot execute statement: Binary logging is impossible since BINLOG_FORMAT = STATEMENT and at least one table uses a storage engine that is not capable of statement-based logging.
|
-
|
|
Unsafe
|
MIXED
|
No
|
Yes
|
-
|
ROW
|
|
Unsafe
|
ROW
|
No
|
Yes
|
-
|
ROW
|
|
Row Injection
|
STATEMENT
|
No
|
Yes
|
Error: Cannot execute row injection: Binary logging is not possible since BINLOG_FORMAT = STATEMENT.
|
-
|
|
Row Injection
|
MIXED
|
No
|
Yes
|
-
|
ROW
|
|
Row Injection
|
ROW
|
No
|
Yes
|
-
|
ROW
|
|
Safe
|
STATEMENT
|
Yes
|
Yes
|
-
|
STATEMENT
|
|
Safe
|
MIXED
|
Yes
|
Yes
|
-
|
STATEMENT
|
|
Safe
|
ROW
|
Yes
|
Yes
|
-
|
ROW
|
|
Unsafe
|
STATEMENT
|
Yes
|
Yes
|
Warning: Unsafe statement binlogged in statement format since BINLOG_FORMAT = STATEMENT.
|
STATEMENT
|
|
Unsafe
|
MIXED
|
Yes
|
Yes
|
-
|
ROW
|
|
Unsafe
|
ROW
|
Yes
|
Yes
|
-
|
ROW
|
|
Row Injection
|
STATEMENT
|
Yes
|
Yes
|
Error: Cannot execute row injection: Binary logging is not possible because BINLOG_FORMAT = STATEMENT.
|
-
|
|
Row Injection
|
MIXED
|
Yes
|
Yes
|
-
|
ROW
|
|
Row Injection
|
ROW
|
Yes
|
Yes
|
-
|
ROW
|
查询异常信息
SHOW WARNINGS;
5.4日志记录格式变化对于mysql库中的表
mysql库授权表内容的内容可以直接修改（insert or delete）或者非直接修改（grant,create_user）。
- 直接修改mysql库表数据的数据操作语句，根据binlog_format系统变量设置被记录。例如：insert ,update,delete,replace,do,load_date,select ,truncate table。
- 间接修改表数据的语句忽略binlog_format设置。这包括:GRANT, REVOKE, SET PASSWORD, RENAME USER, CREATE (all forms except CREATE TABLE ... SELECT), ALTER (all forms), and DROP (all forms).
create table 。。。 select 结合数据定义和数据操作,create table 部分使用基于statement日志记录，select 部分通过binlog_format被日志记录。
6慢查询日志
慢查询日志包是指执行时间超过long_query_time值SQL语句并且检查至少min_examined_row_limit行数据。
6.1慢查询日志参数
- long_query_time 默认值是10，最小值是0，可以自定义长时间查询的阀值。
- slow_query_log 打开或者关闭慢日志。0|1.
- slow_query_log_file 慢日志文件，可以不指定或者指定文件名或者指定绝对路径。
- log_slow_admin_statements 开启或者关闭管理员语句。默认关闭。如 ALTER TABLE, ANALYZE TABLE, CHECK TABLE, CREATE INDEX, DROP INDEX, OPTIMIZE TABLE, and REPAIR TABLE.
- log_queries_not_using_indexes 开启或者关闭查询未走索引行的语句，默认关闭。
- log_throttle_queries_not_using_indexes ,当log_queries_not_using_indexes开启时，慢查询日志会增长的很快，可以通过该变量的进行限制。默认值是0.
默认情况下，备份节点不会将复制查询写到慢日志中。为改变这种情况，开启log_slow_slave_statements 系统变量。注意：如果binlog_format=row,log_slow_slave_statements是无效的。查询日志添加到备份节点的慢查询日志，binlog_format=statement或者MIXED。
6.2慢日志内容
- query_time : 语句执行时间 秒
- lock_time 语句获取锁时间 秒
- rows_sent:发送给客户端的条数
- rows_examined 服务端校验的条数
每条语句执行然后才会被记录到日志中。
7服务日志保存
expireLogs_days 系统变量设置二进制文件超时时间。如果在集群复制时，时间要大于主备异步的时间差。为清除二进制日志，使用 purge binary logs。
强制MySQL服务使用新文件，刷新日志。日志刷新执行flush logs语句或者mysqladmin flush-logs,mysqladmin refresh,mysqldump --flush-logs,或者mysql --master-data.除此之外，服务自动刷新二进制日志当当前二进制文件大小达到max_binlog_size。
flush logs 支持修改单独的日志文件 如 flush binary logs。
日志刷新有下面的影响：
- 如果二进制日志开启，服务端关闭二进制文件，创建新的文件会用序列号码。
- 如果常规日志或者慢查询日志开启，服务关闭和再开打日志文件。
- 如果启动时使用--log-error选项，服务关闭和再打开日志文件。
