众所周知，防止断电丢失 Binlog、故障恢复过程丢失数据，MySQL 主库必须设置 sync_binlog=1。那么作为备库可以例外吗？ 作者：胡呈清，爱可生 DBA 团队成员，擅长故障分析、性能优化，个人博客：[简书 | 轻松的鱼]，欢迎讨论。 爱可生开源社区出品，原创内容未经授权不得随意使用，转载请联系小编并注明来源。 本文约 1200 字，预计阅读需要 4 分钟。 众所周知，防止断电丢失

主库切换为物理备库 查看主库的状态 --获取/确认主库的状态信息以及保护模式 SQL> set linesize 720SQL> col name for a10SQL> col open_mode for a10SQL> col database_role for a14SQL> col switchover_status for a16SQL> col fo

Oracle数据库的主备切换通常指的是在Data Guard配置中，将当前的主数据库（Primary）切换到备用数据库（Standby），同时将备用数据库提升为主数据库的过程。以下是基于最新信息的Oracle数据库主备切换的基本步骤： 1. 检查主库状态 首先，您需要检查主库的状态，确保它处于可以进行切换的状态。您可以通过运行以下SQL命令来检查主库的状态： SELECT OPEN_MODE, D

db_file_name_convert： 作用与DG备库恢复时转换file_name，它将主库的file_name转换为备库的file_name。没有默认值，没有设置按照主库file_name来。（FILE_NAME：包含了数据文件路径和文件名） 白话说就是如果dg主备库目录文件不一样，主库放数据文件的目录备库没有，这个时候就需要去备库设置这个参数，用来把主库目录替换为备库有的目录。 语法： 配

Oracle在12.2版本之后，推出了部署ADG的新方式DBCA，通过DBCA方式快速的部署DG备库，简化了部署备库DG的操作步骤。 12.2.0.1 开始支持DBCA创建物理备库，但是限制较多，如： 主库必须是单机环境，非RAC数据库； 主库必须是非CDB环境； 18C之后，以上限制已经取消，支持主库是CDB和RAC环境，本文将为您详细介绍ORACLE 19C RAC下如何通过DBCA搭建dat

做为一个IT人，虽然经历了很多，但当时没记录故事，所以最后写文章就开始瞎编乱造了。今天就讲一个使用场景吧，A公司因为业务发展需求从机械盘换成了闪存卡，因为够大，所以想把数据库的整个挪到闪存卡上。。。 算了算了编不下去了，占时两个用法 1、redo挪位置 2、调整redo大小 3、调整redo每组个数 注意点：按照文档操作你需要更换路径，和大小根据实际情况调整。路径就不解释了，大小是根据业务量来的，

高可用高性能高并发数据库优势具体在哪？在当前企业信息化的环境下，高可用、高性能和高并发是企业数据服务的基本需求。为了满足这些需求，以高可用、高性能和高并发为设计中心的数据库系统应运而生。 1.高可用数据库 高可用数据库指的是在出现硬件故障、网络中断等故障的情况下，数据库仍能持续不间断地向应用提供服务保障。实现数据库高可用性的关键是数据库的备份与恢复，它包含主备、双机热备、集群等多种技术。 1.1主

前言： 什么是暴力测试，按东北话说，就是造，就是搓磨，绝不哩哩啦啦，上来就齐了咔嚓！ 转换成普通话是什么呢，就是对达梦数据库进行非常规操作，比如强制停库、关电源、杀进程、拔网线等，主要测试极端情况下，如何保证达梦数据库正常对外提供服务。 主要测试了以下几个场景： 1.正常关闭主库实例；2.直接杀掉主库实例；3.关闭主库守护进程；4.关闭备库实例；5.直接杀掉备库实例；6.关闭备库守护进程；7.do

mysql 读写分离是一种数据库架构，将数据库分为主库和从库，主库负责写入操作，从库负责读操作，以降低主库负载和提高并发读能力。实现 mysql 读写分离需要：搭建主从复制环境、修改应用程序配置、使用代理或中间件。读写分离的优势包括：降低主库负载、提高并发读能力、提供数据备份。需要注意的是，读写分离适用于读操作远多于写操作的场景。

在MYSQL 部署架构选型上，许多公司都会用到主从读写分离的架构，如下是一个一主一从的架构，主库master负责写入，从库slave进行读取。 图片 但是既然是读写分离，必然会面临这样一个问题，当在主库上进行更新后，有可能数据还没来得及同步到从库，但是这个时候又有读数据的需求，为了能正确读取出数据，这个时候就只有读主库了。但是这样做增加了主库的压力，违反了我们做读写分离的初衷。所以这一节我们就来针

