前言：

我们都知道，binlog可以说是MySQL中比较重要的日志了，在日常学习及运维过程中，也经常会遇到。不清楚你对binlog了解多少呢？本篇文章将从binlog作用、binlog相关参数、解析binlog内容三个方面带你了解binlog。

1.binlog简介

binlog即binary log，二进制日志文件。它记录了数据库所有执行的DDL和DML语句（除了数据查询语句select、show等），以事件形式记录并保存在二进制文件中。

binlog主要有两个应用场景，一是用于复制，master把它的二进制日志传递给slaves来达到master-slave数据一致的目的。二是用于数据恢复，例如还原备份后，可以重新执行备份后新产生的binlog，使得数据库保持最新状态。除去这两个主要用途外，binlog可以用于异构系统之间数据的交互，binlog完整保存了一条记录的前项和后项记录，可以用DTS服务，将MySQL数据以准实时的方式抽取到底层数据平台，比如HBase、Hive、Spark等，打通OLTP和OLAP。

binlog日志可以选择三种模式，分别是 STATEMENT、 ROW、 MIXED，下面简单介绍下这三种模式：

• STATEMENT：基于SQL语句的复制，每一条会修改数据的sql语句会记录到binlog中。该模式下产生的binlog日志量会比较少，但可能导致主从数据不一致。
• ROW：基于行的复制，不记录每一条具体执行的SQL语句，仅需记录哪条数据被修改了，以及修改前后的样子。该模式下产生的binlog日志量会比较大，但优点是会非常清楚的记录下每一行数据修改的细节，主从复制不会出错。
• Mixed：混合模式复制，以上两种模式的混合使用，一般的复制使用STATEMENT模式保存binlog，对于STATEMENT模式无法复制的操作使用ROW模式保存binlog，MySQL会根据执行的SQL语句选择日志保存方式。

binlog模式在MySQL 5.7.7之前，默认为 STATEMENT，在之后的版本中，默认为ROW。这里建议采用ROW模式，因为ROW模式更安全，可以清楚记录每行数据修改的细节。

2.binlog相关参数

binlog默认情况下是不开启的，不过一般情况下，初始化的时候建议在配置文件中增加log-bin参数来开启binlog。

# 配置文件中增加log-bin配置 [mysqld] log-bin = binlog  # 不指定路径默认在data目录下，也可以指定路径 [mysqld] log-bin = /data/mysql/logs/binlog  # 查看数据库是否开启了binlog show variables like 'log_bin%'; 

开启binlog后，还需注意一些与binlog相关的参数，下面简单介绍下相关参数：

binlog_format

设置binlog模式，建议设为ROW。

binlog_do_db

此参数表示只记录指定数据库的二进制日志，默认全部记录，一般情况下不建议更改。

binlog_ignore_db

此参数表示不记录指定的数据库的二进制日志，同上，一般不显式指定。

expire_logs_days

此参数控制二进制日志文件保留天数，默认值为0，表示不自动删除，可设置为0~99。可根据实际情况设置，比如保留15天或30天。MySQL8.0版本可用binlog_expire_logs_seconds参数代替。

max_binlog_size

控制单个二进制日志大小，当前日志文件大小超过此变量时，执行切换动作。此参数的最大和默认值是1GB，该设置并不能严格控制Binlog的大小，尤其是Binlog比较靠近最大值而又遇到一个比较大事务时，为了保证事务的完整性，不可能做切换日志的动作，只能将该事务的所有SQL都记录进当前日志，直到事务结束。一般情况下可采取默认值。

log_bin_trust_function_creators

当二进制日志启用后，此参数就会启用。它控制是否可以信任存储函数创建者，不会创建写入二进制日志引起不安全事件的存储函数。如果设置为0（默认值），用户不得创建或修改存储函数，除非它们具有除CREATE ROUTINE或ALTER ROUTINE特权之外的SUPER权限。建议设置为1。

sync_binlog

控制MySQL服务端将二进制日志同步到磁盘的频率，默认值为1。设置为0，表示MySQL不控制binlog的刷新，由文件系统自己控制它的缓存的刷新；设置为1，表示每次事务提交，MySQL都会把binlog刷下去，这是最安全的设置，但由于磁盘写入次数增加，可能会对性能产生负面影响；设置为n，其中n为0或1以外的值，在进行n次事务提交以后，Mysql将执行一次fsync之类的磁盘同步指令，将Binlog文件缓存刷新到磁盘。推荐设置为1，出于性能考虑也可酌情调整。

