PostgreSQL 慢查询日志的所有参数均在 postgresql.conf 中配置,分为日志开关控制、慢查询阈值、日志内容、日志文件轮转、日志存储路径五大类,附生产推荐值与作用说明。 一、基础日志总开关(必须开启才能记录慢 SQL) 1. logging_collector ini loggin
PostgreSQL 性能优化遵循先定位瓶颈 → 基础配置调参 → 索引优化 → SQL 改写 → 表结构 / 存储优化 → 架构与运维优化的完整流程,下面分模块拆解每一步核心动作、实操手段与判断标准。 一、第一步:瓶颈定位(优化前提,无监控不调优) 优化前必须先找到慢的根源,禁止盲目改参数、加索引
前后端分离的核心矛盾:前端灵活多变的交互需求 vs 后端稳定、高性能、易维护的数据服务。高效 API 设计围绕「规范统一、性能最优、开发提效、可观测、易扩展」五大目标落地,下面分模块给出可直接落地的标准方案。 一、基础全局规范(统一标准,减少前后端沟通成本)
一、核心前置认知 1. 镜像标签(Tag)本质 Docker 镜像由镜像 ID(sha256 哈希) 唯一标识,Tag 只是给镜像哈希起的别名;一个镜像可绑定多个 Tag,一个 Tag 同一仓库只能绑定一个镜像,直接覆盖旧镜像,这是版本混乱的根源。 2. 版本管理核心目标
场景说明 我的服务器环境说明:Debian11,Docker 数据目录 /var/lib/docker,磁盘已满;目标分区 /tzdata(已提前挂载,空间充足)。 ⚠️重要前提:Docker 不能不停机直接迁移。运行状态拷贝文件一定会造成容器文件损坏、数据库数据丢失。只能:在线先预同步 → 短时停
Apache Flink 所有通信底层均基于TCP,仅REST/WebUI封装了HTTP/HTTPS应用层协议;分为外部对外接口、集群内部 TCP 私有接口、扩展网关接口三大类,仅 REST、SQL Gateway 可人为对外暴露,其余内部端口严禁对公网开放。 一、对外可暴露:HTTP/REST 系
下面分轻量组件、完整网关框架、嵌入式服务三类,全部开源,原生支持路径重写、端口转发、负载均衡、请求转发,对标 Nginx rewrite、proxy_pass、location 能力。 一、完整 API 网关(生产首选,功能对标 Nginx)
Nginx 路径重写rewrite 与 端口转发proxy_pass核心区别: rewrite:URL 路径重写、地址跳转,改浏览器地址栏,侧重路径 / 域名规则修改; 端口转发(proxy_pass 反向代理):请求转发到后端服务,浏览器地址不变,侧重跨机器 / 跨端口分发流量。 一、基础定义与作
一、前置基础 1. 核心概念 索引 (index):类似数据库表 文档 (document):类似数据库行,JSON 格式 字段 (field):类似数据库列 分词器 (analyzer):全文检索核心,把中文 / 英文拆成词条用于匹配 倒排索引:ES 底层结构,实现高速全文模糊、关键词匹配
Apache Flink CDC 的数据同步传输协议需要分三层来看,整体以 TCP 协议为核心,并非 HTTP: 一、数据采集层(Source 端:CDC 读取数据库) Flink CDC 内置 Debezium 引擎,直接与源数据库建立长连接读取变更日志,底层均为 TCP 协议,但不同数据库使用各
核心目标:别人拿到 U 盘后,无法完整拷贝、无法二次分发、操作全程可追溯、过期自动失效,分个人简易方案、中端文档权限管控、企业级硬件 + 软件闭环、高密涉密硬件 U 盘四层落地,由浅入深。 一、基础兜底:U 盘存储层加密(先锁底层,拷贝走也是乱码)