MySQL 主备切换(Master-Slave Switching)是指在 MySQL 主从复制架构中,将从库(Slave)提升为主库(Master),原主库降为从库的过程。这种切换通常用于故障恢复、负载均衡、系统升级等场景。腾讯云混沌演练平台可对云 MySQL 进行主备切换故障注入,通过混沌实验帮助构建高韧性的系统。
数据存储高可用的方案本质都是通过将数据复制到多个存储设备,通过数据冗余的方式来实现高可用。常见的高可用架构有主备、主从、主从切换、主主等接下来我们聊聊每种架构的优缺点。
腾讯云数据库【国产数据库专题线上技术沙龙】正在火热进行中,4月28日陈爱声的分享已经结束,没来得及参与的小伙伴不用担心,以下就是直播的视频和文字回顾。
对于Oracle Data Guard中的Switchover一般是计划内的操作,自己其实也处理了不少的故障,也算是轻门熟路。复杂的事情简单做,简单的事情重复做,重复的事情用心做,想必很多事情都是这个理吧。 发现很多事情虽然做了很多遍,但是每次都会有不同的体会,而这些积累下来的经验才让我们的经验更加宝贵。 一般来说Oracle的Switchover需要考虑的细节较多,大体有以下的流程。 1.在迁移之前明确目标服务器IP,发出维护公告 这个无需多说,本身就是跨部门,多部门的协调工作,说简单简单,说复杂复
数据库作为信息系统重要的基础设施,一直承担着压舱石的角色。互联网应用的高并发、海量数据使得数据库的负载越来越重,这在数据大集中的情况下愈发明显。而数据库作为信息系统唯一的“单点”,稳定性、可用性是首先要保证的目标。这里的单点并不是指数据库没有高可用方案,而是因为数据库只要涉及到数据的复制就一定是有状态的,有状态的应用更加难以运维,并且在遭遇异常时并不能做到真正意义上的无缝切换。
这篇文章计划了一段时间,本来想写篇心情文字,还是留到周末再放飞心情吧。 今天的内容是关于数据库的备库的思考,当然我们可以自己问自己,我们的备库准备工作做好了吗?扪心自问,其实有些工作我也没有准备好,这是我的建议,其实一个备库的思考点还是有很多值得考量和斟酌的地方。自己也需要后续完善 备库总是在容灾中有着举足轻重的作用,但是故障难免,我们的备机备库是否能够在危机降临的时候顶住压力,这个需要打上一个问号,我会从硬件配置,系统层面,数据库层面,架构层面和网络层面进行一些分析。 硬件配置 备库硬件配置更差
在互联网项目中,当业务规模越来越大,数据越来越多,随之而来的就是数据库压力会越来越大。慢慢就会发现,数据库层可能已经成为了整个系统的关键点和性能瓶颈了,因此实现数据层的高可用就成为了我们项目中经常要解决的问题。
洪嘉铭,就职于世纪证券信息技术部,目前负责运维、监控系统的相关架构设计、开发工作。对操作系统、网络编程、服务器后台架构有丰富实践经验。
至于pg为什么不做这个功能我也想了很久,下面是我自己的一点猜测。pg是个追求完美主义的数据库,他从架构设计层面就会考虑如何做到完美,比如说他不用主流数据库都在使用的undo,我猜测这个原因是因为,使用undo有一个问题,undo空间不管是文件系统还是表空间都是有大小限制的,而数据库未提交的事务信息可能是无限大的,这样数据的前镜像总有可能将undo空间撑爆掉,这样就需要清理旧的undo段,如果需要查询的undo前镜像备清理了,数据库就会跑出错误,这就是oracle中经典的snapshot too old报错。所以pg摒弃了这种模式,因为他觉得必须要提供给用户一个需要的数据一定能查到的数据库,而不是本该能查到的数据被无端清理掉了,所以pg使用了多数据版本来解决这个问题,将前镜像的真实数据放在数据文件中,真正确保没有事务可能再去访问该数据时才进行清理。当然这样也带来膨胀的问题,这其实也是pg最遭人诟病的问题。
DG的主备角色转换分为:Switchover和Failover。Switchover适用于某些场合,需要将备库转为主库,Failover则是在主库故障无法使用情况下,将备库提升为主库。
相对于过去单体或 SOA 架构,建设微服务架构所依赖的组件发生了改变,因此分析与设计高可用容灾架构方案的思路也随之改变,本文对微服务架构落地过程中的几种常见容灾高可用方案展开分析。
很多开发者可能都没有接触过 MySQL 的架构部署,但是大多数应该都听过集群架构吧。其实 MySQL 集群架构,总结来说一共有好多种,今天我主要总结一下其中常用的 8 种集群架构。
前几天看到某大型家电工厂的工业互联网系统架构图,发现用MongoDB存储图片及视频。那Redis同样也是Json类型的远程数据字典服务器,也可以用于存储图片、视频。实际Redis可以用512MB的空间存储用于存储字符串型的数据。
今天在测试环境遇到一个很有意思的问题,我们在测试一款分布式数据库,这款分布式数据库底层是基于postgresql做的,现象大致是这样的,我们在重启数据库集群后发现某台机器的数据节点启动失败,然后去那台机器上发现进程确实没有启动。然后看了下运行日志,定位到了启动失败的原因,是内存不够用了,查了下该节点上还运行着其他数据库,由于其他数据库也占了一部分内存,造成该节点数据库由于内存不足启动失败。
在数据库环境中,一主一备是比较传统的使用方式,在灾难发生的时候,可以灵活的切换主备角色,依然可以保持服务的可访问性。但是一些核心系统来说还是会有更多的过滤,一主一备似乎还是不够稳妥,如果主备出现问题,如果有另外一个备库还是有可选的余地,这种情况不是不可能发生,正是因为核心业务的需要还是需要保证数据的安全。 很多场景下,一主两备会保持这样的场景,一主一备在同一个区域内,这样在出现问题的时候方便切换,如果区域出现故障,可以保证异地的机房可以顺利承接服务。 比如下面的这种方式是比较传统的一主一备的方式。因为是在1
在上一篇文章中,介绍了 binlog 的基本内容,在一个主备关系中,每个备库接收主库的 binlog 并执行。
| 作者:杨壮壮 ,腾讯PCG运营开发工程师 ,目前主要从事 MDB(MySQL 云管平台)的后台开发与技术运营的工作,是一个做开发的DBA。熟悉腾讯自研数据库TDSQL的架构原理、集群管理维护、内核SQL优化等。MDB团队承载着整个PCG 关系型数据库的管理与运维工作,支撑着腾讯视频、看点等业务稳定运行。 1 Part1 前言 在今年的三月份,我们举办过一届数据库武林大会,在这场活动沙龙中,有辩手犀利地指出,数据库运维的薪资水平和数据库使用人数并不成正比,有数据表明一些小众但强大的数据库,其DBA的平均
最近也在对容灾的切换做一些改进。 目前碰到的问题有 1.灾难切换后备库的内核参数设置不到位,导致切换后又潜在的性能问题 2.灾难切换后在同机房,网络相关的情况下,需要切换备库的IP为主库,但是跨机房,跨IDC可能不行,可以修改IP的情况下,对应用基本是透明,但是如果修改IP就需要应用修改配置。 3.灾难切换之后防火墙信息在主库无法得到的情况,在备库只能关闭防火墙,或者设置最大的访问权限 4.原来主库中的db link可能无法正常解析,如果解析不当或者依赖较多,会有数据库负载成百倍暴涨的可能性 5.原来主库启
今天下午我的一个朋友碰到了一个Data Guard的问题,大体是主备网络出现问题,因为环境中配置了自动切换,结果备库就自动切换为了主库,这样就成了“双主”,我帮忙看了下,对备库做了闪回,然后直接转换主库为备库角色,一个看似繁琐的修复工作就完成了。 在一个一主多备的环境中,的确需要一个强大的工具来支持,所以最后朋友说DG Broker真是个好东西,我回了句 用好了DG Broker,手工管理Data Guard就是小米加步枪啊。 就如同我昨天文章Data Guard故障自动切换的想法(r11
腾讯云原生数据库 TDSQL-C(Cloud Native Database TDSQL-C,TDSQL-C)是腾讯云自研的新一代高性能高可用的企业级分布式云数据库。融合了传统数据库、云计算与新硬件技术的优势,100%兼容 MySQL 和 PostgreSQL,实现超百万级 QPS 的高吞吐,128TB 海量分布式智能存储,保障数据安全可靠。 本文由腾讯云数据库高级工程师唐颋为大家详细解读TDSQL-C PostreSQL的高可用特性。 TDSQL-C PG版产品简介 TDSQL-C PG版是一款基于计算、
在很多的时候,随着工作的持续开展,可能会接手更多的服务器资源,这个时候我们手里就不但是一两台服务器那么简单,可能几十个,上百个,甚至上千个,这个时候服务器信息的维护就变得额外重要,抛开业务线的规划,对于DBA来说,掌握服务器的信息,做到知根知底,才能在问题发生的时候合理处理问题。 服务器信息可以分成几个方面来看,比如操作系统情况,内核版本,硬盘,内存,空间使用情况,累计运行时间,数据库实例运行时间,系统中的swap争用情况等等,尽可能根据实际的情况进行一些维度的划分和细粒度的归纳。 比如说在生产中,考虑容灾
数据库作为企业数据的管理软件,是企业的核心资产,需要避免单点灾难,因此数据库灾备需求应运而生。
软件架构的出现是为了解决系统规模增加后出现了系统耦合严重,开发效率低,逻辑复杂,扩展困难等问题。所以架构设计是为了解决软件复杂度而存在的,所以架构设计的目地是识别出需求的复杂点然后针对性的解决。系统设计时需要考虑:性能,系统的可扩展性,安全性,高可用,成本。 架构师的工作并不神秘,成熟的架构师需要对已经存在的技术非常熟悉,对已经经过验证的架构模式烂熟于心,然后根据自己对业务的理解,挑选合适的架构模式进行组合,再对组合后的方案进行修改和调整。
如今是数据驱动时代,数据库作为企业的核心资产之一,其安全性和稳定性显得尤为重要。然而,面对复杂多变的业务场景和不断演变的技术挑战,如何把握现有数据库架构可承受故障的故障级别、发生故障后的高可用性方案是否有效,成为了许多数据库用户关注的焦点,也是腾讯云MySQL在服务众多重保用户时思考的问题。
看这里的name是否和你的服务器的计算机名称一样,如果一样可以跳到文档(二),否则请按如下操作更改
Oracle ADG全称为Oracle Active Data Guard,它是Oracle Data Guard功能集中的一个高级选项。Active Data Guard是Oracle数据库提供的一种高级高可用性和灾难恢复解决方案,它在Oracle Data Guard的基础上进一步增强了备用数据库(Standby Database)的功能和利用率。
本篇梳理DG的架构和一些概念知识,重新梳理的目的是加强理解,也方便复习,基于11gR2版本写的,不包含12c新特性。如果能帮助到新接触DG的朋友,那就再好不过。
文章主要介绍了分布式数据库在金融互联网场景下的设计和实现,包括DCDB的架构、基础环境、实例配置、功能、性能、以及扩展性。同时,还探讨了分布式数据库在云原生架构下的应用和挑战,以及TDSQL在金融云上的解决方案和案例。
针对Oracle迁移上云项目,云提供给用户的物理机上加载有三张网卡供用户使用,一张用于跑业务,另外两张可以用于心跳线网络。另外,存储网络是单独的网口,在建设时已由服务商做好配置,不含在这三张网卡内。基于公有云技术,为了组建资源池内部管理控制专网,因此现市面上公有云提供商的IPMI端口,均不能提供出来用于对外访问。
Zabbix 高可用为运行Zabbix Server 的服务器提供了针对软件/硬件故障的保护,并允许在软件/硬件维护期间最大限度地减少停机时间。
DG 的工作原理是通过网络将主数据库的重做数据传输到备用数据库,然后在备用数据库上应用这些重做数据,以确保数据的一致性。
导语:沃趣科技的QBackup数据库备份容灾云平台,是一套集合了CDP备份,历史数据秒级恢复,灾备保护等功能的一体化云平台。支持主流的Oracle、MySQL等数据库,可同时对大量数据库做集中式备份和管理,并对备份进行持续校验以确保数据的可恢复性。QBackup同时可用于应用测试、预发布、性能优化、POC等诸多应用场景。 继QBackup v4.0.0版本发布之后,沃趣科技持续深化对于数据库备份容灾产品的研发,于近日正式发布了QBackup v4.1.0版本,消除了旧版本中已知的风险点,同时增加了多项新功能
题记: 文章内容输出来源:拉勾教育Java高薪训练营。 本篇文章是 MySQL 学习课程中的一部分笔记。
最近又试了下Data Guard的新玩法,可以通过闪回恢复switchover的主库,这种场景听起来比较特别,但是Oracle依旧支持。 我们的大体思路就是,在主库我们标记一下数据状态,然后做
主备切换是很正常的操作,比如服务下线,断电,软件升级等等,首先我们先了解另外一个概念就是同步延迟,与数据同步的三个时间点如下
主备切换有两种场景,一种是主动切换,一种是被动切换。而其中被动切换,往往是因为主库出问题了,由 HA 系统发起的。
为帮助开发者更好地了解和学习分布式数据库技术,2020年3月,腾讯云数据库、云加社区联合腾讯TEG数据库工作组特推出为期3个月的国产数据库专题线上技术沙龙《你想了解的国产数据库秘密,都在这!》,邀请数十位鹅厂资深数据库专家每周二和周四晚上在线深入解读TDSQL、CynosDB/CDB、TBase三款鹅厂自研数据库的核心架构、技术实现原理和最佳实践等。三月为TDSQL专题月,本文将带来直播回顾第二篇《破解分布式数据库的高可用难题:TDSQL高可用方案实现》。
在一个生产系统中,通常都需要用高可用方案来保证系统的不间断运行。PostgreSQL 本身不支持任何多主群集解决方案,例如MySQL或Oracle。尽管如此,仍有许多商业和社区产品提供此实现,以及其他产品,例如PostgreSQL的复制或负载平衡。
腾讯云网络自研路由平台—FCR 云网络厂商在用户接入侧一般采用传统网络设备如路由器、交换机,传统网络设备虽然功能稳定,但是开发周期较长,支持功能无法快速匹配互联网厂商日新月异的应用场景。为了解决上述问题,腾讯云网络在接入时使用了FCR(Fast Cloud Router)作为自己的路由控制平台。 FCR自研路由平台不仅支持BGP、静态路由、BFD等各类路由相关协议,同时还可以提供丰富的路由策略以及百万级的路由管理功能。 平台开放:完全基于开源组件构建,打破了传统设备厂商封闭的产品生
关系数据库的事务(transaction)是一组操作序列,比如读,插入,删除,更新等等。事务有四个基本要素,即原子性(Atomicity)、一致性(Consistency)、隔离性(Isolation)、持久性(Durability),即ACID:
在使用数据库时,表的主键经常会使用数据库的自增(auto_increment)来产生。这当然很方便也很高效。但是使用自增也会带来一些麻烦。如果从一个数据库以外的地方,也就是发号器来产生全局唯一 ID,这些问题就可以得到解决,生活就可以更美好。
腾讯云数据库国产数据库专题线上技术沙龙正在火热进行中,3月12日张文的分享已经结束,没来得及参与的小伙伴不用担心,以下就是直播的视频和文字回顾。
在云网融合大数据时代,数据已经成为重要的生产要素。特别是棱镜门、永恒之蓝、汶川大地震这类造成大规模数据丢失和泄漏的人为或自然灾害事件发生后,中国相继出台了一系列的法律法规,对各组织机构的数据安全保护条件进行限定,如 2016 年颁布的《中华人民共和国网络安全法》、 2021 年全国人民代表大会通过的《数据安全法》等。
正常情况下,只要主库执行更新生成的所有binlog,都可以传到备库并被正确执行,备库就能达到跟主库一致的状态,这就是最终一致性。
腾讯数据库技术发展之路 我来自腾讯TEG计费平台部,一开始负责公司整个计费体系的存储系统研发,现在主要负责TDSQL数据库的研发。这是我们产品的几个发展阶段: 我是2007年进入公司的,在此之前公司业
随着客户上云的加快,客户越来越希望直接采用云上的数据库系统支撑业务发展,作为服务商来讲,了解云上的数据库的应用场景及常见特性成为必然。否则,将出现与客户交流困难,影响项目成效的麻烦事。今天我们讲五种常见的云数据库,这些内容也是在与客户沟通交流中的常见问题。
TDSQL是腾讯提供的一套完整的MySQL数据库集群化管理解决方案,作为私有云TStack平台重要的数据库产品能力,旨在解决高可用、高性能、分布式、配套设施等方面问题。 TDSQL除了在腾讯内部有大量的使用场景,在外部市场中也有诸多应用场景;2014年被WeBank选中,作为其核心交易系统的数据库解决方案,以私有云方式交付;2015年,在腾讯云上正式推出。目前已经为500+机构提供数据库的公有云及专有云服务,客户覆盖计费、第三方支付、银行、保险、互联网金融、物联网、互联网+、政务等领域。 TDSQL私有云版
领取专属 10元无门槛券
手把手带您无忧上云