学亮编程手记

在 AI 技术快速演进的时代，数据基础设施正成为AI应用的核心支撑。Apache Doris 作为一款高性能、实时分析型数据库，深度融合了文本搜索、向量搜索、AI 函数和MCP智能交互能力，构建从数据存储、检索到分析的完整 AI 数据栈。Doris 提供高性能、低成本、易集成的一体化解决方案, 广泛支持混合检索与分析、面向Agent的数据分析、RAG 应用构建、语义检索应用，以及大规模AI系统和应用的可观测性分析等场景。

Doris 选型 (AVX2) 与 AI 功能协作紧密：向量索引构建是高强度 CPU 计算，使用 AVX2 版本可显著提升索引构建速度和查询性能。尝试 AI 函数：在测试环境先用等初步分析。试用混合搜索：整合全文、向量检索和结构化查询。生态集成MCP Server：可通过与 LangChain/Dify 集成，用自然语言查询数据。RAG 系统：作为私有知识库和数据存储底座，开发智能问答/知识库应用。

Doris有avx2和noavx2两个不同版本，当CPU支持AVX2指令集时，优先选择**x64 (avx2)**版本是明确的，它能带来显著的性能提升。博主亲历过no avx2带来的显著性能下降相关场景！！！

博主遇到的这个问题中，根据错误提示表名MySQL 8.0 版本已经。这通常出现在 MySQL 8.4 及以上版本，或某些配置了的 8.0 环境中。这正是ALTER USER命令失败的根本原因。

如果MySQL所在服务器的所有网络和权限配置都正确，但仍然无法连接，问题很可能出在上。从错误来看，客户端可能在发送密码时出现了问题。

可以做静态备份，备份一组日志文件，并在到达最后一个文件的末尾时停止。它也可以制造连续的（“ 活的 ”） 备份，服务器结束时保持连接 最后一个日志文件的记录，并继续复制新的事件 是生成的。一起备份服务器的数据和二进制日志，以及如何在数据丢失时使用备份恢复服务器。可以 直接从本地文件系统读取日志文件，或者使用 --read-from-remote-server。然后使用二进制日志备份，重新执行转储文件中列出的坐标之后写入的事件。写入 文本输出到其标准输出，或文件，称为 的值 --result-file=*

server-id 规划：binlog server 使用 65535 或更高，避免与复制从库冲突目录独立：备份目录和数据目录分开，避免磁盘争用监控告警：5分钟无更新即报警定期演练：每月至少一次恢复演练结合全量：binlog 备份必须配合全量备份才有意义版本兼容：MySQL 5.7.19+ 可获得更好的事件完整性。

通过以上配置，MySQL 5.7 就成功开启了 Pseudo-GTID 功能。这将让 Orchestrator 在不开启原生 GTID 的情况下，依然能够实现接近 GTID 的自动化故障转移能力。最后验证清单所有节点都创建了 meta 数据库所有节点的事件调度器已开启所有节点的 Pseudo-GTID 事件已创建并启用监控用户有 DROP 权限至少观察到一个 Pseudo-GTID 标记写入 binlogOrchestrator 配置文件已更新。

环境是 MySQL 5.7.44，没有开启GTID。对于MySQL 5.7但未开启GTID**，推荐使用 伪GTID（Pseudo-GTID）模式。这是Orchestrator专为这类场景设计的"杀手锏"功能。伪GTID通过在MySQL的二进制日志（binlog）中定期注入一些特殊的、全局唯一的"标记"，为Orchestrator提供了类似于GTID的定位锚点。当发生故障转移时，Orchestrator可以通过这些标记快速找到数据同步点，而不是去费力比对繁琐的文件名和偏移量。如果因为某些原因不想使用伪GTI

Orchestrator非常灵活，它：GTID、传统基于日志点的复制，以及它独创的。你可以根据你的MySQL版本和具体需求，选择最适合的模式。

Orchestrator实现自动化运维的核心逻辑是：当故障的老主库恢复后，它并不是通过一个独立的特殊流程被“收编”的，而是被Orchestrator持续的**“拓扑发现”机制“重建复制”流程**被纳入新拓扑的。整个过程是智能且自动的，就像一个不停巡视的哨兵，看到新来的士兵就自动引导他归队。

通过以上步骤，我们成功在CentOS 7离线环境中部署了Orchestrator集群，实现了MySQL主从复制拓扑的自动发现、可视化管理和故障自动转移。相比传统MHA方案，Orchestrator不仅解决了管理节点的单点问题，还提供了更便捷的运维界面和更智能的故障恢复策略。关键点回顾离线安装需提前准备依赖包（oniguruma, jq）Raft协议保证了Orchestrator自身的高可用GTID复制是自动化切换的基础合理的权限配置和MySQL参数优化是稳定运行的保障。

