运维派

达梦数据库教程（16）审计规则介绍与配置

Thu, 09 Jul 2026 15:19:29 +0800

一、达梦数据库审计功能介绍

数据库审计功能的主要作用是对数据的操作进行记录，比如谁在什么时间、通过什么IP、执行了什么SQL。只有当配置了合理的审计规则后，才能对异常数据（如数据不知道为什么被删除或修改）进行追溯。

达梦数据库采用三权分立设计，必须需要专门的审计账号 SYSAUDITOR 才能进行审计配置（SYSDBA 账号也没有权限）。SYSAUDITOR 账号在完成数据库安装后会默认创建，默认密码 SYSAUDITOR

二、达梦数据库审计配置

1、开启审计功能

DM8 的审计功能默认是关闭的，需登录 SYSAUDITOR 账号开启。达梦数据库的审计分为普通审计和实时检测，实时检测比较少用，主要用于安全防护，可在操作发生时自动告警、断开连接甚至锁账号

-- 开启普通审计，默认0为关闭审计；1为开启普通审计；2为开启普通审计 + 实时检测
SP_SET_ENABLE_AUDIT(1);

-- 验证是否生效
SELECT * FROM V$DM_INI WHERE PARA_NAME = 'ENABLE_AUDIT';

2、审计规则配置

达梦数据库支持三个级别的审计规则，从粗到细依次为系统级、语句级、对象级。

2.1 系统级审计

审计功能开启后自动生效，无需额外配置，审计内容包含数据库启停、参数修改、主备日志传输故障等系统事件

2.2 语句级审计

针对某类 SQL 操作进行审计，全局生效，适合需要全实例覆盖的场景

-- 语法规则
-- SP_AUDIT_STMT('审计选项', '用户名', 'ALL/SUCCESSFUL/FAIL');    如果不限定用户，第二个参数应该传字符串 'NULL'，而不是真正的 NULL

-- 审计所有用户的登录登出
SP_AUDIT_STMT('CONNECT', 'NULL', 'ALL');

-- 审计所有用户的 DML 操作
SP_AUDIT_STMT('INSERT TABLE', 'NULL', 'ALL');
SP_AUDIT_STMT('UPDATE TABLE', 'NULL', 'ALL');
SP_AUDIT_STMT('DELETE TABLE', 'NULL', 'ALL');

-- 审计所有用户的 DDL 操作
SP_AUDIT_STMT('TABLE', 'NULL', 'ALL');

-- 审计某个用户的操作
SP_AUDIT_STMT('UPDATE TABLE', 'APPUSER', 'ALL');
-- 取消审计，参数必须与设置时完全一致才能取消
SP_NOAUDIT_STMT('INSERT TABLE', 'NULL', 'ALL');

2.3 对象级审计

精确到具体的表、视图或存储过程，可进一步细化到列级别，适合对核心业务表做重点审计

-- 语法规则
-- SP_AUDIT_OBJECT('操作', '用户', '模式', '对象名', '时机');
-- SP_AUDIT_OBJECT('操作', '用户', '模式', '对象名', '列名', '时机');

-- 审计所有人对 HR.SALARY 表的 INSERT 和 UPDATE
SP_AUDIT_OBJECT('INSERT', 'NULL', 'HR', 'SALARY', 'ALL');
SP_AUDIT_OBJECT('UPDATE', 'NULL', 'HR', 'SALARY', 'ALL');

-- 只审计 AMOUNT 列的修改
SP_AUDIT_OBJECT('UPDATE', 'NULL', 'HR', 'SALARY', 'AMOUNT', 'ALL');

-- 取消对象级审计（参数同样需完全匹配）
SP_NOAUDIT_OBJECT('INSERT', 'NULL', 'HR', 'SALARY', 'ALL');

3、审计日志管理

3.1 审计日志存放路径

默认存放在数据目录中，文件命名格式为 AUDIT_<GUID>_<创建时间>.log

-- 查看审计文件实际存放路径
SELECT AUD_PATH FROM V$AUDIT_SPACE;

-- 查看所有审计文件列表
SELECT FILEPATH, BEGIN_TIME, LENGTH/1024/1024 AS SIZE_MB, IS_FULL FROM V$AUDIT_FILE ORDER BY BEGIN_TIME DESC;

如需自定义日志存放路径，修改 dm.ini

# 静态参数，修改后需重启
AUD_PATH = /data/dm_audit

3.2 审计日志相关参数配置

以下参数都在dm.ini中进行配置，部分静态参数需要重启数据库生效

· AUD_PATH：审计文件存放路径

· AUDIT_MAX_FILE_SIZE：单个审计日志的最大大小，单位为MB

-- 调整单个审计文件的大小为 500MB
SP_SET_PARA_VALUE(1, 'AUDIT_MAX_FILE_SIZE', 500);

· AUDIT_SPACE_LIMIT：审计日志可以占用的最大磁盘空间，单位为MB，0表示不限制

-- 查看当前审计空间用量
SELECT AUD_PATH, AUDIT_MAX_FILE_SIZE, AUD_SPACE_LIMIT,AUD_SPACE_FREE, AUDIT_IS_NORMAL FROM V$AUDIT_SPACE;

· AUDIT_KEEP_DAYS：审计文件最小保留天数，如果配置了具体天数，优先级大于AUDIT_SPACE_LIMIT，即达到审计文件总存储空间大小的限制也不会删除在指定保留天数内的审计日志

· AUDIT_FILE_FULL_MODE：磁盘不足时对审计日志的处理策略，1=当审计文件创建失败时发生阻塞；2=审计文件创建失败时不再审计；3=先尝试删除符合条件的审计文件，如果删除后还是创建失败则不再审计

3.3 清理与切换审计日志

-- 删除指定时间点前的审计文件，受 AUDIT_KEEP_DAYS 保护的文件不会被删除
SP_DROP_AUDIT_FILE('2026-07-01 00:00:00',0);

-- 手动切换审计文件（生成新文件），1=切换普通审计文件，2=同时切换普通+实时审计文件
SP_SWITCH_AUDIT_FILE(1);

3.4 查看审计记录

-- 查看最近的审计记录
SELECT USERNAME, OPERATION, SCHNAME, OBJNAME,SQL_TEXT, SUCC_FLAG, OPTIME, IP
FROM SYSAUDITOR.V$AUDITRECORDS
ORDER BY OPTIME DESC;

-- 按用户过滤
SELECT USERNAME, OPERATION, SQL_TEXT, OPTIME
FROM SYSAUDITOR.V$AUDITRECORDS
WHERE USERNAME = 'APPUSER'
ORDER BY OPTIME DESC;

Oracle教程（6）SGA\PGA\REDO核心参数调优

Wed, 01 Jul 2026 10:16:42 +0800

一、Oracle核心参数介绍

1、SGA

SGA（System Global Area）是 Oracle 实例启动时分配的共享内存区域，所有连接到该实例的会话都共用这块内存，是整个数据库实例对外提供服务的公共内存池（和 MySQL的 InnoDB Buffer Pool 类似）。SGA主要包含以下部分：

· Shared Pool：用于缓存 SQL 解析结果、执行计划和数据字典信息

· Buffer Cache：用于缓存数据块，减少物理读

· Redo Log Buffer：用于临时存放尚未写入磁盘的重做日志条目。

Oracle 的 SGA 是集合体，而 MySQL 的内存管理相对分散，Buffer Pool、Sort Buffer、Join Buffer 等是各自独立配置的参数，没有一个统一的实例级共享内存区概念

2、PGA

PGA（Program Global Area）是 Oracle 实例中每个进程或会话所私有的内存区域，每个区域不与其他会话共享。主要用于排序操作、哈希连接等需要临时空间的操作。当一个会话 ORDER BY、GROUP BY 或者大表之间的 HASH JOIN 时，如果数据量超过 PGA 能提供的内存上限，就会发生排序溢出到磁盘，导致性能下降。在 MySQL 中与之对应的是每个连接独立分配的 sort_buffer_size、join_buffer_size、tmp_table_size 等参数。

3、REDO LOG

