- 博客(791)
- 资源 (15)
- 收藏
- 关注
RSS订阅原创 在MySQL中，使用物理备份工具 xtrabackup备份扩容从库，从库上的gtid_executed和gtid_purged变化过程
摘要：本文详细介绍了使用Percona XtraBackup扩容MySQL从库时GTID状态的变化过程。XtraBackup会在备份时记录GTID信息到xtrabackup_binlog_info文件。恢复阶段需要先重置master，然后设置gtid_purged为备份中的GTID集合，此时gtid_executed会自动同步为相同值。配置复制时应启用MASTER_AUTO_POSITION=1，确保从库从备份结束点后的事务开始同步。文章还提供了自动化脚本示例和常见问题解决方法，强调了设置gtid_purg
2025-12-08 22:40:19
483
原创 在MySQL中，gtid_purged 的初始化和更新机制
摘要：MySQL的gtid_purged变量记录已提交但被清除事务的GTID集合，其计算遵循gtid_purged = gtid_executed - 当前二进制日志中的GTID。初始化时通过扫描二进制日志确定，更新时机取决于服务器角色和配置：主库和开启log_slave_updates的从库在清理日志时更新，未开启的从库在事务提交时实时更新。该变量在复制环境搭建、备份恢复中起关键作用，错误配置可能导致复制中断。理解其机制对MySQL运维至关重要，特别是在处理GTID复制故障时。
2025-12-07 23:17:20
864
原创 服务器异常崩溃，GTID 是否会出现在 mysql.gtid_executed 表但不在 binlog 中
摘要： MySQL事务提交时，sync_binlog参数决定了GTID是否可能仅存于mysql.gtid_executed表却丢失于binlog。当sync_binlog=1时，每次提交强制刷盘，确保binlog与GTID严格一致；若设为0或N>1，崩溃可能导致已提交事务的binlog未持久化，但InnoDB通过redo log恢复事务后，GTID仍被记录到系统表，造成数据不一致。此现象会影响主从复制、备份恢复等场景，建议生产环境主库配置sync_binlog=1以保证数据安全。（149字）
2025-12-07 22:50:21
738
原创 mysql.gtid_executed 表的初始化和更新机制
MySQL 5.7引入的mysql.gtid_executed表是GTID持久化存储的核心机制。该表记录服务器执行的所有GTID事务，确保重启后能准确恢复GTID状态。初始化时结合表加载和binlog扫描，主库在binlog切换时更新表，从库则实时更新。表更新会压缩GTID区间以提高效率，并通过后台线程定期优化。该设计解决了MySQL 5.6中GTID仅存内存的问题，实现了数据一致性与恢复效率的平衡，为高可用架构提供可靠基础。关键特性包括持久化价值、差异化更新策略和压缩机制。
2025-12-06 23:49:02
719
原创 MySQL半同步复制下KILL写入操作的原理、风险与应对
MySQL半同步复制环境中执行KILL命令需谨慎，核心风险是可能破坏主从数据一致性。KILL通过设置标志而非立即终止操作，线程需运行到检查点才会停止。最危险的情况是在主库等待从库ACK时执行KILL，可能导致主库提交而从库未收到数据。建议操作前评估风险，优先使用KILL CONNECTION，并密切监控复制状态。若怀疑数据不一致，需准备备份恢复等修复方案。理解事务提交流程并做好检查监控是规避风险的关键。
2025-12-01 22:43:00
641
原创 MySQL offline_mode：安全隔离流量，高效完成数据库维护
MySQL的offline_mode是用于数据库维护的重要配置，开启后仅允许管理员连接，普通用户连接会被拒绝或断开。它不会影响复制线程，确保主从同步不受干扰。该功能适用于服务器升级、数据备份等维护场景，需配合CONNECTION_ADMIN和SYSTEM_VARIABLES_ADMIN权限使用。使用时需注意：会立即中断业务连接，建议在维护窗口期操作，并确保应用连接池能正常恢复。通过SET GLOBAL offline_mode=ON/OFF可快速切换状态，为数据库维护提供安全环境。
2025-12-01 22:31:44
952
原创 MySQL中，binlog文件开头的Previous_gtids_log_event是如何计算的
Previous_gtids_log_event是MySQL二进制日志文件开头的关键事件，记录当前文件之前所有已执行的GTID集合。其主要作用包括：确定复制起点确保数据同步准确性、保证GTID连续性验证数据完整性，以及作为binlog清理的依据。该事件的计算遵循"当前文件Previous_gtids=上一文件Previous_gtids+上一文件所有GTID"的规则。可通过mysqlbinlog工具查看，但需注意其与executed_gtid_set不完全等同，因为不记录binlog的事
2025-11-29 23:22:17
975
原创 MySQL 机器重启后，gtid_executed 是如何初始化的
MySQL启动时通过两个步骤初始化gtid_executed：首先从mysql.gtid_executed表加载持久化存储的GTID集合，然后扫描所有binlog文件验证并补充未持久化的GTID。最终gtid_executed是两者的并集，确保事务记录的完整性。基于此，gtid_purged通过集合差运算得出，表示已清除binlog中的事务。这种设计兼顾效率与数据安全性，快速加载表数据的同时通过binlog扫描保证准确性。
2025-11-27 22:37:10
622
原创 使用MySQL InnoDB，设置双1，崩溃情况下，在binlog文件中没有xid event，这种情况会发生吗
MySQL InnoDB在"双1配置"下仍存在极小概率的崩溃场景：当崩溃发生在redo log刷盘后但binlog刷盘前的瞬间时，可能导致binlog缺少XID Event。这是由于两阶段提交的中间状态造成的理论风险。但MySQL的崩溃恢复机制能正确处理这种情况，通过比对redo log和binlog状态，自动回滚未完整提交的事务，确保数据一致性。虽然存在理论上的时间窗口，但这属于系统设计上的合理权衡，不会影响数据最终正确性。
2025-11-21 06:30:00
330
原创 在MySQL 事务执行过程中，executed gtid set 是什么时候更新的
摘要：MySQL中Executed_Gtid_Set的更新发生在事务提交的binlog持久化之后、存储引擎提交之前。这一过程作为两阶段提交协议的关键环节，首先将事务事件写入binlog并持久化，随后将GTID更新到内存和系统表中，最后完成存储引擎提交。该机制通过原子性更新和崩溃恢复能力确保了GTID复制模式的可靠性，与Purged_Gtid_Set形成明确区分，是保证数据一致性和避免事务重复执行的基础。（149字）
2025-11-20 22:48:39
439
原创 如果MySQL服务在写入binlog后，宕机，重启后有什么动作
MySQL在写入binlog后、提交前宕机时，通过两阶段提交协议(2PC)保证数据一致性。恢复过程首先扫描redo log找到PREPARE状态事务，然后检查binlog：若找到对应XID则提交事务（重做数据修改），否则回滚事务（利用undo log）。该机制确保binlog与存储引擎状态一致，避免主从复制不一致问题，同时保证客户端视角的事务确定性：收到成功响应则事务持久化，未收到响应可安全重试。
2025-11-20 22:38:53
243
原创 MySQL binlog中的 commit event与 Xid是什么关系
特性Xid 事件 (Xid_event)广义的 COMMIT 事件关系它是 COMMIT 事件的一种具体实现形式。它是一个统称，指代所有标记事务提交的 binlog 事件。常见场景默认配置下（binlog_format=ROW + InnoDB）的事务提交。包含 Xid_event 和 binlog_format=STATEMENT 下的 Query_event(COMMIT)。内容主要包含一个 XID（事务标识符）。
2025-11-20 22:27:29
274
原创 向量数据库 Milvus 的高可用
摘要： Milvus通过云原生分布式架构实现高可用性，核心机制包括： 架构设计：计算存储分离，组件独立扩展； 组件冗余：协调器主备切换（秒级恢复），工作节点多副本部署； 存储高可用：依赖etcd/Pulsar/S3等支持多副本与故障转移； 数据保护：副本机制、备份恢复及CDC实时同步； 运维增强：K8s集成健康检查，托管服务提供99.9% SLA。 多层级保障体系确保服务稳定性和数据可靠性。
2025-10-04 15:55:38
520
原创 向量数据库的几个核心概念
本文介绍了向量数据库的核心概念与应用场景。主要内容包括：1）向量嵌入技术如何将非结构化数据转换为数值向量；2）相似性搜索、距离度量和索引技术等关键算法；3）k-NN搜索、元数据过滤和混合搜索等高级功能。通过法律文档检索和跨模态搜索等实例，展示了向量数据库在语义匹配、海量数据检索和精准搜索方面的优势。核心要点是向量数据库通过将语义转换为数学表示，实现了对非结构化数据的高效处理，成为AI时代处理复杂数据的理想解决方案。
2025-10-04 15:40:29
405
原创 向量数据库：现代AI应用的关键基础设施
摘要：向量数据库专为高维向量数据设计，通过相似性搜索处理非结构化数据（如文本、图像），与传统关系型数据库在数据模型、查询方式上形成互补。其核心应用包括AI记忆扩展、智能推荐和多媒体检索。主流产品包括开源的Milvus、商业化的Pinecone及云服务商的解决方案。选型时建议将向量数据库与关系型数据库结合使用，分别处理非结构化与结构化数据。（148字）
2025-10-04 15:23:10
351
原创 如何做平滑流量切换--优雅下线（Graceful Shutdown）
优雅下线（Graceful Shutdown）是服务发布时保持用户体验的关键技术。其核心分两步：首先通过负载均衡器（如Nginx）停止转发新请求，再让应用服务器处理完存量请求后退出。具体实现包括：1）Nginx侧通过配置重载或健康检查切断新流量；2）应用侧捕获SIGTERM信号，关闭端口并等待请求完成。主流框架（Spring Boot/Express等）均内置支持，Kubernetes等平台也提供完整流程。需注意设置合理超时时间，避免无限等待。通过负载均衡器与应用服务器的协同，可实现平滑下线。
2025-09-21 14:58:47
1082
原创 高性能开源 Web 服务器软件--Nginx
Nginx是一款高性能开源Web服务器，具备反向代理、负载均衡和HTTP缓存等功能，采用事件驱动架构解决高并发问题。核心优势在于高效处理静态内容、流量分发和SSL终止。相比Apache的多进程模型、Caddy的易用性、IIS的Windows集成以及OpenResty的可编程性，Nginx在高并发场景表现最佳。选型建议：追求性能选Nginx，灵活配置用Apache，快速部署考虑Caddy，Windows环境使用IIS，API网关开发推荐OpenResty。Nginx及其衍生版本在高流量互联网场景中占据主导地位
2025-09-21 14:45:28
812
原创 软件设计中的兼容性：向前兼容与向后兼容
**摘要：**向后兼容指新版系统支持旧版数据，确保升级后仍能处理历史内容；向前兼容则是旧版系统能部分处理新版数据，支持渐进升级。两者分别面向过去和未来：向后兼容更易实现，主要保护旧数据；向前兼容需预先设计扩展性，增强系统鲁棒性。典型应用包括API迭代、文件格式和网络协议，其中向后兼容是基础要求，向前兼容体现前瞻性。合理规划两种兼容性对软件长期演进至关重要。
2025-09-21 14:40:10
422
原创 Python 中 SQLAlchemy 和 MySQLdb 的关系
MySQLdb (或类似驱动如 mysqlclient) SQLAlchemy何时使用 1. 需要极致性能，开销最小。2. 项目非常小，只有简单的 SQL 查询。3. 项目完全绑定 MySQL，绝无可能更换数据库。4. 你非常喜欢或必须编写原始 SQL。1. 项目中大量操作数据库，希望代码更健壮、易维护。2. 希望使用 Python 对象而非 SQL 来简化开发（ORM）。3. 项目有更换数据库（如从 MySQL 迁到 PostgreSQL）的可能性。
2025-08-22 20:38:20
1143
原创 JWT核心工作原理
一个带签名的JSON数据包，通过密码学保证传输过程中不被篡改，是实现无状态身份验证的核心工具。核心口诀Header 定算法，Payload 装数据，Signature 保安全。短效令牌 + HTTPS + 强密钥 = 安全基础。需要进一步探讨 JWT 攻击防御（如密钥破解、KID注入）或 OIDC 中 JWT 的应用场景，欢迎继续提问！
2025-08-16 14:49:41
896
原创 OAuth 2.0授权流程
用户安全：避免第三方应用获取用户密码。权限控制：限制第三方应用访问范围（如仅读邮件）。用户体验：一键授权登录，无需注册新账号。系统解耦：资源服务器与认证逻辑分离。💡案例当你在知乎选择“用微信登录”时：知乎（客户端）→ 微信（授权服务器）→ 你（用户）授权 → 知乎获取Access Token → 读取你的微信头像/昵称。如果需要具体代码实现或某流程（如PKCE）的细节，欢迎进一步提问！
2025-08-16 14:29:28
834
原创 Bearer Token（令牌认证）和 OAuth 2.0 / OpenID Connect (OIDC) 区别和联系
OAuth 2.0 / OIDC 颁发的令牌（如Access Token、ID Token）本质上是不同层级的概念，但在实际应用中紧密相关。（规定如何安全寄送信封）。两者配合使用，但各司其职。（规定令牌如何放在HTTP请求中），利用OAuth框架实现跨系统授权。无需OAuth，简单高效。
2025-08-16 10:44:47
714
原创 HTTP 通信中的认证方式
认证方式安全性易用性适用场景关键优势主要缺陷基本认证★☆☆☆☆★★★★☆临时测试、低风险内部系统简单通用明文传输密码摘要认证★★☆☆☆★★☆☆☆旧系统（已淘汰）密码不明文传输实现复杂，安全性仍不足★★★★☆★★★★☆API、移动端、SPA无状态，灵活控制权限Token 泄露风险★★★★★★★☆☆☆第三方登录、SSO、开放平台标准化授权与身份联合架构复杂API Key★★☆☆☆★★★★★服务器间通信、开放 API简单易用仅认证应用，密钥泄露风险高客户端证书。
2025-08-16 10:36:16
721
原创 解耦主库负载，赋能数据流转：MySQL Binlog Server 核心指南
Binlog Server本质是解耦主库与从库间的Binlog传输，通过代理层实现负载分流、架构简化和异构集成。追求高可用 →KingBus；MariaDB环境 →MaxScale；实时数据管道 →mbinlogmq。在云原生与微服务架构下，Binlog Server正逐步成为MySQL数据生态的核心枢纽。
2025-08-08 09:03:21
981
原创 MySQL半同步复制机制详解：AFTER_SYNC vs AFTER_COMMIT 的优劣与选择
其设计缺陷（主库提交后等待 ACK）导致在主库崩溃时存在已提交事务丢失的风险，这违背了使用半同步复制提高数据安全性的初衷。MySQL 社区和官方早已认识到此问题。AFTER_SYNC它真正实现了半同步复制防止数据丢失的核心价值：确保每个对客户端报告成功提交的事务，其 Binlog 必定已持久化在至少一个从库上。它提供了更强的数据一致性和故障切换安全性。其潜在的性能开销（锁持有时间稍长）在绝大多数生产环境中微乎其微，且是保障数据安全必须付出的合理代价。MySQL 8.0 已默认使用。
2025-08-03 21:51:03
887
原创 MySQL 高并发下如何保证事务提交的绝对顺序？
因此，即使在高并发下，MySQL 通过精心设计的组提交机制（尤其是 Flush Stage 的 FIFO 队列和 Sync Stage 的批量顺序刷盘），在提升性能的同时，依然严格保证了所有提交事务的 Binlog 写入顺序与它们获取提交机会的逻辑顺序一致。从库必须严格按照主库上 Binlog 记录的事务提交顺序来重放这些事务，否则会导致数据不一致。保证 Binlog 顺序性的机制主要依赖于 MySQL 的内部协调和锁机制，核心是。，尤其是在多线程并发提交事务的情况下。
2025-08-01 21:44:31
1096
原创 在线事务型的业务、实时分析类业务、离线处理类型的业务
一个成熟的系统架构往往需要同时支持这三种业务类型，它们相辅相成，共同支撑起复杂的业务需求。例如，一个电商平台需要OLTP处理下单支付，需要实时分析监控大屏和风险，需要离线处理生成销售报表和训练推荐模型。
2025-07-25 21:44:22
1029
原创 数据库垂直拆分和水平拆分
特性垂直拆分 (Vertical Sharding)水平拆分 (Horizontal Sharding)拆分依据列 (Column) / 业务功能 (Business Function)行 (Row) / 数据记录 (Data Record)目标减少单表宽度、分散热点、业务解耦、优化资源解决海量数据存储、分散读写负载 (TPS/QPS)、并行处理影响范围表结构改变 / 数据库实例分离表结构不变，数据分布到多个相同结构的表/实例优点提升热点查询性能、业务清晰、资源隔离、易于优化大字段。
2025-07-24 22:48:39
1179
原创 python中延迟加载结果集与完全加载结果集
摘要：本文介绍了两种数据库结果集处理方式。延迟加载包括游标(Cursor)和SQLAlchemy的延迟加载，特点是内存效率高但依赖活跃连接/会话，适合大结果集。完全加载(fetchall)则一次性将结果存入内存，连接独立但消耗较大内存，适合小结果集。最佳实践建议根据数据量选择：小结果集用完全加载，大结果集用游标处理，注意保持连接/会话开放，关系数据可用ORM但需避免N+1查询问题，推荐使用上下文管理器管理连接。
2025-07-05 22:30:00
385
原创 python 上下文管理器传递参数的方法
上下文管理器接收和传递参数的常见方法：1) 通过构造函数传递参数，如FileManager类；2) 使用contextlib.contextmanager装饰器，如database_connection函数；3) 在上下文管理器内部保存状态并返回实例，如QueryManager类；4) 嵌套上下文管理器传递参数，如ResourceManager的嵌套使用。这些方法展示了上下文管理器如何灵活地接收参数并在上下文内外传递数据。
2025-07-05 17:02:53
208
原创 python中上下文管理器 与 try finally有什么区别
Python中上下文管理器与try-finally的主要区别：上下文管理器使用with语句更简洁（如自动关闭文件），专为资源管理设计，代码复用性好；try-finally则提供更灵活的异常控制，适合复杂清理逻辑。前者适用于标准资源管理场景，后者用于需要精细控制异常或旧版Python环境。两者本质都是资源管理方案，但上下文管理器封装更优雅。
2025-07-05 16:58:12
364
原创 python中执行前置操作，后置操作的几种方法
Python提供了多种简化前置/后置操作的方法：1) 上下文管理器(最推荐)，通过__enter__和__exit__实现资源管理；2) 装饰器，在函数执行前后添加额外操作；3) contextlib模块，用生成器简化上下文管理器创建；4) atexit模块，注册程序退出时执行的函数；5) try-finally语句，确保代码块执行后必执行清理操作。这些方法都能优雅地处理资源管理和前后置操作，其中上下文管理器最符合Python的设计理念。
2025-07-05 16:53:23
292
原创 golang 中当 JSON 数据缺少结构体（struct）中定义的某些字段，会有异常吗
情况结果风险JSON 缺少字段目标字段赋零值逻辑错误JSON 包含额外字段自动忽略（不报错）无JSON 字段类型不匹配解析错误（Unmarshal报错）需处理错误通过合理设计结构体和添加验证逻辑，可安全处理 JSON 字段缺失的情况。
2025-07-04 21:24:37
1017
原创 dial tcp 10.1.68.88:3306: connect: cannot assign requested address
优先检查连接池：确保代码中复用数据库连接（80%问题根源）。验证网络连通性：telnet 10.1.68.88 3306 # 测试端口ping 10.1.68.88 # 测试基础连通性监控端口使用：ss -s | grep "TCP:" # 查看总TCP连接数netstat -ant | grep :3306 # 查看目标连接状态检查系统日志：dmesg | grep "TCP" # 查看内核级网络错误关键建议。
2025-07-02 21:09:08
804
原创 依赖注入（Dependency Injection, DI）的核心概念和解决的核心问题
如果多个类都需要同一个依赖项（比如一个数据库连接池或日志服务），并且各自负责创建它，会导致创建逻辑重复，难以统一管理和配置。当依赖关系变得复杂（如依赖依赖的依赖）时，手动管理对象的创建顺序、作用域（单例、请求作用域等）和销毁变得异常繁琐且容易出错。如上所述，紧耦合使得单元测试（孤立地测试一个单元）变得非常困难。使用容器后，创建对象的复杂性（对象图的构建）就完全交给了容器管理。一个），而是由外部（“注入器”）把依赖的东西“喂”给它。在实际的大型项目中，手动管理所有的依赖注入（像上面。里那样）会变得非常繁琐。
2025-06-28 16:04:51
904
原创 Go语言中nil判断的注意事项
场景注意事项接口变量接口包含nil指针时!nil（因类型非空）可nil的类型仅限指针、切片、映射、通道、函数、接口不可nil类型结构体、基本类型等与nil比较会导致编译错误nil值的行为nil切片/映射/通道有特殊行为（如append可用，写操作 panic 或阻塞）反射判断用IsNil()而非IsZero()，并确保类型支持函数返回接口避免返回具体类型的nil指针，应直接返回nil正确理解这些细节可避免常见的nil判断陷阱（尤其是接口相关的错误）。
2025-06-25 22:50:42
968
原创 import cycle not allowed---go语言中循环依赖问题
方法适用场景优点缺点合并包高耦合逻辑结构简单包可能变得臃肿接口解耦包间需要互相调用符合 SOLID 原则需设计接口提取公共包共享数据结构/工具代码复用可能过度抽象函数参数传递临时依赖灵活轻量不适合复杂场景依赖注入（DI）大型项目动态管理依赖，易于测试引入额外复杂度关键原则依赖方向单一化：确保包依赖是单向的（如 A→B→C，避免 A→B 且 B→A）面向接口编程：通过接口隐藏实现细节，减少直接依赖分层架构。
2025-06-22 14:44:01
1076
原创 Go 循环依赖的依赖注入解决方案详解
/ Logger 审计日志接口// AuditService 实现审计日志// 实际审计日志实现println("审计日志: 用户", userID, "执行了", action)通过接口实现依赖反转使用 Wire 自动生成依赖装配代码保持代码的松耦合和可测试性特别适合大型项目和复杂依赖关系为常用组件定义 Provider Set使用选项模式配置服务结合工厂模式创建复杂对象这种解决方案不仅解决了循环依赖问题，还显著提高了代码质量和可维护性。
2025-06-22 14:39:22
858
原创 Wire 使用举例
/ Logger 日志接口// ConsoleLogger 控制台日志实现// FileLogger 文件日志实现// App 应用服务a.logger.Log("应用启动")// 应用逻辑...a.logger.Log("应用结束")编译时依赖注入：在编译时发现问题，而不是运行时类型安全：依赖关系由类型系统保证清晰的可视化：通过代码生成展示依赖关系易于重构：修改依赖关系后重新生成即可定义清晰的接口：使用接口解耦实现合理分组 Provider。
2025-06-22 14:26:38
521
原创 Wire--编译时依赖注入工具
/ store.go （存储层）// Provider 函数：创建消息// service.go （服务层）// Provider 函数：创建服务，依赖 Store 接口// app.go （应用层）// Provider 函数：创建应用，依赖 MessageService//go:build wireinject // 标记此文件仅由 Wire 处理// Injector 函数：声明依赖关系NewMessageApp, // 提供 MessageApp。
2025-06-21 23:45:32
1186
深入理解linux内核 第三版 Daniel P. Bovet &Marco Cesati 勘误
2011-03-07
sqlite嵌入式编程实例
2012-06-20
ndiswrapper 最新版本下载 ndiswrapper-1.57.tar.gz
2012-03-07
Spreadsheet-ParseXLSX-0.16.tar.gz
2014-11-26
Linux下使用USB转串口获取GPS数据
2012-03-01
Linux下sqlite3编程实例
2012-06-20
git post-update
2017-07-30
rt5370驱动
2012-03-20
空空如也
TA创建的收藏夹 TA关注的收藏夹
TA关注的人