mysql开启binlog日志

mysqlbinlog 是将 binlog 解析成可读可执行的 SQL 的重要工具。

但解析体积较大的 binlog 时，如何查看 mysqlbinlog 的执行进度就变成了一个问题，mysqlbinlog 并未提供 –progress 这样的参数。

那要怎么查看 mysqlbinlog 的解析进度？

实验

我们在 实验 08 中介绍了如何生成随机数据。可以利用其中技巧，生成较大的 binlog，我们忽略这个过程。

从已有的 binlog 开始，bin000002 大约有 11 个 G：

用 mysqlbinlog 解析该 binlog：

大概会执行 46 秒左右。大家仔细做实验时，可以将 binlog 放大一些，让执行实验更长一些。

我们在 mysqlbinlog 解析时，查看其文件句柄：

可以看到 mysqlbinlog 用句柄 3 读取 binlog。（我们暂时忽略句柄 4 指向的临时文件，其涉及到了行格式的解析过程，我们安排在以后的实验中慢慢介绍）

获取了 mysqlbinlog 处理文件句柄 3 的进度，就可以大概估算 mysqlbinlog 的整体进度：

可以看到 mysqlbinlog 此时的进度大概是 600M 左右，整体进度估算为 54%。

结论

我们无法让 mysqlbinlog 直接输出进度，于是通过观察 mysqlbinlog 对 binlog 的读取进度，估算mysqlbinlog 的整体处理进度。

这个你可以看配置文件 启用了才有这样的记录默认是没有的

/etc/myconf

log-bin = mysqlbin

一般放在/var/lib/mysql

比如上面的设置重启数据库会生成mysqlbin000001文件

简介：

Linux *** 作系统是基于UNIX *** 作系统发展而来的一种克隆系统，它诞生于1991 年的 [Linux桌面] 10 月5 日（这是第一次正式向外公布的时间）。以后借助于Internet网络，并通过全世界各地计算机爱好者的共同努力，已成为今天世界上使用最多的一种UNIX 类 *** 作系统，并且使用人数还在迅猛增长。

Linux是一套免费使用和自由传播的类Unix *** 作系统，是一个基于POSIX和UNIX的多用户、多任务、支持多线程和多CPU的 *** 作系统。它能运行主要的UNIX工具软件、应用程序和网络协议。它支持32位和64位硬件。Linux继承了Unix以网络为核心的设计思想，是一个性能稳定的多用户网络 *** 作系统。它主要用于基于Intel x86系列CPU的计算机上。这个系统是由全世界各地的成千上万的程序员设计和实现的。其目的是建立不受任何商品化软件的版权制约的、全世界都能自由使用的Unix兼容产品。

Linux以它的高效性和灵活性著称，Linux模块化的设计结构，使得它既能在价格昂贵的工作站上运行，也能够在廉价的PC机上实现全部的Unix特性，具有多任务、多用户的能力。Linux是在GNU公共许可权限下免费获得的，是一个符合POSIX标准的 *** 作系统。Linux *** 作系统软件包不仅包括完整的Linux *** 作系统，而且还包括了文本编辑器、高级语言编译器等应用软件。它还包括带有多个窗口管理器的X-Windows图形用户界面，如同我们使用Windows NT一样，允许我们使用窗口、图标和菜单对系统进行 *** 作。

当启动Binlog后，事务会产生Binlog Event，这些Event被看做事务数据的一部分。因此要保证事务的Binlog Event和InnoDB引擎中的数据的一致性。所以带Binlog的CrashSafe要求MySQL宕机重启后能够保证：

- 所有已经提交的事务的数据仍然存在。

- 所有没有提交的事务的数据自动回滚。

- 所有已经提交了的事务的Binlog Event也仍然存在。

- 所有没有提交事务没有记录Binlog Event。

这些要求很好理解，如果重启后数据还在，但是Binlog Event没有了，就没办法复制到其他节点上了。如果重启后，数据没了，但是Binlog Event还在，那么不存在的数据就会被复制到其他节点上，从而导致主从的不一致。

为了保证带Binlog的CrashSafe，MySQL内部使用的两阶段提交(Two Phase Commit)。

2 - MySQL的Two Phase Commit(2PC)

在开启Binlog后，MySQL内部会自动将普通事务当做一个XA事务来处理：

- 自动为每个事务分配一个唯一的ID

- COMMIT会被自动的分成Prepare和Commit两个阶段。

- Binlog会被当做事务协调者(Transaction Coordinator)，Binlog Event会被当做协调者日志。

想了解2PC，可以参考文档：

主备binlog文件下标是指MySQL中binlog文件的主从复制状态。主备binlog文件下标是一个数字，它表示MySQL主服务器上binlog文件的当前位置，从服务器上的binlog文件下标也是一个数字，它表示从服务器上binlog文件的当前位置。主备binlog文件下标的作用是，当MySQL主从复制过程中出现故障时，可以通过比较主从服务器上binlog文件下标的值来确定哪些数据没有被复制到从服务器上，从而可以快速恢复数据。

Binlog基本配制与格式设定

1基本配制

Mysql BInlog日志格式可以通过mysql的mycnf文件的属性binlog_format指定。如以下：

binlog_format = MIXED //binlog日志格式

log_bin =目录/mysql-binlog //binlog日志名

expire_logs_days = 7 //binlog过期清理时间

max_binlog_size 100m //binlog每个日志文件大小

2Binlog日志格式选择

Mysql默认是使用Statement日志格式，推荐使用MIXED

由于一些特殊使用，可以考虑使用ROWED，如自己通过binlog日志来同步数据的修改，这样会节省很多相关 *** 作。对于binlog数据处理会变得非常轻松,相对mixed，解析也会很轻松(当然前提是增加的日志量所带来的IO开销在容忍的范围内即可)。

3mysqlbinlog格式选择

mysql对于日志格式的选定原则:如果是采用 INSERT，UPDATE，DELETE 等直接 *** 作表的情况，则日志格式根据 binlog_format 的设定而记录,如果是采用 GRANT，REVOKE，SET PASSWORD 等管理语句来做的话，那么无论如何 都采用 SBR 模式记录 《Linux就该这么学》一起学习linux

4Mixed日志说明：

在slave日志同步过程中，对于使用now这样的时间函数，MIXED日志格式，会在日志中产生对应的unix_timestamp()1000的时间字符串，slave在完成同步时，取用的是sqlEvent发生的时间来保证数据的准确性。另外对于一些功能性函数slave能完成相应的数据同步，而对于上面指定的一些类似于UDF函数，导致Slave无法知晓的情况，则会采用ROW格式存储这些Binlog，以保证产生的Binlog可以供Slave完成数据同步。

以上就是关于mysql开启binlog日志全部的内容，包括:mysql开启binlog日志、linux 怎么查看mysql 的binlog日志存放的位置、怎样打开查看mysql binlog等相关内容解答，如果想了解更多相关内容，可以关注我们，你们的支持是我们更新的动力！