在 Oracle 中 REDO LOG 和 MySQL 一样都是通过重做日志记录数据库所有数据变更操作的"重放记录"，这样可以在实例崩溃后，通过 Redo Log 可以把数据恢复到崩溃前的状态，保证事务的持久性。在 MySQL 中 REDO LOG 是循环覆盖写入的，而 Oracle 采用多个日志组循环写入的机制，当一个日志组写满后会触发日志切换（log switch），同时触发增量检查点（checkpoint），把脏数据写回数据文件。如果日志组设置过小，会导致切换过于频繁，对性能造成明显影响。

Oracle 的 REDO LOG 搭配归档日志（归档日志是 Redo Log 切换后被复制保存的历史副本）来实现时间点恢复，也就是说 Oracle 用 REDO LOG 兼顾实例恢复和时间点恢复两个目的，而 MySQL 把这两个职责拆成了 REDO LOG （实例恢复）和 Binlog（时间点恢复、主从复制）两套独立的日志系统。

二、Oracle内存管理方式介绍

Oracle 提供了三种内存管理方式

管理方式	关键参数	适用场景
AMM自动内存管理	MEMORY_TARGET	不推荐
ASMM自动共享内存管理	SGA_TARGET + PGA_AGGREGATE_TARGET	生产环境推荐
手动管理	逐项指定各子池大小	对内存有精细控制需求时

之所以不推荐通过 AMM 方式来自动进行内存管理，是因为通过 MEMORY_TARGET 自动管理 SGA + PGA听起来方便，但由于 AMM 模式在高并发场景下会频繁的出现内存移动，反而增大了性能开销

1、SGA配置最佳实践

通常建议 SGA 总量不超过服务器物理内存的 60%，剩余部分留给 OS、PGA 以及其他进程

-- 查看当前 SGA 配置
SHOW PARAMETER SGA;

-- 设置 SGA_TARGET，让 Oracle 在这个总量内自动分配各子池
ALTER SYSTEM SET SGA_TARGET=8G SCOPE=SPFILE;
ALTER SYSTEM SET SGA_MAX_SIZE=8G SCOPE=SPFILE;

-- 设置 Shared Pool 子池最小值，防止 AMM/ASMM 压缩得过小出现ORA-04031共享池耗尽的情况
ALTER SYSTEM SET SHARED_POOL_SIZE=2G SCOPE=SPFILE;

子池参考比例（以 16G SGA 为例）：

· Buffer Cache：10～12G ，SGA 里占比最大，越大越好。命中率低于 95% 就需要考虑加大 Buffer Cache，正常生产环境应该维持在 98% 以上

-- 查询 Buffer Cache 命中率
SELECT ROUND((1 - (phys.value / (cur.value + con.value))) * 100, 2) AS "Buffer命中率%" FROM v$sysstat phys, v$sysstat cur, v$sysstat con
WHERE phys.name = 'physical reads' AND cur.name  = 'db block gets' AND con.name  = 'consistent gets';

· Shared Pool：2～4G，OLTP 系统多，SQL 复杂度高则需要更大。硬解析率超过 30% 就需要排查是否 Shared Pool 太小，或应用层没有使用绑定变量

-- 查询 Shared Pool 的硬解析率
SELECT ROUND(hard.value / parse.value * 100, 2) AS "硬解析率%" FROM v$sysstat hard, v$sysstat parse
WHERE hard.name = 'parse count (hard)' AND parse.name = 'parse count (total)';

· Large Pool：512M～1G，RMAN、并行查询、Shared Server 使用

· Redo Log Buffer：128M～256M，一般不需要特别大，写满即刷盘

2、PGA配置最佳实践

高并发场景下 PGA 的总消耗是所有活跃会话 PGA 之和，所以在估算服务器内存分配时，不能忽略这块消耗。通用经验是PGA_AGGREGATE_TARGET = 物理内存 × 20%，如果是以批量处理、数据仓库为主的系统可以提高到 30%，OLTP 系统则适当降低。

-- 查看当前 PGA 配置
SHOW PARAMETER PGA;

-- 设置 PGA 总目标值（Oracle 会尽可能在此范围内为各会话分配内存）
ALTER SYSTEM SET PGA_AGGREGATE_TARGET=4G SCOPE=SPFILE;

-- 设置 PGA 硬上限，防止撑爆内存，超过后 Oracle 会强制终止消耗最多 PGA 的会话，生产环境建议设置为 PGA_AGGREGATE_TARGET 的2倍
ALTER SYSTEM SET PGA_AGGREGATE_LIMIT=8G SCOPE=SPFILE;

排查 PGA 是否成为瓶颈，如果sorts (disk) 磁盘排序次数过高，说明 PGA 不够用

SELECT name, value FROM v$sysstat WHERE name IN ('sorts (memory)', 'sorts (disk)');

3、REDO LOG配置最佳实践

Redo Log 最常见的问题就是日志组太小导致切换过于频繁。Oracle 官方建议最少保留 3 组日志组（高并发写入场景 4～6 组），日志切换频率控制在每 15～30 分钟一次，如果每小时切换次数超过 4 次就需要考虑扩大日志组。如果发现某些高峰时段每小时切换次数很高（如 50MB 大小的日志组每小时上百次切换），就需要立即扩大日志组大小

-- 查看当前切换频率
SELECT TO_CHAR(first_time, 'YYYY-MM-DD HH24') AS hour,COUNT(*) AS switches FROM v$log_history WHERE first_time > SYSDATE - 1
GROUP BY TO_CHAR(first_time, 'YYYY-MM-DD HH24') ORDER BY 1;

日志组大小参考，注意这里是单个日志组大小，不是所有组加起来的总量。

系统类型	推荐单个日志组大小
轻量 OLTP	500M～1G
中等业务量	1G～2G
高并发 / 批量写入	2G～4G

新增日志组

日志组大小不允许直接修改，只能新增更大的日志组，再删掉原来小的，操作顺序如下

-- 第一步：新增日志组，指定序号和日志路径、日志大小
ALTER DATABASE ADD LOGFILE GROUP 4 '/u01/oradata/orcl/redo04.log' SIZE 1G;
ALTER DATABASE ADD LOGFILE GROUP 5 '/u01/oradata/orcl/redo05.log' SIZE 1G;
ALTER DATABASE ADD LOGFILE GROUP 6 '/u01/oradata/orcl/redo06.log' SIZE 1G;

-- 第二步：手动触发切换，让旧日志组变为 INACTIVE 状态
ALTER SYSTEM SWITCH LOGFILE;
ALTER SYSTEM CHECKPOINT;

-- 第三步：确认旧日志组状态为 INACTIVE
SELECT group#, status, members, bytes/1024/1024 AS mb FROM v$log;

-- 第四步：删除状态为INACTIVE的旧日志组
ALTER DATABASE DROP LOGFILE GROUP 1;
ALTER DATABASE DROP LOGFILE GROUP 2;
ALTER DATABASE DROP LOGFILE GROUP 3;

-- 第五步：删除操作系统上的旧日志文件（Oracle 不会自动删除物理文件）
rm /u01/oradata/orcl/redo01.log

Linux时间同步——chrony的配置与使用

Mon, 22 Jun 2026 14:50:18 +0800

一、chrony 工具介绍

chrony 相比 ntpd 服务而言是更现代的NTP时间同步方案，它的同步算法更激进，在服务启动几分钟后就能达到较高精度，并且可以对偏差较大的服务器进行强制同步（在 ntpd 下如果偏差超过 1000 秒会直接退出同步而不是强制校正）。仍然需要强调的是chrony和ntpd不能同时运行，它们会互相冲突抢占 UDP 123 端口

二、chrony 使用教程

1、安装chrony

yum install -y chrony

2、配置chrony

chrony 的主配置文件为 /etc/chrony.conf，以下是常用配置项说明：

# 指定上游 NTP 服务器，iburst 表示启动时快速发送多个请求加速初始同步
server 10.1.18.114 iburst
server ntp.aliyun.com iburst

# 允许内网客户端向本机同步（本机作为内网 NTP 服务器时启用）
allow 192.168.1.0/24

# 当无法连接外部 NTP 时，允许系统作为自身时钟源
local stratum 10

# 记录时钟漂移信息，用于断网后的时钟估算
driftfile /var/lib/chrony/drift