Orchestrator，顾名思义，是一个“总指挥”或“自动化的大脑”。将复杂、重复的人工操作，转变为自动化、可编排的流程。指挥家不会亲自演奏每一个乐器他的工作是协调各个乐手，确保他们在正确的时间按照正确的节奏一起演奏最终呈现出一首和谐的乐曲同样，在技术领域，Orchestrator负责协调各种系统、服务或组件，让它们按照预设的规则协同工作，完成复杂的自动化任务。是一款用Go语言编写的、用于MySQL复制拓扑管理和高可用的开源工具。它就像一个。

回顾整个选型过程，其实是一个从"追求完美"到"接受现实"的演进：PXC的强一致性很美好，但8TB数据量让它寸步难行。MGR同样有节点恢复时的全量同步问题。最终落地的Orchestrator+ProxySQL方案，虽然牺牲了强一致（最终一致），换来了海量数据下的可运维性。不改造现有架构、不引入全量同步风险、切换过程可控。在8TB数据、MySQL 5.7、binlog position的约束下，它是最稳妥的选择。关键成功要素只有三条：半同步配置到位、binlog妥善管理、定期演练验证。

这套Orchestrator+ProxySQL方案，在保留binlog position、MySQL 5.7、8TB数据的约束下，是当前最稳妥的高可用选型。它不要求改造现有架构，避免了PXC/MGR的海量数据同步风险，切换过程可控，运维成本相对较低。半同步配置到位、binlog妥善管理、定期演练验证。做到这三点，8TB集群的自动切换完全可以落地。

收益会高出好几个数量级。贸然调大它们，尤其是在高并发环境下，很容易因为内存过度消耗把数据库实例搞崩。当 MySQL 执行连接查询（JOIN）且无法使用索引时，会为。对于绝大多数业务场景，保持默认值，然后。这是 MySQL 会话在执行。这三个参数确实重要，但都属于。操作，需要排序时，为。

别一上来就无脑改大。这几个货都是。

多数情况下，通过代理服务连接到后端 Doris 服务后，客户端 IP 信息会丢失，Doris 服务端只能获取到代理服务器的 IP 地址信息。利用这个协议，可以是实现客户端 IP 透传，从而在经过负载均衡后，Doris 依然可以获取客户端的真实 IP，实现白名单等权限控制。下面分别介绍如何在 Nginx 和 Haproxy 中开启 Proxy Protocol。列看到的真实的客户端 IP，则说明验证成功。否则，只能看到代理服务的 IP 地址。同时，在 fe.audit.log 中也会记录真实的客户端 IP。

场景推荐方案理由大型生产环境负载均衡器 + HikariCP最高稳定性，运维友好中小规模集群JDBC 负载均衡模式无需额外组件，功能足够测试/开发环境故障转移模式配置简单，满足基本高可用金融/交易系统负载均衡器 + 连接池监控需要强一致性和可观测性Spring Boot 连接 Doris 集群看似简单，但要实现真正的高可用和负载均衡，需要深入理解 Doris 的架构特性、MySQL JDBC 驱动的连接模式，以及连接池的配置调优。

用户通过 FE 的查询端口（query_port，默认 9030）使用 MySQL 协议连接 Doris。当部署多个 FE 节点时，用户可以在多个 FE 之上部署负载均衡层来实现 Doris 查询的高可用。本文档介绍多种适用于 Doris 的负载均衡方案，并介绍如何通过 Proxy Protocol 实现客户端 IP 透传。

Percona Server for MySQL 是由 Percona 公司开发的一款开源的、免费的MySQL数据库服务器分支。它完全兼容官方 MySQL，可以理解为 MySQL 的"增强版"。核心理念：在保持100%兼容性的前提下，提供更优的性能、更强的扩展性、更完善的监控指标和更丰富的企业级功能。本文全面介绍了 Percona Server 5.7 的核心特性，与 MySQL 5.7 进行了详细对比，并提供了在 CentOS 7 环境下的两种离线安装方案。

处理“tablespace和log不一致”的核心是通过绕过启动障碍，以抢救数据为首要目标，最后重建一个健康的数据库实例。由于操作风险较高，建议每一步都谨慎操作。如果在尝试过程中遇到具体的错误信息，可以随时贴出来，我们再一起分析。