关于binlog操作与管理相关的SQL也有很多，下面介绍下部分常用的语句：

3.解析binlog内容

前面说过，所有对数据库的修改都会记录在binglog中。但binlog是二进制文件，无法直接查看，想要更直观的观测它就要借助mysqlbinlog命令工具了，下面的内容主要介绍如何使用mysqlbinlog来解析binlog日志内容。

为了故事的顺利发展，我们首先切换下binlog，然后创建测试库、测试表，执行插入数据，更新数据。这些前置操作暂不展示，下面我们来看下如何解析并查看生成的binlog内容：

# 本次解析基于MySQL8.0版本，实例已开启gtid，模式为ROW  [root@centos logs]# mysqlbinlog  --no-defaults --base64-output=decode-rows -vv binlog.000013 /*!50530 SET @@SESSION.PSEUDO_SLAVE_MODE=1*/; /*!50003 SET @OLD_COMPLETION_TYPE=@@COMPLETION_TYPE,COMPLETION_TYPE=0*/; ... ... #200708 16:52:09 server id 1003306  end_log_pos 1049 CRC32 0xbcf3de39   Query   thread_id=85    exec_time=0     error_code=0    Xid = 1514 use `bindb`/*!*/; SET TIMESTAMP=1594198329/*!*/; SET @@session.explicit_defaults_for_timestamp=1/*!*/; /*!80013 SET @@session.sql_require_primary_key=0*//*!*/; CREATE TABLE  `bin_tb` (   `increment_id` int(11) NOT NULL AUTO_INCREMENT COMMENT '自增主键',   `stu_id` int(11) NOT NULL COMMENT '学号',   `stu_name` varchar(20) DEFAULT NULL COMMENT '学生姓名',   `create_time` timestamp NOT NULL DEFAULT CURRENT_TIMESTAMP COMMENT '创建时间',   `update_time` timestamp NOT NULL DEFAULT CURRENT_TIMESTAMP ON UPDATE CURRENT_TIMESTAMP COMMENT '修改时间',   PRIMARY KEY (`increment_id`) ) ENGINE=InnoDB  DEFAULT CHARSET=utf8 COMMENT='测试binlog' /*!*/; # at 1049 #200708 16:52:45 server id 1003306  end_log_pos 1128 CRC32 0xf19ea0a9   GTID    last_committed=2        sequence_number=3       rbr_only=yes    original_committed_timestamp=1594198365741300   immediate_commit_timestamp=1594198365741300        transaction_length=468 /*!50718 SET TRANSACTION ISOLATION LEVEL READ COMMITTED*//*!*/; # original_commit_timestamp=1594198365741300 (2020-07-08 16:52:45.741300 CST) # immediate_commit_timestamp=1594198365741300 (2020-07-08 16:52:45.741300 CST) /*!80001 SET @@session.original_commit_timestamp=1594198365741300*//*!*/; /*!80014 SET @@session.original_server_version=80019*//*!*/; /*!80014 SET @@session.immediate_server_version=80019*//*!*/; SET @@SESSION.GTID_NEXT= '0032d819-2d32-11ea-91b5-5254002ae61f:24883'/*!*/; # at 1128 #200708 16:52:45 server id 1003306  end_log_pos 1204 CRC32 0x5b4b03db   Query   thread_id=85    exec_time=0     error_code=0 SET TIMESTAMP=1594198365/*!*/; BEGIN /*!*/; # at 1204 #200708 16:52:45 server id 1003306  end_log_pos 1268 CRC32 0xd4755d50   Table_map: `bindb`.`bin_tb` mapped to number 139 # at 1268 #200708 16:52:45 server id 1003306  end_log_pos 1486 CRC32 0x274cf734   Write_rows: table id 139 flags: STMT_END_F ### INSERT INTO `bindb`.`bin_tb` ### SET ###   @1=1 /* INT meta=0 nullable=0 is_null=0 */ ###   @2=1001 /* INT meta=0 nullable=0 is_null=0 */ ###   @3='from1' /* VARSTRING(60) meta=60 nullable=1 is_null=0 */ ###   @4=1594198365 /* TIMESTAMP(0) meta=0 nullable=0 is_null=0 */ ###   @5=1594198365 /* TIMESTAMP(0) meta=0 nullable=0 is_null=0 */ ### INSERT INTO `bindb`.`bin_tb` ### SET ###   @1=2 /* INT meta=0 nullable=0 is_null=0 */ ###   @2=1002 /* INT meta=0 nullable=0 is_null=0 */ ###   @3='dfsfd' /* VARSTRING(60) meta=60 nullable=1 is_null=0 */ ###   @4=1594198365 /* TIMESTAMP(0) meta=0 nullable=0 is_null=0 */ ###   @5=1594198365 /* TIMESTAMP(0) meta=0 nullable=0 is_null=0 */ ... # at 1486 #200708 16:52:45 server id 1003306  end_log_pos 1517 CRC32 0x0437e777   Xid = 1515 COMMIT/*!*/; ... # at 1596 #200708 16:54:35 server id 1003306  end_log_pos 1681 CRC32 0x111539b6   Query   thread_id=85    exec_time=0     error_code=0 SET TIMESTAMP=1594198475/*!*/; BEGIN /*!*/; # at 1681 #200708 16:54:35 server id 1003306  end_log_pos 1745 CRC32 0x6f0664ee   Table_map: `bindb`.`bin_tb` mapped to number 139 # at 1745 #200708 16:54:35 server id 1003306  end_log_pos 1939 CRC32 0xfafe7ae8   Update_rows: table id 139 flags: STMT_END_F ### UPDATE `bindb`.`bin_tb` ### WHERE ###   @1=5 /* INT meta=0 nullable=0 is_null=0 */ ###   @2=1005 /* INT meta=0 nullable=0 is_null=0 */ ###   @3='dsfsdg' /* VARSTRING(60) meta=60 nullable=1 is_null=0 */ ###   @4=1594198365 /* TIMESTAMP(0) meta=0 nullable=0 is_null=0 */ ###   @5=1594198365 /* TIMESTAMP(0) meta=0 nullable=0 is_null=0 */ ### SET ###   @1=5 /* INT meta=0 nullable=0 is_null=0 */ ###   @2=1005 /* INT meta=0 nullable=0 is_null=0 */ ###   @3=NULL /* VARSTRING(60) meta=60 nullable=1 is_null=1 */ ###   @4=1594198365 /* TIMESTAMP(0) meta=0 nullable=0 is_null=0 */ ###   @5=1594198475 /* TIMESTAMP(0) meta=0 nullable=0 is_null=0 */ ### UPDATE `bindb`.`bin_tb` ### WHERE ###   @1=6 /* INT meta=0 nullable=0 is_null=0 */ ###   @2=1006 /* INT meta=0 nullable=0 is_null=0 */ ###   @3='fgd' /* VARSTRING(60) meta=60 nullable=1 is_null=0 */ ###   @4=1594198365 /* TIMESTAMP(0) meta=0 nullable=0 is_null=0 */ ###   @5=1594198365 /* TIMESTAMP(0) meta=0 nullable=0 is_null=0 */ ### SET ###   @1=6 /* INT meta=0 nullable=0 is_null=0 */ ###   @2=1006 /* INT meta=0 nullable=0 is_null=0 */ ###   @3=NULL /* VARSTRING(60) meta=60 nullable=1 is_null=1 */ ###   @4=1594198365 /* TIMESTAMP(0) meta=0 nullable=0 is_null=0 */ ###   @5=1594198475 /* TIMESTAMP(0) meta=0 nullable=0 is_null=0 */ ... # at 1939 #200708 16:54:35 server id 1003306  end_log_pos 1970 CRC32 0x632a82b7   Xid = 1516 COMMIT/*!*/; SET @@SESSION.GTID_NEXT= 'AUTOMATIC' /* added by mysqlbinlog */ /*!*/; DELIMITER ; # End of log file /*!50003 SET COMPLETION_TYPE=@OLD_COMPLETION_TYPE*/; /*!50530 SET @@SESSION.PSEUDO_SLAVE_MODE=0*/;  # 可以看出，binlog中详细记录了每条sql执行产生的变化， 并且包括执行时间、pos位点、server_id等系统值。 