# 启用日志记录
logdir /var/log/chrony
log measurements statistics tracking

3、启动chrony服务

systemctl start chronyd
systemctl enable chronyd

4、查看同步源

通过chronyc sources -v可以查看同步源信息，主要观察同步源的状态

*：当前同步源

+：可用候选源

?：不可达或未响应

x：被标记为异常的源

 chronyc sources -v

5、查看同步状态

chronyc tracking

Reference ID    : 0A011272 (10.1.18.114)             #当前同步的上游时间源 
Stratum         : 2                                  #时间源层级，数字越小越精确  
System time     : 0.000001690 seconds fast of NTP time    #本地时钟与 NTP 时间的偏差  
Last offset     : +0.000002484 seconds
RMS offset      : 0.000368575 seconds
Leap status     : Normal                             #Normal 表示同步正常

6、手动强制同步

chronyc makestep

Linux时间同步——ntpd的配置与使用

Mon, 22 Jun 2026 14:04:55 +0800

一、NTP时间同步介绍

NTP是网络时间协议 Network Time Protocol 的简称。通过 NTP 服务可以确保不同设备或者服务之间的时间一致性，尤其是一些高可用或集群化的服务，节点之间的时间偏差是不允许有误差的。在互联网上有许多可靠的共用NTP服务器，如清华、阿里等，我们可以通过与这些服务器同步使本地服务器间的时间一致、准确。在 CentOS 7 或之前的系统中默认使用 ntp 作为默认的时间同步方案，在 CentOS 7 之后改为 chrony，两者不可同时运行。

二、ntpd使用教程

1、安装NTPD服务

只需要通过yum命令就可以快速安装NTP相关工具包，安装完成后系统会产生以下几个主要工具：

· ntpd：NTP 守护进程，在后台运行，负责持续进行同步时钟

· ntpq：用于查看NTP同步状态和时间源信息

· ntpdate：手动同步工具，常用于首次校时或偏差过大时的强制纠偏

· ntpstat：显示当前同步状态

yum install ntp

2、NTP手动同步配置

通过ntpdate命令并指定ntp服务器地址后可以进行手动同步，如手动配置与阿里云NTP同步

ntpdate ntp.aliyun.com

3、NTP自动同步配置

编辑NTP配置文件，具体内容如下

# 记录系统时钟频率漂移值
driftfile /var/lib/ntp/drift  

pidfile /var/run/ntpd.pid
logfile /var/log/ntp.log

# 安全策略：默认拒绝所有非本地访问
restrict default kod nomodify notrap nopeer noquery
restrict -6 default kod nomodify notrap nopeer noquery

# 允许本地回环地址用于状态查询
restrict 127.0.0.1 nomodify
restrict ::1 nomodify

# 本地伪时钟源，作为兜底时间源
server 127.127.1.0
fudge 127.127.1.0 stratum 10

# 实际 NTP 上游服务器
server ntp.aliyun.com iburst minpoll 4 maxpoll 10

启动NTP服务后客户端会立即进行一次同步，并且会周期性地与服务器进行时间同步，通常为每隔1小时进行一次时间同步，具体频率可以通过配置进行调整。需要注意的是ntpd 有一个内置保护机制，如果服务器与NTP时间相差超过1000 秒，ntpd 会主动退出而不是强制校正。如果要重新与服务器进行同步，必须先用 ntpdate 进行一次手动同步将时间拉近后再启动 ntpd 才能自动同步

systemctl start ntpd

4、查询同步状态

通过ntpstate或者ntpq命令可以查看NTP服务器同步是否正常：

* 号表示当前已选用的服务器；reach列如果不为0表示能访问服务器；offset 表示本地时间与服务器差值（ms）

 ntpq -p
     remote           refid      st t when poll reach   delay   offset  jitter
==============================================================================
*203.107.6.88    100.107.25.114   2 u   11   16    1   59.353   -0.896  15.879

查看服务器是否启用NTPD

timedatectl

Ansible教程（3）使用Playbook进行多任务编排

Fri, 08 May 2026 16:05:17 +0800

一、Ansible Playbook介绍

如果基于AD-Hoc去执行多任务（如安装Nginx、修改配置文件、启动服务），需要先使用yum或command模块安装程序，再使用copy模块复制配置文件，最后使用service模块启动服务。为了解决这种多任务繁琐的情况，可以使用Ansible的playbook（剧本）功能

二、Ansible Playbook构成

Inventory：主机列表，表示剧本中的任务要应用在哪些主机上

Tasks：具体任务，即调用哪些模块完成操作，可以配置多个任务

Variables：变量，包含内置变量和自定义变量

Templates：模板，即使用模板语法来灵活变更的配置文件

Handlers与notify：触发器，由某事件触发执行的操作，比如修改配置文件后自动重启服务

三、Ansible Playbook语法

1、playbook本质是包含了一个或多个任务的YAML配置文件，通常以.yaml或者.yml结尾

2、在单一的一个playbook文件中，使用连续的三个中横线（---）作为每个play的区分

3、缩进必须统一，不能空格和tab混合使用，缩进级别需要一致，同样的缩进代表同样的级别

4、使用冒号“:”之后还需要书写内容的话，则需要空一格才能书写

5、使用短横线“-”后必须追加一个空格

四、Ansible Playbook参数

· hosts：指定远程主机（多个主机用逗号分隔）或主机组

- hosts: webservers

· remote_user：指定执行任务的用户（可以定义在hosts字段下，也可单独给每个task定义），通常是root用户，也可指定非root用户使用sudo方式执行任务

- hosts: 192.168.1.31
    remote_user: root  #定义全局用户

· tasks：任务信息将定义在此字段下

tasks: 
  - name: run df -h
    remote_user: test  #单独为task定义用户
    shell: name=df -h

· sudo（可省略）：如果设置为yes，那么sudo_user指定的用户在执行任务时会获得root权限

· sudo_user（可省略）：指定需要使用sudo执行操作的用户

tasks: 
  - name: run df -h
    sudo_user: test
    sudo: yes
    shell: name=df -h

· connection（可省略）：通过什么方式连接到远程主机，默认为SSH

· gather_facts（可省略）：如果明确不需要通过setup模块来获取远程主机facts信息，可以使用这个选项，能提升一定的性能

- hosts: all
  gather_facts_: no
  tasks:
    - name: sleep 5
      command: sleep 5

· ignore_errors（可省略）：默认情况下ansible会因为一个错误导致后面的任务全部失败，有些时候可能会忽略一些错误的发生，让其他任务能正常执行

-hosts: all
  tasks:
    - name: ignore_test
      command: /bin/false
      ignore_errors: yes
    - name: touch file
      file: path=/tmp/test.txt state=touch

五、Ansible Playbook基础示例

1、基本示例

- hosts: webservers
  tasks:
    - name: 1.Installed NFS Server
      yum:
        name: nfs-utils
        state: present
    - name: 2.Configure NFS Server
      copy:
        src: ./exports.j2
        dest: /etc/exports

2、高级示例，包含变量、触发器等使用

cat playbook01.yml
- hosts: 192.168.1.31     #定义需要执行的主机或主机组
  remote_user: root      #远程用户
  vars:            #定义变量
    http_port: 8088      #变量
  tasks:            #定义一个任务
    - name: create new file               #定义任务的名称
      file: name=/tmp/playtest.txt state=touch   #调用模块，具体要做的事情
    - name: install package
      yum: name=httpd
    - name: config httpd
      template: src=./httpd.conf dest=/etc/httpd/conf/httpd.conf
      notify:                #触发器，当条件触发后需要做的操作，配合handlers使用
        - restart apache  #需要引用的handlers的名字
    - name: copy index.html
      copy: src=/var/www/html/index.html dest=/var/www/html/index.html
    - name: start httpd
      service: name=httpd state=started
  handlers:                                             #notify定义的触发执行相应的处理动作
    - name: restart apache               #要与notify定义的内容相同
      service: name=httpd state=restarted      #触发要执行的动作

六、Ansible playbook运行结果说明

当playbook运行后在PLAY RECAP（汇总报告）一列将返回返回的结果包含了任务ok的数量（已经达到任务要求，无需再次处理）、changed数量

