运维123 - 中间件
type: channel
link: https://sddts.cn/index.php/category/%E4%B8%AD%E9%97%B4%E4%BB%B6/
items: Databasus 开源数据库备份工具技术分析
items: Redis NUMA 架构下的延迟性能优化案例分析
items: MySQL主从复制搭建实战：数据同步零丢失配置指南
items: Rails 8 使用 SolidQueue 替代 Redis 架构分析
items: rabbitmq 遇到的一些问题
items: 使用ja-netfilter激活datagrip访问mongodb2.6.11
items: sql_mode导致程序无法获取数据了
items: gui 连接 mongodb2.6.11
items: 尝试CloudCanal 同步rerdis集群
items: 升级mysql云主机内存

Databasus 开源数据库备份工具技术分析
type: item
date: 2026-01-15T12:45:53+00:00
description: Databasus 开源数据库备份工具技术分析一、背景与目标1. 项目背景A. 业务场景随着云计算和容器化技术的普及，数据库备份管理成为运维工作的核心环节。传统的备份方案存在以下痛点：需要编写复杂的脚本、缺乏统一的可视化管理界面、难以支持多种数据库类型、无法灵活配置存储目标和通知渠道。B. 痛点分析操作复杂：传统方案依赖命令行工具如 pg_dump、mysqldump，需要编写自动化脚本缺乏监控：备份任务执行状态难以及时掌握，失败发现滞后存储单一：难以同时支持本地存储和多种云存储服务协作困难：团队成员无法共享备份配置和查看备份历史2. 设计目标A. 功能目标支持 PostgreSQL、MySQL、MariaDB、MongoDB 四种主流数据库提供可视化的 Web 管理界面支持多种存储后端和通知渠道支持定时备份和加密B. 非功能目标安全性：备份文件 AES-256-GCM 加密，敏感数据不暴露易用性：提供直观的 UI，支持暗色/亮色主题可靠性：支持 Docker 容器化部署，自动重启可扩展性：支持团队协作，工作空间隔离，角色权限管理二、系统架构1. 整体架构graph TB subgraph 用户层 U1[管理员] U2[成员] U3[查看者] end subgraph Databasus应用层 W[Web界面] A[API服务] S[调度器] E[加密引擎] end subgraph 数据库连接层 PG[PostgreSQL] MY[MySQL] MR[MariaDB] MO[MongoDB] end subgraph 存储层 L[本地存储] S3[S3兼容存储] GD[Google Drive] FTP[SFTP/FTP] RC[Rclone] end subgraph 通知层 EM[邮件] TG[Telegram] SL[Slack] DC[Discord] WH[Webhook] end U1 --> W U2 --> W U3 --> W W --> A A --> S S --> PG S --> MY S --> MR S --> MO S --> E E --> L E --> S3 E --> GD E --> FTP E --> RC S --> EM S --> TG S --> SL S --> DC S --> WH2. 组件说明A. Web 界面提供 RESTful API 接口支持暗色和亮色主题切换响应式设计，支持移动端访问B. 调度器支持多种调度策略：每小时、每天、每周、每月、Cron 表达式智能压缩：4-8 倍空间节省，约 20% 性能开销C. 加密引擎使用 AES-256-GCM 算法加密备份文件零信任存储：加密后的备份文件即使泄露也无法解密敏感数据加密存储，日志中不暴露三、核心功能1. 支持的数据库数据库类型支持版本PostgreSQL12, 13, 14, 15, 16, 17, 18MySQL5.7, 8, 9MariaDB10, 11MongoDB4, 5, 6, 7, 82. 定时备份策略graph LR A[调度器] --> B{调度类型} B --> C[每小时] B --> D[每天] B --> E[每周] B --> F[每月] B --> G[Cron表达式] C --> H[执行备份] D --> H E --> H F --> H G --> H H --> I[压缩] I --> J[加密] J --> K[存储] K --> L[通知]3. 存储后端支持本地存储：直接存储在服务器磁盘云存储：S3、Cloudflare R2、Google Drive、Azure Blob Storage网络存储：NAS、SFTP、FTP扩展存储：通过 Rclone 支持 70+ 种存储服务4. 通知渠道邮件：SMTP 协议即时通讯：Telegram、Slack、DiscordWebhook：自定义 HTTP 回调四、安全设计1. 加密机制A. 备份文件加密算法：AES-256-GCM适用场景：所有存储到外部服务的备份文件安全性：即使存储服务被攻破，备份文件也无法解密B. 敏感数据保护数据库凭证加密存储敏感配置不在日志中显示错误信息中不包含敏感数据2. 访问控制A. 工作空间隔离不同项目/团队使用独立工作空间工作空间间数据隔离B. 角色权限角色权限查看者仅查看备份状态和历史成员管理数据库和备份任务管理员管理工作空间内所有资源所有者完全控制，包括删除工作空间C. 审计日志记录所有用户操作记录备份任务执行历史3. 只读用户原则Databasus 默认使用只读用户连接数据库不存储任何可以修改数据的凭证备份过程不会对源数据库产生写入操作五、部署方式1. 部署架构对比graph LR subg…