在MYSQL 部署架构选型上，许多公司都会用到主从读写分离的架构，如下是一个一主一从的架构，主库master负责写入，从库slave进行读取。 但是既然是读写分离，必然会面临这样一个问题，当在主库上进行更新后，有可能数据还没来得及同步到从库，但是这个时候又有读数据的需求，为了能正确读取出数据，这个时候就只有读主库了。但是这样做增加了主库的压力，违反了我们做读写分离的初衷。所以这一节我们就来针对这种

注: 本文为云贝教育 刘峰 原创，请尊重知识产权，转发请注明出处，不接受任何抄袭、演绎和未经注明出处的转载。 软件规划 软件名称 版本 vmware v15 操作系统 oracle linux 8.8 数据库 19.3.0.0.0 secureCRT 9 主备规划 类型 IP 主机名 db_name db_unique_name instance_name ORACLE_SID 主库 192.16

背景 在GreatSQL主从复制环境中，有时候可能会出现一些误操作，将本应该写入到主库的数据写入到了从库，导致主从数据不一致，影响数据同步。是否可以将写入从库的数据同步写入主库呢？ 测试环境 角色 IP地址 数据库开放端口 版本 主库 192.168.137.179 3308 GreatSQL 8.0.32 从库 192.168.137.180 3308 GreatSQL 8.0.32 复制链路：

点击上方“IT那活儿”公众号--专注于企业全栈运维技术分享，不管IT什么活儿，干就完了！！！  背 景Oracle中，在备份端与主库同步的过程中由于网络原因或磁盘问题导致一个或多个归档日志丢失，进而dataguard同步无法继续。很多人都会选择重新全库恢复，并重新搭建备库。那么除了重建备库的方式还有一种高效的方式通过对主库进行基于SCN的增量备份前滚物理备库。 以下就是模拟该场景的实验记录。 模拟

前言 本文介绍关于MySQL组复制的背景信息和基本原理。包括，介绍MySQL传统复制方法的原理和隐患、介绍组复制的原理，单主模式和多主模式等等。通过结合原理图学习这些概念，可以很好的帮助我们理解组复制技术这一MySQL高可用方案，有利于提升我们对组复制的管理能力，以及为部署组复制和学习InnoDB Cluter打下理论基础。 官方参考文档：https://dev.mysql.com/doc/ref

主库 SYS 密码改变未同步密码文件到备库主库或者备库归档空间满无法归档主库或者备库监听异常，无法通过网络连接到主备库主库相关参数改变导致无法和备库正常同步主备库 tnsnames sqlnet listener 等文件改变备库未开启日志应用进程备库磁盘空间不足等等其他原因。 而这些原因大多数都可以通过查看主备库的 alter 告警日志展现出来，或者在主库查看视图 V$ARCHIVE_DEST。

注: 本文为云贝教育 刘峰 原创，请尊重知识产权，转发请注明出处，不接受任何抄袭、演绎和未经注明出处的转载。          软件规划 软件名称 版本 vmware v15 操作系统 oracle linux 8.8 数据库 19.3.0.0.0 secureCRT 9 主备规划 类型 IP 主机名 db_name db_unique_name instance_name ORACLE_SID

点击上方“IT那活儿”公众号--专注于企业全栈运维技术分享，不管IT什么活儿，干就完了！！！  MySQL 主从复制是一种常见的数据库架构，用于提高数据库的可用性和性能。但是，在实际应用中，主从故障是难免的。本文详细介绍一套MySQL主从故障排查方案。 一 确认主从状态 首先要确定主从复制的状态，可以通过执行以下命令来检查：1）SHOW MASTER STATUS; 命令用于显示主库的状态信息，包

Republication Lags （ 复制延迟）是指在主从数据库复制环境中，从库数据同步落后于主库的时间间隔。 如果复制延迟比较严重，会对系统有不好的影响，如: 1. 数据不一致 从库的数据状态会落后主库，查询从库如果读取到过期数据，会造成数据不一致的情况。 2. 高可用性降低 如果主库宕机，需要故障转移到从库提供服务，但此时从库的数据状态不是最新的，可能会有比较长的服务中断时间。 3. 主从

从进入互联网时代开始，我们从单机走向集群再到当前的微服务架构，我们已经很少再使用单机架构来实现业务逻辑，即使没有使用微服务，但是主备、主从等集群已经属于是业务侧必备能力。 但是，无论是主备还是主从架构，实际上就是为了系统的高可用性实现的一个策略，防止主机因为某些故障导致异常下线，这时候备份或者从实例就会通过选择或者其他策略成为主服务实例，对外继续提供服务。 在MySQL的正常情况下，只要主库执行更