ansible-playbook命令示例与常用选项

ansible-playbook -t tag_name httpd.yml #-t指定标签名，多个标签用逗号分隔
ansible-playbook playbookname.yml --list-task #列出该playbook中的任务

# --check | -C：只检测可能会发生的改变，但不真正执行操作
# --list-hosts：列出运行任务的主机
# --list-tags：列出playbook文件中定义的所有tags
# --list-tasks：列出playbook文件中定义的所有任务
# --limit：主机列表 只针对主机列表中的某个主机或者某个组执行
# -f：指定并发数，默认为5个
# -t：指定tags运行，运行某一个或者多个tags。前提是playbook中有定义tags
# -e：声明变量和值

七、使用ansible-vault加密Playbook

ansible-vault encrypt hello.yml  #加密playbook，加密否的文件无法直接执行和查看
ansible-vault view hello.yml  #查看加密后的文件
ansible-vault edit hello.yml  #查看加密后的文件
ansible-vault decrypt hello.yml  #解密playbook

Ansible教程（2）Ansible的命令行与常用模块

Fri, 08 May 2026 15:38:52 +0800

一、Ansible Ad-Hoc简介

Ad-Hoc是一种通过ansible内置命令行让Ansible进行工作的方式，也是最简单的调用方式。命令行语法格式如下

ansible <host-pattern> [-f forks] [-m module_name] [-a args]

<host-pattern>：指定生效的主机组，可以使用主机列表中的地址或者组名，all代表所有主机，也支持逻辑与、或以及正则表达式

[-f forks]：并发数，可以理解为ansible一次性要让多少个主机执行任务，配置文件中默认为5

[-m module_name]：使用的模块名

[-a args]：每个模块特有的参数，可以用ansible-doc -s 模块名来查看模块对应参数

-b：老版本中的sudo指令，将在远端主机切换到root执行操作，这个root用户是在ansible配置中定义的

-K：sudo时需要输入的密码

Ansible命令行示例

ansible 192.168.1.100 -m ping  #指定某台主机
ansible all -m ping  #指定所有主机
ansible 192.168.1.100:192.168.1.50 -m ping  #一次指定多台主机
ansible all:\!192.168.1.100 -m ping  #排除某台主机
ansible web -m ping -u dba -k  #使用dba用户对web组进行操作
ansible web -m command -a 'cat /etc/passwd' -u dba -k -b  -K #使用dba用户连接web组，然后sudo到root用户查看passwd文件

二、Ansible常用模块介绍

· command模块：缺省默认模块，指定远端主机需要执行的命令，不支持管道或者重定向

ansible 192.168.44.130 -a 'date'

· cron模块：设置定时任务，其中有个state选项包含present、absent两个参数，分别代表增加和移除

ansible webserver -m cron -a 'minute="*/10" job="/bin/echo test" name="test cron job" '
ansible webserver -m cron -a 'hour="*/1" job="/usr/sbin/ntpdate 10.254.1.10" name="crontab from ansible" state=present'

· user模块：管理用户，还有一个group模块用于管理组

ansible webserver -m user -a "name=mysql system=yes"

· file模块：设置文件的属性，如所属主、文件权限等

ansible all -m file -a 'owner=mysql group=mysql mode=644 path=/tmp/test'
ansible all -m file -a 'path=/etc/passwd.link src=/etc/passwd state=link' 
# path：指定要设置的文件所在路径，可使用name或dest替换
# state：指明文件的格式，touch=创建新的文件；absent=删除文件，link=创建软连接文件；directory=创建目录。创建文件的软连接时src指明源文件，path指明连接文件路径

· ping模块：测试远端主机是否能连接

ansible all -m ping

· service模块：控制服务运行状态

ansible webserver -m service -a 'enabled=true name=httpd state=started'
# enabled：是否开机自动启动，取值为true或者false
# name：服务名称
# state：状态，取值有started，stopped，restarted

· shell模块：和command模块一样是用来运行命令，当命令中有变量或者管道符的时候要用shell模块，特殊符号需要转义，比如\$

ansible all -m shell -a "echo test | passwd --stdin user1"

· script模块：将本地的脚本复制到远端主机并执行，需要把脚本放在当前目录中并使用相对路径来指定

ansible all -m script -a 'test.sh'

· yum模块：安装程序包，远端主机需要先配置好正确的yum源

ansible -m yum -a 'name=httpd state=present' 
# name：指明要安装的程序包，可以带版本号，否则默认最新版本，多个安装包用逗号分隔
# tate：present代表安装，也是默认操作；absent是卸载；latest最新版本安装

· setup模块：收集被管理主机的信息，包含系统版本、IP地址、CPU核心数。在Ansible高级操作中可以通过该模块先收集信息，然后根据不同主机的不同信息做响应操作，类似Zabbix中的低级别发现自动获取磁盘信息一样

· copy模块：实现文件复制，但是使用该模块进行文件复制时不会引用变量的值，如果使用了变量，需要替换为template模块（该模块只能通过playbook方式运行）

ansible all -m copy -a 'src=/etc/fstab dest=/etc/fstab owner=root mode=640' 
ansible all -m copy -a 'content="hello world" dest=/etc/fstab owner=root mode=640 backup=yes'   
# src=：定义本地源文件的路径
# dset=：定义目标文件路径
# content=：用该选项直接生成内容，替代src
# backup=：如果目标路径存在同名文件，将自动备份该文件

· sysctl模块：实现内核参数修改

ansible all -m sysctl -a 'name=vm.swappiness value=1 state=present'

三、查看Ansible模块帮助信息

1、通过ansible-doc -l 可以显示当前版本所支持的模块信息

2、通过ansible-doc -s modulename显示指定模块的详细用法

ansible-doc -s yum

Ansible教程（1）Ansible的安装与基本使用

Fri, 08 May 2026 15:25:57 +0800

一、Ansible简介

Ansible是一个基于Python开发的轻量级自动化运维工具，有着其他自动化运维工具如puppet、cfengine、chef、func、fabric的优点，并且不需要单独安装客户端以及启动服务，只需要通过SSH就可以快速的对大量客户端实现批量系统配置、程序部署、批量运行命令等。而且Ansible的学习曲线也平缓，比puppet易学很多

二、安装Ansible

方法1（推荐）：YUM安装

对于Ansible这种工具性软件使用YUM安装是最方便的，只需要配置好EPEL仓库就可以一条命令安装

yum install ansible -y #yum安装最新版
ansible --version  #安装后查看版本以及模块路径等信息

方法2：通过python pip工具安装

该方法需要先编译安装好python3，安装好以后Ansible的命令都会放在Python的目录中

/usr/local/python3/bin/pip3 install ansible==2.7  #使用pip安装指定版本Ansible
ln -s /usr/local/python3/bin/ansible /usr/local/bin

三、Ansible配置文件

· /etc/ansible/hosts

主机列表清单，也叫Inventory。所有被管理的主机都需要定义在该文件中。如果不想使用默认清单的话可以用-i选项指定自定义的清单文件，防止多人混合使用一个主机清单。如果没有定义在主机列表文件中，执行命令会提示“No hosts matched”

· /etc/ansible/ansible.cfg

Ansible服务主配置文件，可以自定义Inventory文件、并发数等，该配置文件的优先级实际是最低的，如果有定义其他配置文件，可以通过ansible --version查看实际有效路径

四、Inventory定义方法

方法1：为不同的主机组配置各自的主机IP、端口、用户名、密码信息

#编辑配置清单文件
vim /etc/ansible/hosts

#组名为webserver，并且为该组下的主机配置了各自的端口、root信息
[webserver]  
192.168.1.31 ansible_ssh_port=22 ansible_ssh_user=root ansible_ssh_pass="123456"
192.168.1.32 ansible_ssh_port=22 ansible_ssh_user=root ansible_ssh_pass="123456"
192.168.1.33 ansible_ssh_port=22 ansible_ssh_user=root ansible_ssh_pass="123456"
192.168.1.36 ansible_ssh_port=22 ansible_ssh_user=root ansible_ssh_pass="123456"

