从这期开始讲Oracle Data Guard方面的内容,先将基本的概念,然后介绍如何搭建Data Guard
从这期开始讲Oracle Data Guard方面的内容,先讲基本的概念,然后介绍如何搭建Data Guard
一旦使用 MySQL 的复制功能,就很大可能会碰到主备切换的情况。也许是为了迭代升级服务器,或者是主库出现问题时,将一台备库转换成主库,或者只是希望重新分配容量。不过出于什么原因,都需要将新主库的信息告诉其它备库。
正常情况下,只要主库执行更新生成的所有binlog,都可以传到备库并被正确执行,备库就能达到跟主库一致的状态,这就是最终一致性。
② kill -9 mysqld 或者 reboot 服务器 结果状态:有可能同①,也有可能是双Yes(我自己测试的是同①结果,看别人测的有的是双yes)
MySQL 本身通过 show slave status 提供了 Seconds_Behind_Master ,用于衡量主备之间的复制延迟,但是今天碰到了一个场景,发现 Seconds_Behind_Master 为 0 , 备库的 show slave status 显示 IO/SQL 线程都是正常的 , MySQL 的主库上的变更却长时间无法同步到备库上。如果没有人为干预,直到一个小时以后, MySQL 才会自动重连主库,继续复制主库的变更。 影响范围: MySQL , Percona , MariaD
本篇梳理DG的架构和一些概念知识,重新梳理的目的是加强理解,也方便复习,基于11gR2版本写的,不包含12c新特性。如果能帮助到新接触DG的朋友,那就再好不过。
Oracle数据库的日志传递机制是指将重做日志从产生的数据库服务器传递到备库服务器,并在备库上应用这些重做日志以保持与主库的一致性。
在上一篇文章中,介绍了 binlog 的基本内容,在一个主备关系中,每个备库接收主库的 binlog 并执行。
主备切换是很正常的操作,比如服务下线,断电,软件升级等等,首先我们先了解另外一个概念就是同步延迟,与数据同步的三个时间点如下
DG 的工作原理是通过网络将主数据库的重做数据传输到备用数据库,然后在备用数据库上应用这些重做数据,以确保数据的一致性。
最近也在对容灾的切换做一些改进。 目前碰到的问题有 1.灾难切换后备库的内核参数设置不到位,导致切换后又潜在的性能问题 2.灾难切换后在同机房,网络相关的情况下,需要切换备库的IP为主库,但是跨机房,跨IDC可能不行,可以修改IP的情况下,对应用基本是透明,但是如果修改IP就需要应用修改配置。 3.灾难切换之后防火墙信息在主库无法得到的情况,在备库只能关闭防火墙,或者设置最大的访问权限 4.原来主库中的db link可能无法正常解析,如果解析不当或者依赖较多,会有数据库负载成百倍暴涨的可能性 5.原来主库启
正常情况下,只要主库执行更新生成的所有 binlog,都可以传到备库并被正确地执行,备库就能达到跟主库一致的状态,这就是最终一致性。
第10章 复制 复制是通过在主库记录二进制日志,然后再在备库重放日志的方式来实现异步的数据复制。 复制通常不会对主库产生开销,主要是启用二进制日志带来的开销。除此之外每个备库也会对主库增加一些负载,例如网络io开销 复制如何工作: 在主库上把数据更改记录到二进制日志中。 备库将主库的日志复制到自己的中继日志中。 备库读取中继日志中的事件,将其重放到备库数据之上。 二进制日志是由服务器层面去实现的,事务日志是存储引擎层面的。先记录了二进制日志之后,MySQL才会去提交相关事务。 创建复制账号的时候虽然可以只设
关于半自动化搭建Data Guard,自己花了一些时间,总算是把这件事情继续推进了一下,还是再啰嗦一句,为什么不自动化,因为安全。主库就是主库,任何变更都要手工检查审核, 自动化的工作在备库和中控端来完成。我希望自己的脚本能够只知道主库的IP,不用一次又一次连过去配置和检查,当然要完成自动化还是半自动化,有些网友也提醒的极是,那就是规范和标准。 预先条件: 1.目前的设计是基于11.2.0.4的版本,当然这个很容易定制,在此是作为一个基本的标准,作为环境的初始化和Data Guard对的搭建的基线。 2.
MySQL 主从复制的问题及解决方案
Oracle ADG全称为Oracle Active Data Guard,它是Oracle Data Guard功能集中的一个高级选项。Active Data Guard是Oracle数据库提供的一种高级高可用性和灾难恢复解决方案,它在Oracle Data Guard的基础上进一步增强了备用数据库(Standby Database)的功能和利用率。
关系数据库的事务(transaction)是一组操作序列,比如读,插入,删除,更新等等。事务有四个基本要素,即原子性(Atomicity)、一致性(Consistency)、隔离性(Isolation)、持久性(Durability),即ACID:
一般情况下,我们是通过"show slave status \G;"提供的Seconds_Behind_Master值来衡量mysql主从同步的延迟情况。具体说明见:mysql主从同步(4)-Slave延迟状态监控,这种方法在大多数情况下确实是可行的。但是经验告诉我,仅仅依靠Seconds_Behind_Master的值来监测主从同步数据是否延迟是绝对不可靠的!!! 曾经遇到过的一个坑: Mysql主从环境部署后,刚开始主从数据同步是没问题的,也是通过监控Seconds_Behind_Master的值来判断
Oracle Data Guard主要是通过为生产数据库提供一个或多个备用数据库(是产生数据库的一个副本),以保证在主库不可用或异常时数据不丢失并通过备用数据库继续提供服务。对于Oracle DG的配置,我们可以通过Grid Control来完成,也可以通过Data Guard Broker以及SQL*Plus来完成。对于前两者方式可以在图形界面上完成,操作简单。而对于使用SQL*Plus命令行方式,我们需要进行大量的配置,尤其是这其中的一些参数。本文主要描述配置Oracle Data Guard 的重要参数。下面关于Data Guard简称为DG。
Oracle Data Guard逻辑备库是利用主库的一个备份首先建立一个物理备库,然后再将其转换为逻辑备库。这之后主库将日志传递到备库,备库利用logminer从主库的日志中解析出主库所执行过的SQL,在备库上重新执行一遍,从而保证与主库的数据在逻辑上保持一致。与物理备库相对应的是,物理备库使用的是redo apply,逻辑备库使用的是sql apply。因此逻辑备库仅仅保证数据与主库是在逻辑上是一致的,从而逻辑备库可以处于open状态下并进行相应的DML操作。本文描述了创建逻辑备库的注意事项以及给出了如何创建逻辑备库。
2.备库的压力大。主库提供写能力,备库提供一些读能力。忽略了备库的压力控制,导致备库上的查询耗费了大量的CPU资源,影响了同步速度,造成主备延迟
MySQL 主备切换(Master-Slave Switching)是指在 MySQL 主从复制架构中,将从库(Slave)提升为主库(Master),原主库降为从库的过程。这种切换通常用于故障恢复、负载均衡、系统升级等场景。腾讯云混沌演练平台可对云 MySQL 进行主备切换故障注入,通过混沌实验帮助构建高韧性的系统。
作为一名开发同学,大家对 MySQL 一定不陌生,像常见的 事务特性、隔离级别 、索引等也都是老生常谈。
在状态1中,客户端的读写都直接访问节点A,而节点B是A的备库,只是将A的更新都同步过来,到本地执行。这样可以保持节点B和A的数据是相同的。当需要切换的时候,就切成状态2。这时候客户端读写访问的都是节点B,而节点A是B的备库
数据库作为信息系统重要的基础设施,一直承担着压舱石的角色。互联网应用的高并发、海量数据使得数据库的负载越来越重,这在数据大集中的情况下愈发明显。而数据库作为信息系统唯一的“单点”,稳定性、可用性是首先要保证的目标。这里的单点并不是指数据库没有高可用方案,而是因为数据库只要涉及到数据的复制就一定是有状态的,有状态的应用更加难以运维,并且在遭遇异常时并不能做到真正意义上的无缝切换。
Postgresql从9.1开始支持流复制,流复制的出现是一次革命,因为它速度非常快,性能很好。流复制是基于wal日志的复制技术,主库不断发送wal日志至备库,备库进行应用回放。
复制解决的基本问题 让一台服务器的数据让其他服务器保持同步,一台主库的数据可以同步到多台备库上,悲苦本身也可以被配置成另外一台服务器的主库。 MySQL支持两种复制方式:基于行的复制和基于语句的复制(逻辑复制)。这两种都是在主库上记录二进制日志,在备库重放日志的方式来实现异步的数据复制, 这说明同一时间主备库存在不一致,并且无法保证主备之间的延迟。 常见的复制用途 数据分布:MySQL通常复制不会造成很大的贷款压力,但基于行的复制会比基于语句的复制带宽压力大, 可以随意停止或开始复制,并在不同的地理位置来分
一个DG环境中只有两种角色:Primary和Standby。所谓角色转换就是让数据库在这两种角色中切换,切换也分两种:Switchover和Failover,关于角色切换需要注意以下几点:
Data Guard作为Oracle提供的一个高可用及灾备解决方案,理解并可以实施它对于DBA来说是非常重要套的技能
Postgresql主从复制 📷 主备数据库启动,备库启动wal_receiver进程,wal进程向主库发送连接请求; 主库收到连接请求后启动wal_sender进程,并与wal_receiver进程建立tcp连接; 备库wal_receiver进程发送最新的wal lsn 给主库; 主库进行lsn 对比,定期向备库发送心跳信息,来确认备库的可用性,并且将没有传递的wal日志文件进行发送,同时调用SyncRepWaitForLSN()函数来获取锁存器,并且等待备库响应;锁存器的释放时机和主备同步模式的选择有
作者介绍 黄堋 多年一线DBA经验,曾服务于电信、电网、医院等行业客户。擅长数据库优化、数据库升级迁移、数据库故障处理 当主备同步中断了,备库想快一点恢复,偏偏这个时候归档太多恢复不过来或者说需要的归
1.3.2 备库切换到open状态,启用Real-time query A physical standby database instance cannot be opened if Redo Apply is active on a mounted instance of that database. Use the following SQL statements to stop Redo Apply, open a standby instance read-only, and restart Redo Apply:
报错是备库事务或者单SQL查询时间长,和备库的日志apply发生冲突,如果业务上有长事务、长查询,主库上又再修改同一行数据,很容易造成备库的wal日志无法apply。
读写分离的主要目标就是分摊主库的压力。图 1 中的结构是客户端(client)主动做负载均衡,这种模式下一般会把数据库的连接信息放在客户端的连接层。也就是说,由客户端来选择后端数据库进行查询。
主库(Primary Database)在运行过程中,会源源不断地产生Redo日志,这些日志需要发送到备库(Standy Database)端。这个发送动作可以由主库的LGWR或者ARCn进程完成,不同的归档目的地可以使用不同的方法,但是对于一个目的地,只能选用一种方法。选择不同的进程在数据保护能力和系统可用性方面有很大区别。如果使用LGWR进程来传递日志,但是由于某些原因,LGWR进程变得无法归档到目的地了,那么重做传输将会使用ARCn进程来完成归档操作。
MySQL 内置的复制功能是构建基于 MySQL 的大规模、高性能应用的基础,复制解决的基本问题是让一台服务器的数据与其他服务器保持同步。
就像在“传统关系数据库高可用的缺失”一文中所看到的,高可用在传统关系数据库的理论和实践上都是缺失的,这使得传统数据库无法做到主库备库完全一致,为了减少主库故障对业务的影响不得不使用昂贵的高可靠硬件,缺乏高可用还导致了分布式OLTP数据库缺失、无法水平伸缩从而使得高并发业务不得不采用更加昂贵的大型服务器等。作为分布式关系数据库,OceanBase必须解决这个问题。那么,采用普通PC服务器的OceanBase是如何做到高可用的呢?
读写分离的主要目的就是分摊主库的压力。上图中的结构是客户端主动做负载均衡,这种模式下一般会把数据库的连接信息放在客户端的连接层。由客户端来选择后端数据库进行查询
Postgresql9开始支持流复制(stream replication),作为pg原生的复制技术,有着很好的性能。本文从几个方面全面介绍pg的流复制技术。
DG的主备角色转换分为:Switchover和Failover。Switchover适用于某些场合,需要将备库转为主库,Failover则是在主库故障无法使用情况下,将备库提升为主库。
正所谓理论造航母,现实小帆船。单有理论,不动手实践,学到的知识犹如空中楼阁。接下来,我们一起来看下如何一步步进行 MySQL Replication 的配置。
在上一篇文章中,我和你介绍了一主多从的结构以及切换流程。今天我们就继续聊聊一主多从架构的应用场景:读写分离,以及怎么处理主备延迟导致的读写分离问题。
不知道是否有人关注到下面这个错误日志,在一个异步流复制的环境中,我们在主库看到如下日志:
记录一起由于DG主备库之间出现GAP,归档日志丢失,导致备库无法应用日志同步的故障。
DG提供了3种数据保护模式(Protection Mode):最大保护(Maximum Protection)、最高性能(Maximum Performance)和最高可用(Maximum Availability),如下表所示:
随着Oracle ADG技术的逐渐成熟,大多数数据库环境都使用ADG作为灾备和报表数据库,可以说是标配。
领取专属 10元无门槛券
手把手带您无忧上云