Redis NUMA 架构下的延迟性能优化案例分析
type: item
date: 2026-01-15T12:25:02+00:00
description: Redis NUMA 架构下的延迟性能优化案例分析一、事件概述1. 事件背景Redis 作为核心存储组件，对实时性要求非常高。在长期运行后，Redis 服务会出现性能下降，导致较大的查询延迟，拖慢整个链路的响应速度。2. 影响范围A. 影响功能Redis 数据库的所有查询操作B. 性能指标P99 延迟从 9.2ms 降至 5.7ms，下降约 37%3. 严重程度P2 级性能问题（核心业务响应速度受影响）二、问题分析1. 直接原因通过 HUATUO 系统观测指标分析，发现 Redis 延迟升高时，NUMA 页面迁移指标（huatuo_bamai_vmstat_numa_pages_migrated）同步升高，两者趋势一致。2. 根本原因（5 Whys 分析）A. 为什么出现这个问题？Redis 进程在 NUMA 架构下，内存分散在不同的内存节点上，访问远端节点内存时触发 NUMA balancing，导致页面迁移，在 page fault 中产生额外开销。B. 为什么内存会分散？负载变化导致 Redis 进程在 node 之间迁移AOF 备份产生的文件缓存持续占用内存，导致某个 node 可用内存减少，后续分配从另一个 node 进行C. 为什么没有自动优化？内核默认的 NUMA balancing 策略旨在提高访存速度，但对内存带宽敏感型的数据库服务，页面迁移本身的开销超过了收益。3. 深层反思容器化环境下，NUMA 架构与内存管理策略需要针对不同类型的负载进行调优，通用内核参数无法满足所有场景。三、问题定位过程1. 观测指标使用 HUATUO 提供的关键指标：huatuo_bamai_vmstat_numa_pages_migrated：系统级 NUMA 页面迁移次数huatuo_bamai_vmstat_container_numa_pages_migrated：容器级 NUMA 页面迁移次数nr_inactive_file：非活跃文件缓存页数nr_active_file：活跃文件缓存页数nr_free_pages：空闲内存页数2. 指标关联分析graph TD A[Redis 延迟升高] --> B[NUMA 页面迁移指标升高] B --> C[发现关联性] C --> D[AOF 操作] D --> E[nr_inactive_file 升高] E --> F[nr_active_file 升高] F --> G[nr_free_pages 下降] G --> H[跨 node 内存分配] H --> I[NUMA balancing 触发] I --> J[页面迁移开销] J --> A3. 现象总结触发 NUMA balancing 的两个条件：A. 进程迁移随着负载变化，Redis 进程会在 node 之间迁移，导致内存分散在两个内存节点上。B. 文件缓存占用Redis 定期进行数据备份（AOF），将数据保存在文件里。这些磁盘数据写完后一般不再使用，但仍留在文件缓存中，导致某个 node 可用内存特别少。四、解决方案1. 临时方案A. 提升内存水位参数将 vm.watermark_scale_factor 设定为 1000，使内核的 low 水位被设定为总内存的 1/10。B. 效果评估kswapd 可以频繁回收文件缓存，让 free 内存保持合理水平，内存分配不会被迫横跨节点，NUMA miss 减少到接近 0。2. 永久方案A. 提升内存水位调整 vm.watermark_scale_factor 参数B. 关闭 NUMA balancing对于内存带宽敏感型的数据库服务，关闭 NUMA balance 策略C. 实施计划测试环境验证参数调整效果生产环境分批次灰度调整五、技术细节1. vm.watermark_scale_factor 参数详解A. 参数作用控制内存水位的间距，影响内核的内存回收行为，主要是 kswapd 守护进程的唤醒和睡眠时机。B. 参数特性不改变 min 水位只影响 min 水位到 low 和 high 的间距默认值为 10（对应总内存的 0.1%）取值范围为 0-3000（即 0% 到 30%）C. 计算公式WMARK_LOW = WMARK_MIN + (zone->managed_pages * vm_watermark_scale_factor) / 10000 WMARK_HIGH = WMARK_LOW + (zone->managed_pages * vm_watermark_scale_factor) / 10000D. 推荐配置vm.watermark_scale_factor=10002. NUMA balancing 策略A. 工作原理NUMA balance 调度…