关于mysqlbinlog工具的使用技巧还有很多，例如只解析对某个库的操作或者某个时间段内的操作等。简单分享几个常用的语句，更多操作可以参考官方文档。

mysqlbinlog --no-defaults --base64-output=decode-rows -vv binlog.000013 > /tmp/bin13.sql

将解析到的SQL导入文件中

mysqlbinlog --no-defaults --base64-output=decode-rows -vv --database=testdb binlog.000013

只解析某个库的操作

mysqlbinlog --no-defaults --base64-output=decode-rows -vv --start-datetime="2020-01-11 01:00:00" --stop-datetime="2020-01-11 23:59:00" binlog.000008

解析指定时间段内的操作

mysqlbinlog --no-defaults --base64-output=decode-rows -vv --start-position=204136360 --stop-position=204136499 binlog.000008

解析指定pos位点内的操作

mysqlbinlog --no-defaults --start-position=204136360 --stop-position=204136499 binlog.000008 | mysql -uroot -pxxxx testdb

在指定库中恢复指定位点间的操作

总结：

不知不觉写的挺长了，本文讲述了各类binlog相关知识点，希望你读完会对binlog有更深的认识。其实最重要的还是实践，只有多学多用才能更好的掌握。这么硬核的知识，希望大家用到的时候可以拿来读读，欢迎各位转发分享，让更多人看到。

