ITPub博客

【实战排错】Docker网桥诡异网络问题：MySQL VIP漂移后容器突然无法连接数据库本文适用场景：Docker默认bridge网桥、数据库VIP主从漂移、MySQL白名单鉴权失败、容器跨主机网络异常故障特征：业务零配置变更，仅MySQL VIP发生主机漂移，Docker容器访问数据库从正常变为权限拒绝，物理机访问完全正常。一、故障环境与问题现象1.1 现场基础环境MySQL服务节点（宿主机A）

前言在企业域架构 SQL Server AlwaysOn 可用性组运维中，绝大多数 AG 采用域账号启动 SQL 服务 + Windows Kerberos 认证架构。一旦旧域账号存在密码泄露、权限冗余、账号生命周期到期，就必须完成「旧账号下线、新账号全量替换」的高危变更。该操作属于生产高危运维动作，大量 DBA 长期踩坑，核心误区集中在以下 5 点：1、误以为「改密码需要重启、换账号不用重启」；

前言在云原生时代，Kubernetes 已经成为容器编排的事实标准。而 kubeadm 作为官方提供的集群部署工具，是新手入门和搭建生产集群最推荐的途径之一。本文将基于 Kubernetes v1.28，带你从零开始，完成一个3节点控制平面（HA） 集群的搭建。内容涵盖系统前置配置、容器运行时安装、集群初始化、证书延长、网络插件部署，以及节点加入的全流程。环境概览OS：Linux (CentOS

一、背景在微服务架构中，Redis Cluster凭借其高可用、数据分片的特性，成为缓存层的首选方案。然而，我们在生产环境中发现了一个棘手的问题：当Redis集群在发生主从切换或某个节点宕机时，基于Spring Boot 2.x的应用会陷入“连接拒绝”的异常泥潭，业务操作被阻塞，无法自动恢复。本文将从问题现象、根因分析到多种解决方案，完整记录这一问题的排查与解决过程。二、问题现象应用日志报错1：L

一、什么是自适应哈希索引？自适应哈希索引 是 InnoDB 在内存中基于 B+Tree 索引的常用搜索模式，自动创建并维护的一个哈希索引，可以理解为索引的索引。它使用哈希表数据结构。对于等值查询，哈希表的查询时间复杂度是 O(1)，而 B+Tree 是 O(log n)。因此正常情况下，它的速度会更优，并且仅支持等值查询，范围、模糊、排序场景仍走原 B+ 树 关键点：自适应： 哈希索引不是由 DB

一、现象：目标是想搭建dg库，但是该数据库数据量比较大，将近5T，故需要使用rman备份恢复的方式来搭建， 于是先在主库做了全备，然后在dg库做恢复，restore成功后，尝试recover报错，说某个文件需要restore, 然后查看该文件状态发现报错：WRONG FILE NUMBER1、数据文件备份方式如下：RUN {  ALLOCATE CHANNEL c

一、rabbitmq选型背景：我们有个业务，业务特点是需要顺序消费队列消息，并且对可靠性和低延迟有高要求，同时我们的业务消息量不大，每秒2000以内，于是我们调研后选择rabbitmq来作为消息队列的载体，本片记录下，搭建的过程，后续会陆续更新，核心原理和设计理念二、rabbitmq普通集群搭建过程：1. 准备服务器 ：选择二台或多台服务器，配置尽量相同，如 CPU、内存、磁盘等。2. 安装 Er

一、rabbitmq的设计理念：1、RabbitMQ主要设计用于消息的可靠传递和快速消费，而不是作为长期数据存储解决方案。它的核心功能是确保消息能够高效地从生产者传递到消费者，并在消息被消费后尽快释放资源。2、高吞吐量与低延迟：基于Erlang的并发模型，单节点可处理数千至数万条消息/秒，集群模式下可线性扩展，满足高并发场景；3、内存优先：RabbitMQ在处理消息时，优先将消息存储在内存中，以提

本文介绍下MySQL 5.7中针对主从并行复制的演变过程，首先MySQL主从延迟是一个永远都无法彻底解决的问题，我们只能通过优化参数来减小延迟，其中一个大的问题是主库可以并发执行事务，但是从库无法完全按着主库的并发度来并行复制，好在MySQL官方也在不断优化主从复制的逻辑，旨在提高从库并行复制的粒度，首先MySQL 5.6支持库级别的并行复制，MySQL 5.7 开始支持基于组提交的COMMIT_

一、observer内存限制；1、 OBServer 可用的总内存大小限制：memory_limit 的默认值为 0。如果该值不为 0，则系统会忽略 memory_limit_percentage 的设置而优先使用 memory_limit 配置的值。例如，一台物理机的内存为 100 GB，memory_limit_percentage 设置为 80，表示使用 80% 的内存，而 memory_l

首先查看配置项：sys 租户和所有用户租户均可以使用 SHOW PARAMETERS 语句或视图 GV$OB_PARAMETERS 查询该配置项，如下所示：方式1：root@10.1.150 : (none) 21:31:44>show  parameters   like   'log_disk_size'; +-------+-------

问题现象：日志盘(clog)满，导致集群出现问题：收到磁盘告警，业务报错，无法执行写入和更新的SQL，无法选举和缺副本等问题处理过程：第一步：根据告警及现象，判断出现问题的租户；oceanbase的日志盘是预分配的，并且集群级别可以设置每个observer上的所有的租户可用的日志盘总和，并且可以根据实际情况配置每个observer为不同的值。第二步：通过如下SQL查看对应租户log_disk使用情

前言：我们知道oceanbase的日志盘是预分配的，这一点给Oracle类似，那么oceanbase是分布式数据库，该如何配置oceanbase日志盘空间大小呢？可以给不同的observer节点设置不同的值吗？答案是可以的。一、oceanbase可用日志盘大小：1、配置项log_disk_size：1.1、配置项含义：log_disk_size 用于设置 Redo 日志磁盘的大小，即本 OBSer

MySQL主从架构故障切换，如何保证数据一致性？或者说如何最大化的保证数据不丢失？可以通过那些配置来提升一致性？dba都知道我们需要设置增强半同步(after_sync)来保证数据一致性，那只设置半同步就可以了吗？一、先看下事务执行流程（AFTER_SYNC半同步模式）1、客户端发起事务：客户端执行 SQL 语句并提交事务，注意只是进入两阶段的提交阶段，但是并没有提交成功，但是binlog已经写完

一、场景：MySQL有个一个大查询，需要返回很大的一个数据量，例如返回20g的结果集数据，针对这个场景该怎么从DB和OS参数层面优化呢？二、MySQL数据库查询结果数据发送流程：首先，服务端并不需要保存一个完整的结果集。取数据和发数据的流程是这样的：获取一行，写到 net_buffer 中。这块内存的大小是由参数 net_buffer_length 定义的，默认是 16k。重复获取行，直到 net

如何保证kafka集群不丢数据？1、正确设置replication.factor参数topic 设置 replication.factor 参数值大于 1，要求每个 partition 必须有至少 2 个副本；replication.factor 是 Kafka 中的一个关键配置，它决定了一个 topic 的分区需要被复制到多少个 broker 上。这个参数在创建 topic 时需要指定，并且在

一、添加tracker节点1、新机器安装tracker服务0）安装需要的依赖包yum -y install make zlib zlib-devel perl gcc gcc-c++ libtool pcre pcre-devel  openssl openssl-devel1）下载安装libfastcommon注意  fastdfs的版本包要和libfastcommon版本对

一、背景测试环境fastdfs就一个节点（tracker和storage在一个机器上），并且这个服务器cpu故障，随时可能重启，所以要迁移测试环境fastdfs到另一个台机器，或者添加storage节点实现高可用；需要先了解下fastdfs的基本架构和原理；二、fastdfs体系结构注释：如下所示的client并非fastdfs架构中的一个服务，java服务需要访问fastdfs,那么java服务

一、故障报错：无法为数据库 'BPMCloud_Log' 中的对象 'dbo.T_Log_Manage'.'IX_T_Log_Manage_32' 分配空间，因为 'PRIMARY' 文件组已满。请删除不需要的文件、删除文件组中的对象、将其他文件添加到文件组或为文件组中的现有文件启用自动增长，以便增加可用磁盘空间。Could not

一、在线迁移方式：方式1：通过集群添加新节点、下架旧节点的方式完成迁移；业务连续性：在某些情况下，通过逐步添加新节点并下架旧节点的方式，可以确保业务在迁移过程中的连续性，减少停机时间。自动分片迁移：Elasticsearch集群具有自动分片迁移的能力，当新节点加入并稳定后，集群会自动将部分数据迁移到新节点上，从而减轻旧节点的负载。减少数据丢失风险：由于数据在迁移过程中是实时同步的，因此减少了数据丢