#组名为dbserver，并且使用了表达式来表示连续的IP段
[dbserver]  
192.168.1.4[1:3] ansible_ssh_port=22 ansible_ssh_user=root ansible_ssh_pass="123456"  

[redis]
192.168.1.5[1:3]
[redisserver:vars]  #将信息定义为变量
ansible_ssh_pass="123456"

[nginx] #推荐写法
nginx_1 ansible_ssh_host=192.168.1.61 ansible_ssh_port=22 ansible_ssh_user=root ansible_ssh_pass="123456"
nginx_2 ansible_ssh_host=192.168.1.62 ansible_ssh_port=22 ansible_ssh_user=root ansible_ssh_pass="123456"

方法二：基于秘钥管理

基于秘钥管理客户端的话需要在管理端创建公钥和私钥，然后发送给被管理端的机器

#管理端创建秘钥并发送到每个被管理端
ssh-keygen
ssh-copy-id -i $被管理端IP

#管理端清单文件
vim /etc/ansible/hosts
[webserver]  #做好秘钥的机器只用写IP即可
192.168.1.31:22
192.168.1.32
192.168.1.33
192.168.1.36

[dbserver]  #也可以通过别名方式进行配置
node1 ansible_ssh_host=192.168.1.31 ansible_ssh_port=22
node2 ansible_ssh_host=192.168.1.32 ansible_ssh_port=22
node3 ansible_ssh_host=192.168.1.33 ansible_ssh_port=22

方法三：自定义Inventory清单文件

#创建清单文件
vim /etc/ansible/dockers
[dockers]
192.168.1.31 ansible_ssh_pass='123456'
192.168.1.32
192.168.1.33
#使用-i指定清单文件
ansible dockers -m ping -i /etc/dockers

五、Inventory内置参数

Oracle教程（5）数据泵备份教程与实战

Thu, 23 Apr 2026 15:03:52 +0800

一、数据泵介绍

数据泵（Data Pump）是 Oracle 10g 开始引入的命令行逻辑备份与恢复工具。通过 expdp / impdp ，可以对所有数据库对象（模式、表数据、表空间等）进行高效导出和导入，并且支持多进程并行导出导入、可暂停恢复备份作业、灵活的对象过滤与重映射（如 REMAP_SCHEMA、REMAP_TABLESPACE、REMAP_TABLE 等），还能直接在数据库间通过网络链路完成数据传输，无需落地中间文件。

二、备份前置工作

1、创建数据泵目录

数据泵目录是 Oracle 中定义的逻辑目录，用于配置导出和导入数据的存放位置，在进行导出和导入操作时都需要指定该目录

#登录数据库后创建逻辑目录
CREATE DIRECTORY DATA_PUMP_DIR AS '/u01/app/oracle/admin/backup/';

2、创建备份用户

CREATE USER backup_user IDENTIFIED BY "YourPassword123!";
GRANT READ, WRITE ON DIRECTORY DATA_PUMP_DIR TO backup_user;

3、授予用户备份权限

GRANT CREATE SESSION TO backup_user;
GRANT EXP_FULL_DATABASE TO backup_user;
GRANT IMP_FULL_DATABASE TO backup_user;

4、授予用户数据泵目录权限

GRANT READ, WRITE ON DIRECTORY DATA_PUMP_DIR TO backup_user;

三、expdp / impdp 常用选项说明

expdp username/password@db SERVICE_NAME directory=DATA_PUMP_DIR dumpfile=backup.dmp logfile=backup.log schemas=SCHEMA_NAME

1、expdp常用选项

· 文件相关

username/password：执行备份的数据库用户名和密码

@db：指定需要连接的数据库实例，可以通过tnsnames.ora查看

directory=DUMP_DIR：指示数据泵目录，即一开始创建的逻辑目录

dumpfile=backup.dmp：指定备份文件名

logfile=backup.log：备份日志

PARALLEL=4：并行备份，可以提高到处速度

COMPRESSION=ALL：压缩备份，ALL表示数据 + 元数据全部压缩，还可以设置为METADATA_ONLY（默认）、DATA_ONLY、NONE

JOB_NAME=my_backup：给任务命名，方便监控和恢复

FLASHBACK_TIME="TO_TIMESTAMP('2024-01-01 00:00:00','YYYY-MM-DD HH24:MI:SS')"：导出某一时间点的一致性数据

· 备份范围（四选一）

FULL=Y：导出整个数据库

SCHEMAS=$SCHEMA_NAME：导出指定 Schema

TABLES=$SCHEMA_NAME_$TABLE_NAME：导出指定表

TABLESPACES=TBS1,TBS2：导出指定表空间

· 过滤

CONTENT=ALL：指定需要导出的数据，默认为ALL，此外还有DATA_ONLY 和 METADATA_ONLY

QUERY=$TABLE_NAME:"WHERE deptno=10"：按照过滤条件进行备份

EXCLUDE=TABLE:"IN ('TMP','LOG','TEMP')"：备份时排除指定对象

INCLUDE=TABLE:"IN ('EMP','DEPT','SALARY')"：备份时只包含指定对象

2、impdp常用选项

dumpfile=backup.dmp：指定备份文件

logfile=restore.log：指定恢复过程的日志文件

schemas=SCHEMA_NAME：指定要恢复的模式名

TABLE_EXISTS_ACTION=REPLACE：导入时如果表已存在的处理方式，支持SKIP（跳过）、APPEND（追加）、TRUNCATE（先清空）和REPLACE（替换）

remap_tablespace=old_tablespace:new_tablespace：如果要恢复到不同的表空间，通过 remap_tablespace 参数进行映射，如果导出还原时表空间名一致就可以不用该选项

四、expdp / impdp 使用实例

1、expdp导出示例

· 完整备份

expdp username/password@db directory=DATA_PUMP_DIR dumpfile=all_tables.dmp logfile=all_tables.log full=yes

· 备份特定的表

expdp username/password@db directory=DATA_PUMP_DIR dumpfile=table_backup.dmp logfile=table_backup.log tables=SCHEMA_NAME.TABLE_NAME

· 只导出表结构

expdp username/password@db directory=DATA_PUMP_DIR dumpfile=structure_only.dmp logfile=structure_only.log content=metadata_only schemas=SCHEMA_NAME

· 并行导出

expdp username/password@db directory=DATA_PUMP_DIR dumpfile=backup%U.dmp logfile=backup.log schemas=SCHEMA_NAME parallel=4

2、impdp导出示例

· 从完整备份恢复

impdp username/password@db directory=DATA_PUMP_DIR dumpfile=full_backup.dmp logfile=full_restore.log full=yes

· 恢复指定表

impdp username/password@db directory=DATA_PUMP_DIR dumpfile=table_backup.dmp logfile=table_restore.log tables=SCHEMA_NAME.TABLE_NAME

· 导入数据到指定表空间

impdp username/password@db directory=DATA_PUMP_DIR dumpfile=backup.dmp logfile=restore.log remap_tablespace=old_tablespace:new_tablespace

五、监控数据泵作业

· 查看当前数据泵作业

SELECT * FROM DBA_DATAPUMP_JOBS;

· 查看作业进度

SELECT * FROM DBA_DATAPUMP_SESSIONS;

六、备份还原实战

将A服务器 Oracle 中的 IPLAT.HISTRORY_LOG 表恢复到B服务器 Oralce 中进行归档，恢复后保持表名不变或者使用一张新表保存，但是SCHEMA需要保持一致

1、源库创建 DIRECTORY

DIRECTORY 是 Oracle 中的数据库对象，用于指定数据库和操作系统物理路径的映射关系，把数据库内的一个名字和服务器磁盘上的真实路径关联起来。在对 Oracle 进行备份时，不允许直接写操作系统路径，而是需要先创建 DIRECTORY 对象，再把这个对象的权限授予具体用户

-- 查看已有 directory
SELECT directory_name, directory_path FROM dba_directories;

-- 如不存在，创建一个（路径需提前在 OS 上建好）
CREATE OR REPLACE DIRECTORY dp_dir AS '/data/datapump';

-- 授权给 iplat 用户
GRANT READ, WRITE ON DIRECTORY dp_dir TO iplat;

2、导出数据

注意 DIRECTORY 的名字要与数据库中已有的 DIRECTORY 保持一致