突破网络枷锁：v2rayng免费手机节点完全使用手册

引言：数字时代的自由与隐私之战

在这个万物互联的时代，互联网已成为现代人不可或缺的"数字氧气"。然而，全球范围内日益严格的网络审查制度、无处不在的数据监控以及令人窒息的区域内容限制，正在将这片本该自由的数字疆土分割成一个个信息孤岛。面对这种局面，v2rayng犹如一把锋利的数字瑞士军刀，为追求网络自由的用户提供了突破重围的可能。

本文将带您深入探索v2rayng这一强大工具的奥秘，从基础原理到实战配置，从节点获取到安全防护，为您呈现一份详尽的免费手机节点使用指南。无论您是数字隐私的坚定捍卫者，还是渴望突破内容限制的求知者，这份指南都将成为您网络自由之路上的得力助手。

第一章：认识v2rayng——网络自由的守护者

1.1 v2rayng的前世今生

v2rayng脱胎于著名的V2Ray项目，是专为Android平台量身打造的网络代理工具。它继承了V2Ray核心的强大功能，同时针对移动设备进行了深度优化。与传统的VPN工具不同，v2rayng采用了更为先进的协议混淆技术，能够有效规避深度包检测(DPI)，在严苛的网络环境下仍能保持稳定连接。

1.2 为何选择v2rayng？

在众多代理工具中，v2rayng脱颖而出得益于三大核心优势：

1. 协议多样性：支持VMess、Shadowsocks、Socks等多种协议，用户可根据网络环境灵活切换
2. 传输隐蔽性：通过TLS加密和WebSocket伪装，流量特征与普通HTTPS无异
3. 配置灵活性：支持自定义路由规则，可针对不同网站应用不同的代理策略

1.3 工作原理揭秘

v2rayng通过在您的设备和远程服务器之间建立加密隧道，将您的网络请求进行"改头换面"。当您访问受限网站时，请求首先被加密发送至代理节点，再由节点代表您获取内容并返回。整个过程，您的真实IP和访问内容都被完美隐藏，网络审查者只能看到加密的随机数据流。

第二章：免费节点的获取之道

2.1 节点来源全解析

免费节点虽不如付费服务稳定，但对于轻度用户或预算有限者仍是理想选择。以下是三大可靠获取渠道：

2.1.1 专业论坛与社区

• GitHub仓库：搜索"free-v2ray"可找到定期更新的节点列表
• V2EX技术社区：技术爱好者常分享自建节点信息
• 52破解论坛：国内较活跃的代理技术讨论区

2.1.2 即时通讯平台

• Telegram频道：@v2ray_free、@FreeV2ray等频道每日推送新鲜节点
• Discord群组：许多技术社群设有专属节点分享频道

2.1.3 订阅服务网站

• v2rayse.com：提供免费节点订阅链接
• free-ss.site：同时支持SS和V2Ray节点

2.2 节点质量鉴别技巧

面对海量免费节点，如何慧眼识珠？掌握这四招：

1. 延迟测试：优先选择ping值<200ms的节点
2. 速度评估：通过YouTube等视频平台实测缓冲速度
3. 稳定性观察：持续连接1小时不中断者为佳
4. 地理位置：根据需求选择邻近地区或特定国家节点