MySQL主从复制搭建实战：数据同步零丢失配置指南
type: item
date: 2026-01-15T10:04:51+00:00
description: MySQL主从复制搭建实战：数据同步零丢失配置指南一、概述1. 背景介绍在生产环境中运维MySQL数据库十年，主从复制是遇到最频繁的架构需求之一。无论是为了读写分离提升性能，还是为了数据容灾保障业务连续性，主从复制都是MySQL高可用架构的基石。2019年的一次惨痛经历至今记忆犹新：某电商平台大促期间，单机MySQL扛不住流量直接宕机，由于没有从库，数据恢复花了整整6个小时，直接损失数百万。这次事故之后，主从复制成为所有核心业务数据库的标配。A. 核心原理MySQL主从复制的核心原理是：主库将数据变更写入二进制日志（Binary Log），从库通过I/O线程读取主库的binlog并写入本地的中继日志（Relay Log），然后SQL线程读取中继日志并在从库上重放这些变更，从而实现数据同步。2. 技术特点MySQL 8.0/8.4 LTS版本在复制功能上有了重大改进：A. 基于GTID的复制全局事务标识符（GTID）让每个事务都有唯一标识故障切换时自动定位复制位点，无需手动指定binlog文件和位置支持自动故障转移，大幅简化运维复杂度B. 增强的半同步复制主库提交事务前必须收到至少一个从库的确认配合rpl_semi_sync_source_wait_for_replica_count参数可要求多个从库确认有效防止主库故障时的数据丢失C. 并行复制优化基于WriteSet的并行复制，大幅提升从库回放效率replica_parallel_type=LOGICAL_CLOCK配合binlog_transaction_dependency_tracking=WRITESET实测可将复制延迟从分钟级降到秒级D. 克隆插件支持MySQL 8.0.17+引入Clone Plugin从库初始化无需mysqldump或xtrabackup自动完成数据同步和复制配置3. 适用场景场景说明推荐配置读写分离主库写、从库读，分担主库压力异步复制 + 多从库数据容灾主库故障时快速切换到从库半同步复制 + GTID数据备份在从库执行备份，不影响主库性能异步复制 + 延迟从库数据分析报表查询在从库执行异步复制 + 专用从库跨地域部署多数据中心数据同步异步复制 + 压缩传输4. 环境要求组件版本要求说明MySQL Server8.0.35+ 或 8.4 LTS推荐使用8.4 LTS长期支持版本操作系统Rocky 9 / Ubuntu 24.04内核版本5.14+内存最低4GB，推荐16GB+InnoDB Buffer Pool需要足够内存磁盘SSD，IOPS 3000+binlog和数据文件分盘存储网络主从之间延迟<1ms同机房部署最佳本文实验环境：主库：192.168.1.100（master.example.com）从库：192.168.1.101（slave.example.com）系统：Rocky Linux 9.3MySQL：8.4.0 LTS二、准备工作1. 系统环境配置在主库和从库服务器上执行相同的系统配置：# 关闭SELinux（或配置相应策略） sudo setenforce 0 sudo sed -i 's/SELINUX=enforcing/SELINUX=permissive/' /etc/selinux/config # 配置防火墙 sudo firewall-cmd --permanent --add-port=3306/tcp sudo firewall-cmd --reload # 配置时间同步（主从时间必须一致） sudo dnf install -y chrony sudo systemctl enable --now chronyd # 验证时间同步状态 chronyc tracking # 配置主机名解析 echo "192.168.1.100 master.example.com master" | sudo tee -a /etc/hosts echo "192.168.1.101 slave.example.com slave" | sudo tee -a /etc/hosts # 优化系统参数 cat << 'EOF' | sudo tee /etc/sysctl.d/mysql.conf # 网络优化 net.core.somaxconn = 65535 net.ipv4.tcp_max_syn_backlog = 65535 net.ipv4.tcp_fin_timeout = 10 net.ipv4.tcp_tw_reuse = 1 net.ipv4.tcp_keepalive_time = 600 # 内存优化 vm.swappiness = 1 vm.dirty_ratio = 10 vm.dirty_b…