expdp iplat/密码@服务名 DIRECTORY=DUMPDIR \   
DUMPFILE=em_hi_log_$(date +%Y%m%d).dmp \
LOGFILE=em_hi_log_exp_$(date +%Y%m%d).log \
TABLES=iplat.EM_HI_LOG \
COMPRESSION=ALL

3、目标库创建DIRECTORY

确认目标库 DUMPDIR 目录对象存在，如果不存话按照上面的步骤创建

SELECT directory_name, directory_path FROM dba_directories  WHERE directory_name = 'DUMPDIR';

4、目标库创建用户

确认 iplat 用户存在，如果不存在需要提前创建

SELECT username, account_status FROM dba_users WHERE username = 'IPLAT';

5、确认目标库存在表空间

源库用的是 DS_IPLAT01表空间，如果目标库不进行表空间映射的话就需要保持一致；如果要不存在该表空间就要先行创建，避免写入到默认表空间

SELECT tablespace_name, status FROM dba_tablespaces WHERE tablespace_name = 'DS_IPLAT01';

--创建表空间
CREATE TABLESPACE DS_IPLAT01 \
DATAFILE '/u01/oradata/orcl/ds_iplat01_01.dbf' SIZE 10G \
AUTOEXTEND ON NEXT 1000M MAXSIZE 32G
EXTENT MANAGEMENT LOCALSEGMENT SPACE MANAGEMENT AUTO;

6、导入数据

这里使用REMAP_TABLE将表名进行了修改

impdp 'iplat/123456' \
DIRECTORY=DUMPDIR DUMPFILE=em_hi_log_20260611.dmp \
LOGFILE=em_hi_log_imp_20260611.log \
TABLES=iplat.EM_HI_LOG \
REMAP_TABLE=iplat.EM_HI_LOG:EM_HI_LOG_202606

MySQL教程（13）基于Position或GTID实现主从复制

Fri, 17 Apr 2026 17:01:36 +0800

一、MySQL主从复制概述

主从复制是MySQL高可用与横向扩展的基础方案，其核心依赖于 MySQL 自身的 Binlog 机制。主节点的 Binlog 记录了数据库上所有的 DDL 与 DML 操作（SELECT、SHOW 等不产生数据变更的语句不会被记录，临时表的操作同样不在记录范围内），从库将主库 Binlog 复制到自己的Relay Log，再依据 Relay Log 执行相同的操作，从而实现数据同步。

1、主从复制主要应用场景

· 提升查询性能：所有数据变更在主节点完成，查询请求通过从节点完成，尤其是一些 OLAP 报表类任务也非常适合通过从节点完成

· 提升数据安全：从节点可以作为主节点的备份，结合半同步复制或延迟复制保障数据安全，日常备份任务也可以在从节点上执行，降低主节点的性能压力

· 远程数据分发：跨区域数据同步，适合对数据实时性要求不高的场景，对实时性有要求的请求则继续走主节点或同区域节点

· 滚动升级：先升级从库并进行测试，再切换主从关系，实现不停机的在线升级

· 自动化高可用：当主节点发生故障时，通过数据库中间件或手动切换的方式快速恢复服务

2、主从复制常见方式

· 主从架构：常见的主从架构包括一主一从、一主多从、级联复制。需要注意的是在进行 Binlog 传输时会有IO和带宽消耗，如果是一主多从的架构，从节点的数量不宜过多

· 复制模式：主从复制在进行数据同步时分为异步复制、半同步复制和同步复制。异步复制是主库写完 Binlog 就立刻返回给客户端，不关心从库有没有真正收到日志并完成应用，性能最好但存在数据丢失风险；半同步复制是主库写完 Binlog 后，需要等待至少一个从库确认已经收到并写入 Relay Log 才返回给客户端；全同步复制是主库必须等所有从库都执行完事务才返回，数据一致性最强，但性能影响也最大

二、MySQL主从复制配置

在部署主从架构前先确保主从节点时间同步，并且数据库版本一致（从库版本可以高于主库版本，但是不能低于主库版本）

1、基于position方式实现主从同步

基于position是传统的主从配置方式，从库记录了当前同步到的 Binlog 偏移量，比如 mysql-bin.000023，pos 4521。这种方式简单易懂，但是当进行主从切换或者级联复制时，需要手动找到新主库对应的偏移量，操作繁琐

· 数据库配置部分

由于主从可能发生切换，所以建议在配置上保持一致，可以参考《MySQL教程（2）MySQL 生产环境配置文件模板及参数详解》，这里摘取部分配置进行说明

### Binlog ###
sync_master_info = 1                            # 每次事务提交后立即将 master.info 刷新到磁盘，防止主库宕机时丢失同步状态
log_bin = /data/mysql3310/log/binlog/mysql-bin  # Binlog存储路径及文件名前缀
binlog_format = row                             # 使用 row 格式记录 Binlog，记录每行数据的实际变更，比 statement 模式更安全可靠
binlog_rows_query_log_events = on               # 在 Binlog 中额外记录原始 SQL 语句
max_binlog_size = 1024M                         # 单个 Binlog 文件的最大大小，超过后自动切换到下一个文件
expire_logs_days = 10                           # Binlog 文件的自动清理天数，10 天前的文件会被自动删除
### Relay Log ###
relay-log = /data/mysql3310/log/relaylog/relay-bin  # Relay Log 文件的存储路径及文件名前缀
relay_log_recovery = 1                              # 从库崩溃重启后自动从最新的 Relay Log 恢复，避免使用可能损坏的旧文件
relay-log-purge = 1                                 # 自动删除已应用的 Relay Log
### Replication ###
master_info_repository = TABLE          # 将 master.info 持久化到系统表，避免宕机后状态不一致
relay_log_info_repository = TABLE       # 将 relay-log.info 持久化到系统表，原因同上
skip_slave_start = 1                    # 从库启动时不自动开启复制线程，需手动执行 START SLAVE，便于启动后先检查状态
log_slave_updates = 1                   # 从库将复制执行的事务也写入自己的 Binlog，级联复制或从库切主时必须开启
slave_parallel_type = LOGICAL_CLOCK     # 并行复制调度策略，基于主库提交时序判断事务能否并行，比 DATABASE 模式并行度更高
slave_parallel_workers = 8              # 并行复制的工作线程数，通常与主库核心数相当
slave_preserve_commit_order = 1         # 保证从库事务提交顺序与主库一致，开启并行复制时建议同时开启
slave_net_timeout = 10                  # 从库检测主库连接超时的时间（秒），超时后触发重连
#read_only = 1                           # 从库只读，建议从库打开
#super_read_only = 1                     # SUPER权限的用户也只读，建议从库打开
transaction_write_set_extraction = XXHASH64                     # 事务哈希算法，用于 WRITESET 并行复制和冲突检测
binlog_transaction_dependency_tracking = WRITESET_SESSION       # 同会话内事务保持顺序，跨会话无冲突事务可并行回放

· 在主库建立复制账号并授予权限

GRANT REPLICATION SLAVE,REPLICATION CLIENT ON *.* TO 'slave'@'192.168.36.11' IDENTIFIED BY '123456789';

· 查看主库当前position

position实际对应的是binlog的File Size，从库会从该位置进行复制

mysql > show master status \G

· 从库指定主库position

STOP SLAVE;
CHANGE MASTER TO MASTER_HOST='192.168.145.85',MASTER_USER='repl',MASTER_PASSWORD='123456',MASTER_LOG_FILE='master-bin.000004',MASTER_LOG_POS=0;
#MASTER_HOST：MASTER服务器的IP
#MASTER_USER：有slave权限的用户，就是GRANT所授权的用户
#MASTER_PASSWORD：从库用户的密码
#MASTER_LOG_FILE：在主库上执行show master status语句可以查看日志名
#MASTER_LOG_POS=333：这个位置决定了从库从哪个位置开始复制，实测写0也可以，从头复制

· 启动从库复制线程

启动后查看下状态，必须确保 Slave_IO_Running、Slave_SQL_Running的状态都为YES

mysql > start slave;  #启动从库
mysql > show slave status \G  #查看从库状态，确保IO_THREAD

2、基于GTID方式实现主从同步

