a) 二进制日志由一些host-bin.000000形式文件组成,每个binlog文件以format_description事件开头,以日志轮换事件作为结尾。如果服务器停机日志末尾可能不是轮换事件而是stop事故。格式描述符事件主要是包含binlog的服务器信息,以及文件的状态关键字。Binlog文件中的事件都被分成组,如果是事务,那么本身就是一个组,如果非事务,那么一个语句就是一个组。
b) Binlog事件,在binlog format v4 中每个事件有3部分组成:通用头,提交头,事件体。通用头(common header):大小固定。事件的基本信息,其中重要的字段是事件类型和事件大小。提交头(post header):大小固定。提交头与特定的事件类型相关。事件体(Event body):大小可变。事件体存储事件的主要数据,因事件类型不同而异。
c) 二进制写入,因为在同一个服务器上有多个线程需要些二进制日志,所以他们必须获得lock_log锁,在表尚未释放锁之前,当语句提交的时候同时将该语句写入二进制日志。
d) 二进制日志过滤器,在master上可以配置记录那些数据库的的二进制日志,连个参数binlog-do-db及binlog-ignore-db,如果连个同时使用,只要有binglog-do-db存在,所有binlog-ignore-db将完全被忽略。建议是不要使用这两个选项,因为如果过滤掉二进制日志,在事件崩溃时,将无法从二进制日志恢复数据库。
e) 对于master上的存储过程,触发器,存储函数式写进二进制日志方法
1) 存储过程。对于存储过程写入二进制日志时,会隐式的加入definer,调用存储过程时call语句不会写入二进制,而是将调用语句的结果写入二进制日志,也就是将存储过程展开后写入二进制日志。对于存储过程的参数,在二进制日志中是使用NAME_CONST函数为每个参数创建一个单独的结果集。
2) 存储函数和触发器,存储函数也会隐式的将definer写入二进制日志,执行触发器的上下文信息也会被写入二进制。需要注意的是有个漏洞,在master上定义存储函数的权一般是create router.二在slave 上的io线程复制时不会进行权限检查。但是执行重现时会进行权限检查,这可能导致执行不一致。在存储函数定义时使用SQL SECURITY DEFINER而不是SQL SECURITY INVOKER可以防止这一点。因为这一点的考虑,MySQL默认要求SUPER权限来定义存储函数。调用触发器的语句被记录入二进制,但是没有连接到特定的触发器,在slave 上执行到该语句时,他会寻找与该表关联的其他触发器达到触发母的。所以可以在master和slave上调用不同的触发器。
f) 事件events,事件在主服务器上调度的,它也有definer,但是总是被 定义者执行。当事件执行时,他们被自动写入二进制日志,但是在slave上是禁止的,如果要在slave 上执行需要在master上执行:
UPDATE mysql.events vSET status = ENABLED WHERE status = SLAVESIDE_DISABLED;
g) 对于load data in file 需要引入新的事件类型。在执行过程中会分配一个唯一的文件id 供该执行语句。
h) 二进制日志对事务性和非事务性语句的处理。
在事务性语句执行过程中,服务器将会进行额外的处理,在服务器执行时多个事务是并行执行的,为了把他们的记录在一起,需要引入事务缓存的概念。在事务完成被提交的时候一同刷新到二进制日志。对于非事务性语句的处理。遵循以下3条规则:
1) 如果非事务性语句被标记为事务性,那么将被写入事务缓冲。
2) 如果没有标记为事务性语句,而且事务缓存中没有,那么直接写入二进制日志。
3) 如果没有标记为事务性的,但是事务缓存中有,那么写入事务缓冲。
注意如果在一个事务中有非事务性语句,那么将会利用规则2,优先将该影响非事务表语句直接写入二进制日志。
i) 二进制日志安全和系统崩溃。
对于事务性存储引擎而言是安全的,因为在事务释放锁之前会将二进制日志刷新到磁盘(可以通过sync-binlog设置刷新时间),但是对于非事务存储引擎而言,有可能在数据完成修改,但是没有写二进制日志。
j) Binlog文件轮换。导致轮换的事件主要有4种:服务器停止、flush logs、日志被写满达到binlog-cache-size、服务器发生故障。
在服务器down机时,为了能使用二进制日志,二进制采用了预写策略。在临时文件里写明意图。预写文件基于索引文件命名,当生成新的二进制文件并完成索引更新后会删除预写文件。
K)清除二进制日志由3种方式:
设置—expire-logs-days
Purge binary logs before datedime
Purge binary logs to ‘filename’
再删除之前,系统会先将要删除的文件预写到一个索引文件,当正式的删除文件后将该索引文件删除,如果宕机,那么在启动时继续执行预写的文件。
b) Binlog事件,在binlog format v4 中每个事件有3部分组成:通用头,提交头,事件体。通用头(common header):大小固定。事件的基本信息,其中重要的字段是事件类型和事件大小。提交头(post header):大小固定。提交头与特定的事件类型相关。事件体(Event body):大小可变。事件体存储事件的主要数据,因事件类型不同而异。
c) 二进制写入,因为在同一个服务器上有多个线程需要些二进制日志,所以他们必须获得lock_log锁,在表尚未释放锁之前,当语句提交的时候同时将该语句写入二进制日志。
d) 二进制日志过滤器,在master上可以配置记录那些数据库的的二进制日志,连个参数binlog-do-db及binlog-ignore-db,如果连个同时使用,只要有binglog-do-db存在,所有binlog-ignore-db将完全被忽略。建议是不要使用这两个选项,因为如果过滤掉二进制日志,在事件崩溃时,将无法从二进制日志恢复数据库。
e) 对于master上的存储过程,触发器,存储函数式写进二进制日志方法
1) 存储过程。对于存储过程写入二进制日志时,会隐式的加入definer,调用存储过程时call语句不会写入二进制,而是将调用语句的结果写入二进制日志,也就是将存储过程展开后写入二进制日志。对于存储过程的参数,在二进制日志中是使用NAME_CONST函数为每个参数创建一个单独的结果集。
2) 存储函数和触发器,存储函数也会隐式的将definer写入二进制日志,执行触发器的上下文信息也会被写入二进制。需要注意的是有个漏洞,在master上定义存储函数的权一般是create router.二在slave 上的io线程复制时不会进行权限检查。但是执行重现时会进行权限检查,这可能导致执行不一致。在存储函数定义时使用SQL SECURITY DEFINER而不是SQL SECURITY INVOKER可以防止这一点。因为这一点的考虑,MySQL默认要求SUPER权限来定义存储函数。调用触发器的语句被记录入二进制,但是没有连接到特定的触发器,在slave 上执行到该语句时,他会寻找与该表关联的其他触发器达到触发母的。所以可以在master和slave上调用不同的触发器。
f) 事件events,事件在主服务器上调度的,它也有definer,但是总是被 定义者执行。当事件执行时,他们被自动写入二进制日志,但是在slave上是禁止的,如果要在slave 上执行需要在master上执行:
UPDATE mysql.events vSET status = ENABLED WHERE status = SLAVESIDE_DISABLED;
g) 对于load data in file 需要引入新的事件类型。在执行过程中会分配一个唯一的文件id 供该执行语句。
h) 二进制日志对事务性和非事务性语句的处理。
在事务性语句执行过程中,服务器将会进行额外的处理,在服务器执行时多个事务是并行执行的,为了把他们的记录在一起,需要引入事务缓存的概念。在事务完成被提交的时候一同刷新到二进制日志。对于非事务性语句的处理。遵循以下3条规则:
1) 如果非事务性语句被标记为事务性,那么将被写入事务缓冲。
2) 如果没有标记为事务性语句,而且事务缓存中没有,那么直接写入二进制日志。
3) 如果没有标记为事务性的,但是事务缓存中有,那么写入事务缓冲。
注意如果在一个事务中有非事务性语句,那么将会利用规则2,优先将该影响非事务表语句直接写入二进制日志。
i) 二进制日志安全和系统崩溃。
对于事务性存储引擎而言是安全的,因为在事务释放锁之前会将二进制日志刷新到磁盘(可以通过sync-binlog设置刷新时间),但是对于非事务存储引擎而言,有可能在数据完成修改,但是没有写二进制日志。
j) Binlog文件轮换。导致轮换的事件主要有4种:服务器停止、flush logs、日志被写满达到binlog-cache-size、服务器发生故障。
在服务器down机时,为了能使用二进制日志,二进制采用了预写策略。在临时文件里写明意图。预写文件基于索引文件命名,当生成新的二进制文件并完成索引更新后会删除预写文件。
K)清除二进制日志由3种方式:
设置—expire-logs-days
Purge binary logs before datedime
Purge binary logs to ‘filename’
再删除之前,系统会先将要删除的文件预写到一个索引文件,当正式的删除文件后将该索引文件删除,如果宕机,那么在启动时继续执行预写的文件。