Rails 8 使用 SolidQueue 替代 Redis 架构分析
type: item
date: 2026-01-14T14:47:57+00:00
description: Rails 8 使用 SolidQueue 替代 Redis 架构分析一、背景与目标1. 项目背景 A. 业务场景 Rails 8 从默认技术栈中移除了 Redis。新的功能组件——SolidQueue（任务队列）、SolidCache（缓存）、SolidCable（实时消息传递）——完全运行在应用程序现有的关系数据库服务上。对于大多数 Rails 应用，可以不再依赖 Redis。 B. 痛点分析 Redis 虽然是快速、可靠的基础设施，但它增加了系统复杂性： - 需要单独部署、版本管理、补丁和监控服务器软件 - 需要配置持久化策略（RDB 快照、AOF 日志或两者） - 需要设置内存限制和淘汰策略 - 需要维护 Rails 与 Redis 之间的网络连接和防火墙规则 - 需要配置 Redis 客户端认证 - 需要构建和维护高可用 Redis 集群 - 需要协调 Sidekiq 进程的生命周期管理 2. 设计目标 A. 功能目标 - 使用关系数据库替代 Redis 实现任务队列功能 - 支持任务调度、并发控制、重试机制 - 提供监控和管理界面 B. 非功能目标 - 降低运维复杂性 - 减少基础设施组件数量 - 保持足够的性能水平 二、Redis 运维成本分析1. 直接成本 A. 服务器部署 - Redis 服务器软件安装与配置 - 版本升级与补丁管理 - 服务器资源监控 B. 持久化配置 - RDB 快照：内存快照持久化 - AOF 日志：追加文件日志 - 混合策略：结合两者优势 2. 间接成本 A. 网络与安全 - 防火墙规则配置 - Redis 客户端认证管理 - 高可用集群部署 B. 进程管理 - Sidekiq 进程编排 - 跨部署的生命周期管理 - 进程崩溃恢复 3. 调试复杂性 当任务出现问题时，需要同时调试 Redis 和 RDBMS 两个具有不同语义的数据存储，在不同的查询语言和工具之间切换上下文。还需要维护两套独立的备份策略。 三、SolidQueue 工作原理1. 核心技术：SKIP LOCKED PostgreSQL 9.5 增强了 SQL 的 `FOR UPDATE` 子句，添加了 `SKIP LOCKED` 选项。`FOR UPDATE` 创建排他行锁，`SKIP LOCKED` 进一步跳过当前被锁定的行。 这使得基于数据库的任务队列成为可能，即使在规模化场景下也能正常工作。 2. 任务获取流程 工作进程获取任务的查询： ```sql SELECT * FROM solid_queue_ready_executions WHERE queue_name = 'default' ORDER BY priority DESC, job_id ASC LIMIT 1 FOR UPDATE SKIP LOCKED ``` 自由的工作进程始终获取下一个可用任务。 这个数据库优化解决了早期数据库队列实现面临的根本问题：**锁竞争**。工作进程从不等待另一个进程，也从不阻塞。多个工作进程可以同时查询，PostgreSQL 保证每个进程获得唯一的任务。 3. 数据库表结构 SolidQueue 架构围绕三个核心表： ```mermaid graph TD subgraph SolidQueue 数据库表结构 A[solid_queue_jobs 任务元数据表] B[solid_queue_scheduled_executions 定时任务表] C[solid_queue_ready_executions 就绪任务表] end D[新任务] -->|已调度| B D -->|立即执行| C B -->|到达执行时间| C C -->|工作进程获取| E[执行中] E -->|完成| F[删除执行记录] E -->|失败| G[失败记录表] ``` A. solid_queue_jobs 存储所有任务元数据，包括任务名称、Ruby 类、开始和结束时间戳。默认情况下，每个排队请求都会记录在此表中，并在任务完成后永久保留。 B. solid_queue_scheduled_executions 定时任务等待直到其预定时间到达。 C. solid_queue_ready_executions 准备立即运行的任务排队在此，工作进程从中获取任务。 PostgreSQL 的 MVCC 设计通过内置的 autovacuum 进程很好地处理了任务表的快速和稳定 churn（大量插入和删除）。无需特殊调优。 4. 进程架构 ```mermaid graph LR subgraph SolidQueue 进程组件 A[Supervisor 监督进程] B[Workers 工作进程] C[Dispatchers 调度进程] D[Schedul…

rabbitmq 遇到的一些问题
type: item
date: 2025-02-24T03:24:19+00:00
description: （1）内存类型 MQ 节点将队列等运行状态数据不写硬盘，不影响业务数据持久化内存节点（RAM 节点）的特点运行时状态：内存节点仅将运行时状态（如交换器、队列、绑定、虚拟主机、用户和策略的定义）存储在内存中，不会将其写入磁盘。如果内存节点崩溃或重启，这些运行时状态会丢失，需要从磁盘节点或其他节点恢复。业务数据（消息）：消息的存储方式（是否持久化）由消息的 delivery-mode 属性决定，而不是节点类型。如果消息的 delivery-mode = 2（持久化），即使是在内存节点上，消息也会被写入磁盘。如果消息的 delivery-mode = 1（非持久化），消息仅存储在内存中，节点类型不会影响这一点。磁盘节点（Disk 节点）的特点运行时状态：磁盘节点将运行时状态存储在内存和磁盘中，确保即使节点重启，这些状态也不会丢失。业务数据（消息）：同样，消息的存储方式由 delivery-mode 属性决定，与节点类型无关。总结内存节点和磁盘节点的区别仅在于运行时状态的存储方式，不会直接影响业务数据（消息）的存储。消息的持久化由 delivery-mode 属性控制，无论是内存节点还是磁盘节点，持久化消息都会被写入磁盘。如果使用内存节点，需要注意运行时状态的丢失风险，尤其是在集群环境中，建议至少有一个磁盘节点来保存集群的运行时状态。（2）关于 DURABLE，只是影响队列是否存在，与其业务数据持久化无关是的，你的理解是正确的。在 RabbitMQ 中，durable 属性仅影响队列本身的定义是否在 RabbitMQ 服务器重启后仍然存在，而与队列内部的数据（消息）是否持久化无关。durable 属性的作用队列的持久化：当 durable=True 时，队列的定义会被持久化到磁盘。即使 RabbitMQ 服务器重启，队列仍然会存在。当 durable=False 时，队列的定义仅存储在内存中。如果 RabbitMQ 服务器重启，队列会被删除。与消息持久化的区别：durable 属性仅影响队列的定义，不涉及队列中消息的存储方式。消息是否持久化由消息的 delivery-mode 属性决定：delivery-mode=1：消息非持久化，仅存储在内存中。delivery-mode=2：消息持久化，会被写入磁盘。使用场景durable=True：适用于需要长期存在的队列，例如任务队列或消息队列，确保队列定义在 RabbitMQ 重启后仍然可用。即使队列是持久的，队列中的消息仍然需要单独设置为持久化（delivery-mode=2）才能确保消息不丢失。durable=False：适用于临时队列，例如 RPC 风格的应用程序，队列的生命周期与消费者绑定，消费者断开后队列可以自动删除。注意事项如果希望消息在 RabbitMQ 重启后仍然存在，必须同时满足以下两个条件：队列是持久的（durable=True）。消息是持久的（delivery-mode=2）。如果只设置了 durable=True 而没有设置 delivery-mode=2，队列定义会保留，但消息可能会丢失。总结durable 属性仅控制队列定义的持久化，与队列内部消息的存储方式无关。为了确保消息在 RabbitMQ 重启后不丢失，需要同时设置队列为持久化（durable=True）和消息为持久化（delivery-mode=2）。（3）关于如何不落盘业务数据，需要消息中指定 delivery-mode 为 2delivery-mode 是 AMQP 协议中定义的一个消息属性，用于指示 RabbitMQ 如何处理消息的存储和持久化。它有两个可能的值：delivery-mode = 1：这是默认值，表示消息是非持久化的。RabbitMQ 会将消息保留在内存中，不会将其写入磁盘。如果 RabbitMQ 重启，这些非持久化的消息将会丢失。delivery-mode = 2：表示消息是持久化的。RabbitMQ 会将消息写入磁盘，确保即使 RabbitMQ 重启，消息仍然会保留在队列中。这种模式提供了更高的可靠性，但可能会影响性能，因为磁盘 I/O 比内存 I/O 慢。使用场景delivery-mode = 1：适用于对消息丢失不敏感的场景，例如实时日志或临时数据，可以最大限度地减少延迟。delivery-mode = 2：适用于需要确保消息不丢失的场景，例如金融交易或关键业务数据。性能影响使用 delivery-mode = 2 时，由于需要将消息写入磁盘，可能会增加发布消息的延迟，尤其是在高并发或 I/O 负载较高的情况下。如果需要更高的性能，可以结合其他优化技术，例如事务或批量确认。总结delivery-mode 是一个重要的消息属性，开发者需要根据业务需求选择合适的模式，以在消息的可靠…

使用ja-netfilter激活datagrip访问mongodb2.6.11
type: item
date: 2024-08-14T06:09:00+00:00
description: 安装datagrip，可以使用链接http://vip.123pan.cn/1815238395/download/datagrip/2024.1.5/datagrip-2024.1.5.exe使用链接https://ipfs.io/ipfs/bafybeih65no5dklpqfe346wyeiak6wzemv5d7z2ya7nssdgwdz4xrmdu6i/下载jetbra.zip文件。或者直接从这里http://vip.123pan.cn/1815238395/download/datagrip/%E6%BF%80%E6%B4%BB/jetbra-8f6785eac5e6e7e8b20e6174dd28bb19d8da7550.zip解压到datagrip的bin目录下。进入bin/jetbra/，查看readme.txtOperation guide: 1. add -javaagent:/path/to/ja-netfilter.jar=jetbrains to your vmoptions (manual or auto) 2. log out of the jb account in the 'Licenses' window 3. use key on page https://jetbra.in/5d84466e31722979266057664941a71893322460 4. plugin 'mymap' has been deprecated since version 2022.1 5. don't care about the activation time, it is a fallback license and will not expire Enjoy it~ JBR17: add these 2 lines to your vmoptions file: (for manual, without any whitespace chars) --add-opens=java.base/jdk.internal.org.objectweb.asm=ALL-UNNAMED --add-opens=java.base/jdk.internal.org.objectweb.asm.tree=ALL-UNNAMED NEW: Auto configure vmoptions: macOS or Linux: execute "scripts/install.sh" Windows: double click to execute "scripts\install-current-user.vbs" (For current user) "scripts\install-all-users.vbs" (For all users) 找到安装datagrip目录的datagrip64.vmoptions，根据上述readme.txt内容加入进去。然后启动datagrip，不要使用账号密码登录，选择激活码54H0PAD972IO7OS-[binary]-[binary]-[binary]

sql_mode导致程序无法获取数据了
type: item
date: 2024-08-13T02:12:28+00:00
description: 研发发来了一个报错，这个报错是sql_mode=only_full_group_by兼容性导致。直接修改sql_mode就可以了。com.mysql.jdbc.exceptions.jdbc4.MySQLSyntaxErrorException: In aggregated query without GROUP BY, expression #2 of SELECT list contains nonaggregated column 'xxx.bm.gid'; this is incompatible with sql_mode=only_full_group_by at sun.reflect.NativeConstructorAccessorImpl.newInstance0(Native Method) ~[na:1.8.0_152] at sun.reflect.NativeConstructorAccessorImpl.newInstance(NativeConstructorAccessorImpl.java:62) ~[na:1.8.0_152] at sun.reflect.DelegatingConstructorAccessorImpl.newInstance(DelegatingConstructorAccessorImpl.java:45) ~[na:1.8.0_152] at java.lang.reflect.Constructor.newInstance(Constructor.java:423) ~[na:1.8.0_152]临时修改## 查看 -- 开启-- 查看数据库版本和 Session级信息 SELECT VERSION(),@@sql_mode; -- 查看数据库版本和 GLOBAL级信息 SELECT VERSION(),@@GLOBAL.sql_mode; ## 关闭 -- 关闭 session级 SET SESSION sql_mode=(SELECT REPLACE(@@sql_mode,'ONLY_FULL_GROUP_BY','')); -- 关闭 GLOBAL级 SET GLOBAL sql_mode=(SELECT REPLACE(@@sql_mode,'ONLY_FULL_GROUP_BY','')); 查看线上配置修改配置文件 mysql: image: harbor.op123.ren:44301/library/mysql:5.7.35 command: --sql-mode="STRICT_TRANS_TABLES,NO_ZERO_IN_DATE,NO_ZERO_DATE,ERROR_FOR_DIVISION_BY_ZERO,NO_ENGINE_SUBSTITUTION" restart: "no" container_name: mysql environment: - MYSQL_ROOT_PASSWORD=xxx - TZ=Asia/Shanghai - SET_CONTAINER_TIMEZONE=true - CONTAINER_TIMEZONE=Asia/Shanghai # 添加性能相关的环境变量 - MYSQL_INNODB_BUFFER_POOL_SIZE=4G - MYSQL_INNODB_LOG_FILE_SIZE=256M - MYSQL_INNODB_LOG_BUFFER_SIZE=64M - MYSQL_INNODB_FLUSH_LOG_AT_TRX_COMMIT=2 - MYSQL_INNODB_FLUSH_METHOD=O_DIRECT - MYSQL_MAX_CONNECTIONS=1000 # 添加日志相关的环境变量 - MYSQL_LOG_CONSOLE=true - MYSQL_LOG_ERROR=/var/log/mysql/custom-error.log - MYSQL_LOG_QUERIES_ENABLED=true - MYSQL_LOG_QUERIES_FILE=/var/log/mysql/queries.log networks: yewu-network: ipv4_address: 192.168.177.55 cap_add: - SYS_NICE # CAP_SYS_NICE ports: - 3306:3306 volumes: - ./data/mysql/conf:/etc/mysql/conf.d - ./data/mysql/data:/var/lib/mysql - ./data/mysql/logs:/var/log/mysql - /etc/localtime:/etc/loc…

gui 连接 mongodb2.6.11
type: item
date: 2024-08-12T05:58:19+00:00
description: 昨天在V2提问mongodb2.6.11 版本在 2015 年前后比较流行，可是现在的软件不大支持老版本了。当前，我们成熟的做法是，使用 mongodb2.6.11 的 cli 版本直接命令行操作，兄弟们有啥 gui 建议么？参考大家的意见，大致试了一下，最新版本的 compass 也是可以的，最新版本的 datagrid 也是可以的。

尝试CloudCanal 同步rerdis集群
type: item
date: 2024-07-12T07:21:00+00:00
description: 线上环境使用的是redis4，2副本共6台机器，之前的几年被大key问题困扰，解决之后目前又面临部分数据节点更新较快，使得槽位所在redis实例cpu使用率高的问题。于是，继续加节点、分槽位是一个不错的解决方案。不过由于是给线上环境更换，如何进行数据同步也是一个面临的问题。在测试环境中，部署有redis集群，一开始使用的版本是redis 4.1.1，然后升级到6.2.10，然后进行了一次手动分片，目前是6个节点，4个master。然后，手头刚好有一个redis6.2.10的2副本集群，可以进行CloudCanal尝试了。部署打开首页https://www.clougence.com/。点击下载私有部署，选择“容器部署”，X86版本。上传到服务器后，直接解压，运行install_on_docker下面的install.sh。注意：我在2024年7月12日下载的版本当前还有bug，主要表现为第一次安装后，打开页面http://192.168.124.28:8111后，使用账号密码无法登录。然后，使用uninstall.sh卸载重新sh install.sh一遍可以了。登录打开http://192.168.124.28:8111后，先登录。账号: test@clougence.com密码: clougence2021默认验证码: 777777然后是激活，激活的时候当前版本有个bug，激活了4遍才通过。而且重启服务后激活会消失，再次激活一次就可以了。使用这次是测试redis 4个槽位节点到另一个redis节点的数据同步。测试老的1个节点到新的1个节点，任务运行后发现数据有缺失。于是，一口气把4个槽位的节点分别建立一个任务，然后目标redis节点还是写同一个也没有问题。最后，数据同步成功。注意：在测试过程中，每个任务消耗2GB内存，当前云主机只有8GB，把内存升级到12GB后，第4个任务也可以正常运行了。最后数据同步成功。参考https://www.clougence.com/cc-doc/productOP/docker/install_linux_macos

升级mysql云主机内存
type: item
date: 2024-07-09T09:32:00+00:00
description: 以下三条线分别是：max used、connected、aborted数据。刚刚升级内存由4GB到8GB后，可以看到max used和connected基本持平，而过了2个小时后，aborted数据上升了。而且，这边程序报超时确实少了，几乎没有了。在 MySQL 的状态指标中，max used、connected 和 aborted 这三个指标的意义如下：max used：表示从 MySQL 服务启动以来，同时使用的连接的最大数量。它给出了连接使用的高峰值，可以用来评估服务器的连接资源是否足够。如果 max used 接近或达到了 max_connections 的限制，说明连接资源可能不足，需要考虑增加 max_connections 的值。connected：表示当前已建立的连接数量，包括空闲连接和正在使用的连接。它反映了当前服务器的连接负载情况。如果 connected 持续接近 max_connections 的限制，可能表示连接资源紧张，需要优化连接的使用或增加资源。aborted：表示异常中断的连接数量，包括客户端异常断开和服务器主动关闭的连接。aborted 分为两个指标：aborted_clients：由于客户端没有正常关闭连接而导致连接中断的数量。aborted_connects：尝试与服务器建立连接但失败的次数。较高的 aborted 值可能表示网络问题、客户端程序错误或服务器资源不足等问题。通过监控这些指标，可以了解 MySQL 服务器的连接使用情况和异常情况，从而进行性能优化和问题诊断。如果 max used 接近 max_connections，可以考虑增加 max_connections 的值。如果 connected 持续较高，可以优化连接的使用，如使用连接池、减少长时间空闲连接等。如果 aborted 较高，需要排查网络问题、客户端程序的连接处理是否正确，以及服务器资源是否充足。定期监控这些指标，并根据实际情况进行调整和优化，可以确保 MySQL 服务器的连接资源得到合理利用，并提供稳定的服务。