GTID（全局事务标识）是从 MySQL 5.6 开始引入，InnoDB 引擎会对每个事务都使用一个全局唯一编号进记录，GTID拥有全局唯一性和幂等性，GTID按照递增方式发生变化，一个完整的GTID包含了UUID和GTID两部分，UUID即Server_uuid，用于区分事务来自于集群中哪个节点。从5.7版本开始，即便没有配置GTID也会存在匿名事务，只不过这个匿名事务不包含GTID信息，不能用于主从复制。MySQL在启动的时候通过读取 auto.cnf 获取UUID，如果auto.cnf文件丢失则会自动生成新的UUID，如下为GTID示例

# 同一个实例的事务GTID会进行合并，比如来自同一个实例的1-3号事务，会写为1-3。事务之间如果不连续，则用逗号分隔
2a09ee6e-645d-11e7-a96c-000c2953a1cb:1-3
2a09ee6e-645d-11e7-a96c-000c2953a1cb:1-3,11,48-51

因为GTID的全局唯一性，从库只需要知道自己已经执行过哪些GTID，然后会自动执行该GTID之后的事务，不再需要指定Position。这样一来可以大幅简化主从复制部署与维护的复杂度。因为不同节点之间的GTID还有连续性和幂等性，这样在进行主从切换时也更方便，不再有每个节点position不同的情况，从库不需要关心偏移量就能自动找到新主库上的同步点。在实际使用中，GTID 模式已经是目前最优选择，尤其是配合 MHA、orchestrator 等高可用工具做自动故障切换时已经是必选项

需要注意启用GTID以后，不再支持create table...select...语句，因为该语句实际是先CREATE TABLE再INSERT会生成2个GTID，违背了GTID下一个事务只有一个GTID的特性。并且也不支持使用CREATE TEMPORARY TABLE临时表相关操作

· 在所有节点开启GTID

MySQL 5.7开始支持在线配置GTID，无需重启服务。但是为了确保MySQL能正确处理从匿名事务更改为GTID事务的过程，gtid_mode的值只能按照顺序逐一提升或下降，如可以从OFF_PERMISSIVE逐步升级为ON_PERMISSIVE和OFF，但是不能直接调整为ON，关于GTID在线开启见https://www.ywdba.cn/post-647.html

开启 GTID 后需要关注的相关表与变量

· mysql.gtid_executed：该表存储GTID信息，数据库实例启动时会读取该表信息并赋值给gtid_executed变量（在MySQL 5.6时期是使用binlog中的GTID_LOG_EVENT来持久化GTID信息的，所以必须配置 log_slave_updates=1 才能使用GTID的主从方式）

· gtid_executed：该变量用于实时查看当前数据库实例已经执行过的GTID集合。执行show master status或show slave status时返回的Executed_Gtid_Set的值就来自于该变量

· gtid_purged：该变量记录了已经被删除或丢弃的GTID事务（Binlog过期或人为操作删除都算）。在部署从库的时候通常需要使用set global gtid_purged命令来设置该变量，表示从库不需要再执行这些GTID包含的操作（因为这些事务已经在备份数据中了），否则会因为日志被删除了而导致同步失败

· 数据库配置部分

采用GTID复制后从库也会产生binlog日志，通过show master logs可以看到与主库是一致的。在从库执行show binlog event in 'master-bin.000001'命令可以查看当前所执行的事务ID位置，正常情况也与主库一致

### Binlog ###
sync_master_info = 1                            # 每次事务提交后立即将 master.info 刷新到磁盘，防止主库宕机时丢失同步状态
log_bin = /data/mysql3310/log/binlog/mysql-bin  # Binlog存储路径及文件名前缀
binlog_format = row                             # 使用 row 格式记录 Binlog，记录每行数据的实际变更，比 statement 模式更安全可靠
binlog_rows_query_log_events = on               # 在 Binlog 中额外记录原始 SQL 语句
max_binlog_size = 1024M                         # 单个 Binlog 文件的最大大小，超过后自动切换到下一个文件
expire_logs_days = 10                           # Binlog 文件的自动清理天数，10 天前的文件会被自动删除
### Relay Log ###
relay-log = /data/mysql3310/log/relaylog/relay-bin  # Relay Log 文件的存储路径及文件名前缀
relay_log_recovery = 1                              # 从库崩溃重启后自动从最新的 Relay Log 恢复，避免使用可能损坏的旧文件
relay-log-purge = 1                                 # 自动删除已应用的 Relay Log
### Replication ###
master_info_repository = TABLE          # 将 master.info 持久化到系统表，避免宕机后状态不一致
relay_log_info_repository = TABLE       # 将 relay-log.info 持久化到系统表，原因同上
skip_slave_start = 1                    # 从库启动时不自动开启复制线程，需手动执行 START SLAVE，便于启动后先检查状态
log_slave_updates = 1                   # 从库将复制执行的事务也写入自己Binlog，级联复制或从库切主时必须开启
slave_parallel_type = LOGICAL_CLOCK     # 并行复制调度策略，基于主库提交时序判断事务能否并行，比 DATABASE 模式并行度更高
slave_parallel_workers = 8              # 并行复制的工作线程数，通常与主库核心数相当
slave_preserve_commit_order = 1         # 保证从库事务提交顺序与主库一致，开启并行复制时建议同时开启
slave_net_timeout = 10                  # 从库检测主库连接超时的时间（秒），超时后触发重连
read_only = 1                           # 从库只读，建议打开
super_read_only = 1                     # SUPER权限的用户也只读
transaction_write_set_extraction = XXHASH64                     # 事务哈希算法，用于 WRITESET 并行复制和冲突检测
binlog_transaction_dependency_tracking = WRITESET_SESSION       # 同会话内事务保持顺序，跨会话无冲突事务可并行回放
### GTID ###
gtid_mode = on                      #  开启 GTID 模式，每个事务分配全局唯一 ID，简化主从切换和故障恢复
enforce_gtid_consistency = 1        # 强制所有事务满足 GTID 一致性约束，禁止在 GTID 模式下无法安全复制的语句
binlog_gtid_simple_recovery = 1     # 简化 GTID 恢复流程，只扫描最新和最旧的 Binlog 即可确定已执行的 GTID 集合，加快启动速度

· 主库进行授权操作

grant replication slave,replication client on *.* to 'repl'@'192.168.1.110' identified by '123456'

· 从库恢复主库备份

备份数据恢复后需要在从库指定gtid_purged变量信息，这个信息根据备份方式不同导致查询的方式不同。如果是mysqldump逻辑备份，在备份文件前50行会有gtid_purged变量，xtrabackup物理备份则会写入xtrabackup的备份文件中

#通过备份还原数据后通过该命令可以看到从节点和主节点GTID信息是一致的 
show master status \G  
#防止从库读取到错误的gtid_executed变量，执行该命令可以重置变量
reset master;        
#指定从库需要跳过的GTID信息，也就是让从库从该GTID之后开始进行复制
set global gtid_purged='xxxxxxxxxx:1-21';

· 从库指定同步位点信息

由于采用了GTID，从库在指定position信息时只用声明从哪个GTID后开始同步即可

change master to master_host='192.168.1.100',master_port=3306,master_user='repl',master_password='123456',master_auto_position=1;
start slave;

· 验证同步状态

从库执行show slave status命令查看事务ID是否与主库一致，Retrieved_Gtid_Set表示从库已经接受到的GTID信息；Executed_Gtid_Set表示从库已经应用了的GTID信息

2.1 GTID常见问题处理

· 跳过指定事务

开启GTID后如果需要跳过一个事务不能再使用sql_slave_skip_counter参数，而是要获得从库执行的最后一个GTID操作。也就是show slave status 中的Retrieved_Gtid_Set信息

构建空事务

stop slave;
set gtid_next='xxxxxxxxxxxxxxxcb140c:10903292'
begin;
commit;
set gtid_next='xxxxxxxxxx3:4'
begin;
commit;
set gtid_next='automatic';
start slave;

· 复制线程状态为yes但是不同步

数据目录下auto.cnf存放了数据库UUID，每个节点的ID不能一样，如果一样会出现主从状态是2个yes，但是数据不同步的情况