是 MySQL 中一个用于在紧急情况下强制启动 InnoDB 存储引擎的调试工具。当数据库因页面损坏、数据不一致等问题无法正常启动时，你可以通过设置这个参数，暂时跳过一些自检和后台操作，让数据库以受限模式运行起来，目的是。这是一个非常危险的操作，尤其是较高数值的设置可能会导致数据永久损坏。因此，，且在生产环境使用前，。

中间件主要功能适用场景HikariCP连接池、心跳检测基础配置Druid连接池、监控、防火墙需要监控和SQL防护重试机制简单重试需求断路器、限流复杂的容错需求多数据源、读写分离主从架构分库分表、读写分离分布式数据库缓存降级读多写少场景推荐组合：HikariCP + Spring Retry + Resilience4j + dynamic-datasource + Caffeine，这个组合能提供完整的数据库容错能力。

│ 应用层重试机制 ││ 断路器熔断保护 ││ 数据源自动重建/切换 ││ HikariCP心跳检测 ││ MySQL服务监控/重启 │通过以上方案的组合实施，可以有效应对MySQL数据库的各种异常情况，最大程度保证业务系统的可用性。

【代码】Linux shell脚本案例：检测MySQL运行状态并在异常时自动重启的脚本。

是 MySQL InnoDB 存储引擎中一个，它控制着 InnoDB 如何与文件系统交互来刷新数据和日志。

传统方式负责监控和重启 MySQL现代方式：systemd 的负责重启关键区别：systemd 提供更精细的控制（重启间隔、次数限制等）最佳实践使用 systemd 管理 MySQL配置合理的重启策略和限制配合监控和告警更重要的是预防 OOM，而不是依赖自动重启最重要的一点：自动重启只是应急措施，根本解决方案是预防 OOM 发生，通过合理配置内存、禁用 overcommit、使用 cgroups 限制等手段。

对于专用 MySQL 服务器，防御 OOM 的关键顺序首要：禁用 overcommit (其次：合理配置 MySQL 内存参数，留足系统开销再次：使用 cgroups 硬限制 MySQL 总内存然后：配置适当的监控和预警最后：准备 OOM 发生后的恢复方案最根本的解决方案：确保物理内存足够，并有适当的余量（通常建议 MySQL 专用服务器上，InnoDB Buffer Pool 不超过物理内存的 75%）。

【代码】MySQL InnoDB Page Cleaner 刷脏页机制深度解析。

【代码】MySQL Page Cleaner 进程执行缓慢与 OOM Killer 的关联分析。

【代码】MySQL 服务器高 buff/cache 占用深度解析（InnoDB 缓冲池的“双缓存“问题）

https://downloads.mysql.com/archives/community5.7.44 版本下载地址：https://downloads.mysql.com/archives/get/p/23/file/mysql-5.7.44-linux-glibc2.12-x86_64.tar.gz

MySQLTuner 是一个用 Perl 编写的脚本，用于分析 MySQL 配置和性能，提供优化建议。

是 Percona Toolkit 中的一个强大工具，能够提供 MySQL 实例的全面诊断报告。这会尝试使用默认 socket 连接（这会显示每个连接的内存开销。），使用当前系统用户。

fill:#333;important;important;fill:none;color:#333;color:#333;important;fill:none;fill:#333;height:1em;所有服务挤在 dm-0 根分区高 I/O 导致 %util=100%临时表写满 /tmpInnoDB 刷脏页慢 → page_cleaner 延迟从库回放 relay log 时内存打满OOM Killer 杀死 mysqld从库自动重启主库半同步超时 → 自动降级核心教训。

1 安全，2 折中，0 快但危险”默认用1，除非你明确知道可以承担数据丢失风险。

是 MySQL InnoDB 存储引擎中的一个重要配置参数，用于控制。这个缓冲区用于在将事务日志（redo log）写入磁盘之前，临时缓存这些日志数据。

TIS 实现了多数据源端到端的数据同步，使用批量和实时增量的方式。TIS经过多年精心打造，专注用户侧使用体验，在操作界面化、流程化上下了不少功夫。TIS有别于传统大数据ETL工具，它借鉴了DataOps、DataPipeline理念，对大数据ETL各个执行流程建模，将传统的ETL工具执行以黑屏化工具包的方式（json+命令行执行）升级到了白屏化2.0的产品化方式（系统借助底层的MetaData自动生成脚本，用户只需轻点鼠标，借助系统给出的提示快速录入配置），从而大大提高了工作效率。

针对上图阿里Java开发手册中的说明，本文我来详细分析 MySQL EXPLAIN 中的type。