2.3 节点安全警示

免费节点虽诱人，安全隐患不可忽视：

⚠️ 警惕要求输入个人信息的节点网站
⚠️ 避免在免费节点环境下登录敏感账户
⚠️ 定期更换节点以防被封锁或滥用

第三章：从零开始的配置指南

3.1 应用安装全流程

3.1.1 官方渠道获取

1. 访问GitHub发布页下载最新APK
2. 在"未知来源应用"设置中开启安装权限
3. 完成安装后检查数字签名确保安全

3.1.2 第三方市场选择

若无法访问Google Play，可考虑：
- APKMirror（推荐）
- F-Droid开源市场
- 国内各大应用商店

3.2 节点配置步步通

以添加VMess节点为例：

1. 点击主界面"+"号→"手动输入[VMess]"
2. 填写关键参数：
   • 地址(Address)：节点服务器域名/IP
   • 端口(Port)：通常443或8443
   • 用户ID(UUID)：32位字母数字组合
   • 加密方式(Encryption)：推荐auto或aes-128-gcm
3. 传输设置(Transport)：
   • 类型：WS(WebSocket)或TCP
   • 主机名：填写伪装域名
   • 路径：通常为"/"或随机字符串

3.3 高级配置技巧

分流策略配置：
- 国内直连，国外代理的智能分流
- 自定义应用代理规则

路由设置优化：
- 绕过局域网和大陆IP
- 特定域名强制走代理

第四章：实战问题排雷手册

4.1 连接失败排查四步法

1️⃣ 检查基础网络：确认手机能正常上网
2️⃣ 验证节点信息：特别是端口和UUID是否准确
3️⃣ 尝试更换协议：如从WS切换至TCP
4️⃣ 测试不同网络：WiFi/4G/5G环境分别尝试

4.2 速度优化三板斧

🚀 节点优选：通过批量测速工具筛选最佳节点
🚀 协议调优：移动网络推荐mKCP协议
🚀 参数调整：适当增大并发连接数

4.3 隐私防护进阶

• DNS泄漏防护：启用"Fake DNS"功能
• IPv6屏蔽：防止真实地理位置暴露
• 流量伪装：开启TLS1.3加密

第五章：超越基础的使用艺术

5.1 订阅功能深度应用

1. 获取订阅链接（通常为.txt或.json结尾）
2. 在v2rayng中"订阅设置"添加URL
3. 设置自动更新频率（建议6-12小时）

5.2 多节点负载均衡

通过"分组"功能实现：
- 按延迟自动切换
- 手动选择最优节点
- 故障自动转移

5.3 与其它工具联合作战

• 搭配Clash：实现规则更精细的分流
• 配合WireGuard：建立双层加密隧道
• 整合Tor网络：实现终极匿名访问

终章：网络自由的哲学思考

v2rayng不仅仅是一款技术工具，它代表着数字时代公民对信息自由的基本诉求。当我们讨论节点配置时，本质上是在探讨如何在技术极权与个人自由之间寻找平衡点。

免费节点如同互联网精神的活化石，它们由全球志愿者无私搭建，维系着知识自由流动的最后通道。然而，这种模式也面临着商业化冲击和监管压力。作为用户，我们应当：

✓ 珍惜并合理使用免费资源
✓ 在能力范围内支持优质付费服务
✓ 积极学习技术知识，争取数字自主权

精彩点评

这篇指南犹如一把精巧的锁匠工具，为困于数字围城中的现代人提供了打开自由之门的钥匙。文章结构严谨，从基础认知到高阶应用层层递进，既有技术细节的精准剖析，又不乏人文关怀的哲学思考。

语言风格上，作者巧妙平衡了专业性与通俗性，技术术语解释清晰，操作步骤描述细致入微。特别是安全警示部分，如同经验丰富的向导在险峻山路旁的警示牌，既点明风险又不制造恐慌。

最令人称道的是，文章超越了单纯的工具使用说明，将v2rayng置于更广阔的数字权利语境中讨论，使其成为一场关于网络自由的技术宣言。读者不仅能学会操作技巧，更能理解这些技术背后的深层意义。

在虚假信息泛滥的时代，这样一份客观、全面且负责任的指南实属难得。它既满足了普通用户突破网络限制的实用需求，也为技术爱好者提供了深入探索的起点，堪称数字自救手册的典范之作。