show global variables like 'server_uuid' ;

· 报错：Master_has_purged_require_gtids

通常是主库删除了还未同步完成的Binlog导致

#在从库上手动指定二进制日志文件和位置
mysql > stop slave;
mysql > change master to master_host='192.168.1.100',master_user='repl',master_password='123456',master_log_file='master-bin.000005',master_log_pos=526,master_auto_position=0;
mysql > start slave;

· 报错：Slave has more GTIDs than the master has,using the master's SERVER_UUID

该问题代表从库获取到的GTID超过了主库，比如主库在未指定binlog文件名的同时修改了系统主机名导致binlog全部被修改，从库就会判断失败；或者主库未配置双1参数时断电，导致从库提前获取到了还未执行的GTID，解决方法如下

#全在从库执行
stop slave;
reset slave;
reset master;  #从库的binlog已经无效了，所以要执行这个命令清空binlog
change master to master_host='192.168.1.100',master_port=3306,master_user='repl',master_password='123456',master_auto_position=1;三、MySQL主从常见维护方法

三、MySQL主从常见维护方法

· 查看主节点状态

#主要用于查看主库position信息
show master status \G

· 查看从节点状态

show slave status \G   #主要用于查看从库状态

从节点需要关注的地方比较多，主要有以下重点指标

指标名	用途
Read_Master_Log_Pos	记录从库读取到主库Binlog到哪个位置
Exec_Master_Log_Pos	记录从库执行到主库Binlog到哪个位置。如果和Read_Master_Log_Pos一致代表数据是完全同步的
Relay_Log_File	记录当前从库将Binlog记录到哪个Relay Log
Relay_Master_Log_file	当前Relay Log所对应的Binlog日志文件
Seconds_behind_master	从服务器比主服务器慢了多少秒，为0代表没有延迟。这里的计算方式为“从库当前系统时间 - 主从节点之间的系统时间差 - 从库SQL线程正在执行的事务时间戳”，这里主从节点之间的时间差会在从库IO线程执行启动的时候进行计算，所以主从时间不一致时也能计算出正确的延迟时间，但是要注意如果在复制过程中修改了系统时间就会导致主从延迟不可靠，除非重启IO线程。当SQL线程重放主库的大事务时，时间戳更新相当于被暂停了，此时无论主库是否还有事务写入，从库的延迟值都会越来越大，等大事务执行完毕后又突然变为0是正常现象。虽然该值可以用来判断主从同步情况，但是最准确的方式还是对比Read_Master_Log_Pos - Exec_Master_Master_Log_Pos的值以及Executed_Git_set - Retrieved_Gtid_Set的差值。如果GTID差值很小而Position差距很大的话，说明是有大事务的存在
Slave_IO_Running、Slave_SQL_Running	如果有一项为No都表示主从异常。IO Thread的作用是从Master端请求二进制日志并存放到Slave端的中继日志中；SQL Thread的作用是将中继日志里的事件导入到SQL语句中

· 从库管理常用命令

需要注意的是无论使用何种复制方式，如果需要重启服务建议先stop slave再重启MySQL服务，避免复制出错

STOP SLAVE IO_THREAD;	         #停止从库IO进程
STOP SLAVE SQL_THREAD;	 #停止从库SQL进程
STOP SLAVE;	         #停止IO和SQL进程
START SLAVE IO_THREAD;	 #启动IO进程
START SLAVE SQL_THREAD;	 #启动SQL进程
START SLAVE;	         #启动IO和SQL进程
RESET SLAVE;	         #重置从库状态，该操作会删除所有中继日志并启动一个新的中继日志，通常重做从库的时候才会执行此命令
SHOW SLAVE STATUS;	         #查看MySQL同步状态

Redis教程（4）数据持久化配置

Wed, 01 Apr 2026 16:11:01 +0800

一、Redis的持久化介绍

Redis支持将缓存数据持久化到硬盘中保存，避免内存中的数据在服务重启后或者服务器断电等情况下发生丢失。Redis的数据持久化支持rdb快照持久化和aof日志持久化两种方式。在生产环境中如果要考虑Redis数据持久化，建议将两种方式都同时配置，并且是在从库上执行数据的持久化，减少对主库性能的影响

· RDB快照持久化

每隔一段时间或者操作次数达到一定量后，从内存Dump数据形成rdb文件，RDB文件是经过压缩的二进制数据，文件会比较小，恢复速度快。RDB持久化的缺点是如果当前写入的数据还无法触发持久化操作，此时发生宕机，那么会丢失这部分数据

· AOF日志持久化

类似MySQL的Binlog，可以实现每次操作的持久化，数据最为安全，但是影响性能

二、手动保存Redis数据

在配置RDB和AOF前还需要了解下保存Redis数据的命令——save和bgsave，在生产环境中建议使用bgsave进行保存数据，它会fork出一个子进程来读取内存中的数据并写入到文件中，除了fork期间会有短暂的阻塞，后续的操作都不会阻塞客户端的读写请求。但是由于fork出来了新进程，在保存数据的时候内存的消耗也会double，要小心OOM风险

三、RDB持久化配置方法

编辑redis.conf配置文件，主要修改以下内容

save 900 1  #在900秒内，key值发生变化次数超过1次则进行持久化，生产环境通常默认这个值即可 
save 300 10  #在300秒内，key值发生变化次数超过10次则进行持久化，生产环境通常默认这个值即可 
save 60 10000  #在60秒内，key值发生变化次数超过10000次则进行持久化，生产环境通常默认这个值即可  
stop-write-on-bgsave-error yes  # 如果rdb文件在导出过程中出错则让Redis停止任何写数据请求，避免数据不一致 
rdbcompression yes  #压缩rdb数据，消耗CPU性能来节约磁盘空间 
rdbchecksum yes  #服务启动时检查rdb文件的完整性，如果不完整则不启动
dbfilename dump.rdb  #rdb文件名
dir /data/redis/rdb/ #rdb文件保存路径，启动时会从该目录寻找rdb文件

当设置完后重启Redis服务，然后在工作中只要达到了save条件，key就会被保存。并且日志中也会有“xx changes in xx seconds. Saving”这样的记录。如果要关闭rdb功能的话将save选项改为save ""，引号里为空即可

四、AOF持久化配置方法

编辑redis.conf配置文件，主要修改以下内容

appendonly yes  #打开aof功能
#appendfsync  no  #让系统决定持久化时机，Linux默认30秒写入一次数据到磁盘
#appendfsync always  #每个命令都写入磁盘，最多丢失一条命令的数据
appendfsync  everysec  #每秒写一次数据到磁盘，最多丢失一秒数据，满足大部分应用场景，推荐使用
no-appendfsync-on-rewrite  yes  #如果正在导出rdb数据，停止aof的写入（aof将保存在一个队列中，rdb备份完成后执行队列，不会丢失数据）
auto-aof-rewrite-percentage 100  #aof文件体积与上次相比增长率达到100%就进行重写（重写相当于记总账，比如对同一个key做了100次操作，我们只需要最后一次的操作，重写就会把多余的操作给忽略掉）
auto-aof-rewrite-min-size 64m  #和上一项组合使用，aof文件达到64M时进行重写（重写会节省掉空间，因为多余的操作被删除了）
appendfilename  "appendonly.aof"  #aof文件名
dir /data/redis6379

当Redis服务启动后需要进行数据恢复时，如果同时开启了rdb和aof持久化，Redis只会加载aof文件（因为aof即时性高于rdb），如果rdb有数据时，再开启aof选项会把已经存储过的数据清空

当AOF写入文件时如果服务器崩溃或AOF存储已满的情况下，最后一条命令可能会被截断并产生异常的AOF文件。在AOF文件异常的情况下，如果Redis配置文件中指定了aof-load-truncated为yes，那么Redis在启动时会忽略最后一条命令并顺利启动 Redis，否则启动会失败。而如果AOF文件中间命令被破坏的话则需要使用redis-check-aof命令跳转到出现问题的命令行然后尝试手动修复此文件。如果无法手动修复，可以使用redis-check-aof --fix 自动修复AOF 异常文件，不过可能会导致异常部分至文件末尾的数据全部被丢弃。