当前随着信息化时代的不断发展,信息系统及数据对于企业,公司,单位越来越重要,相对的信息系统和核心数据的依赖程度也越来越高,如何保障生产数据的安全就显得尤为重要,相信很多企业或公司通过Oracle的EXP/EXPD工具实现生产数据本地的磁盘与磁带的备份,很好的保障了对核心数据的安全管理。并且通过FTP工具,将备份数据传输到其他地方进行备份。但是随着企业或公司对信息系统依赖程度的升高,数据恢复的时间
前言后台服务可以划分为两类,有状态和无状态。高可用对于无状态的应用来说是比较简单的,无状态的应用,只需要通过F5或者任何代理的方式就可以很好的解决。后文描述的主要是针对有状态的服务进行分析。服务端进行状态维护主要是通过磁盘或内存进行保存,比如MySQL数据库,redis等内存数据库。除了这两种类型的维护方式,还有jvm的内存的状态维持,但jvm的状态生命周期通常很短。高可用1、高可用的一些解决方案
从Oracle RAC角度看跨数据中心的存储配置注意事项  Oracle RAC在设计的时候是没有考虑跨数据中心的,它的设计目的是为一个数据中心内有着共享存储的多个主机实现负载均衡和高可用性。但是由于它的架构确实有着跨数据中心实现负载均衡和高可用性的潜力,所以有几家存储设备供应商对它的使用环境做了扩展,提出了跨数据中心的解决方案。Oracle
依托于阿里云高速通道专线、事件总线EventBridge和MSHA(Multi-Site High Availability)多容灾平台,消息队列RocketMQ版提供异地功能,通过跨实例间数据的双向同步和业务切流能力,实现业务恢复和故障恢复解耦,保障故障场景下的业务连续性。本文介绍异地的概念、应用场景、功能优势、使用限制和计费说明。什么是异地容灾MSHA是在阿⾥巴巴电商业务环境
转载 2023-11-13 06:53:28
132阅读
1后台服务后台服务可以划分为两类,有状态和无状态。高可用对于无状态的应用来说是比较简单的,无状态的应用,只需要通过 F5 或者任何的方式就可以很好的解决。后文描述的主要是针对有状态的服务进行分析。服务端进行状态维护主要是通过磁盘或内存进行保存,比如 MySQL 数据库,redis 等内存数据库。除了这两种类型的维护方式,还有 jvm 的内存的状态维持,但 jvm 的状态生命周期通常很短。高可用
     本部分内容在上一篇《vsphere集群应用部署之--搭建mysql-5.7高可用主主-从-HA》的基础上进行了大量改进,启用了新功能并实战将一个业务数据库导入到我们新建的mysql主集群,实现mysql数据库数据迁移。一、主要流程介绍1、mysql数据库存储位置更改(通过mysql配置文件实现)2、开启mysql-Gtid复制模式,实现无主键冲突风险的复
转载 2024-08-26 16:10:09
100阅读
简述异地是一项系统性工作,包含 web 层、应用服务层、数据层的流量分配和同步。数据层的双向同步是整个方案基础,CloudCanal 在 MySQL <-> MySQL 链路有效支持了这个能力,本文简要介绍如何使用 CloudCanal 配置这样的双向同步链路。技术点数据冲突双向同步中, 暂时无法完全通过数据层解决的是数据冲突问题,如一个订单同时在两地被修改价格,到底哪个为准,这个
mysql+keepalive实现浮动地址自动切换,由于keepalive无自带健康检查功能,所以必须自动编写健康检查守护进程(监控DB1和DB2数据库的监控状态,来保证浮动地址双机自动切换。)一,部署说明及拓扑架构:    1、mysql安装在非root用户下(Mysql 版本5.7.18)  2、keepalive安装在root用户下  3、两台服务器安装mysql+keepalive,DB1
转载 2023-12-07 17:34:30
205阅读
摘要:GaussDB(for Redis)推出方案,助力全球化业务部署,为您的数据资产保驾护航! 作者: 高斯Redis官方博客。一、GaussDB(for Redis)方案介绍数据库系统是业务稳定运行的基石,其重要性不言而喻。然而,现实世界存在着的如断电、火灾,甚至是更小概率的地震等突发灾害,这些不稳定因素都会威胁到公司核心业务的连续性。华为云GaussDB(for R
对于单机房而言,只要参考​​Elastic Search 官方文档​​,搭建一个集群即可,示意图如下:原理类似分布式选举那一套,当一个master节点宕机时,剩下2个投票选出1个新老大,整个集群可以继续服务。对于核心系统,只部署单机房总归有点不保险,万一单机房故障就废了(比如:断电断网、或光缆被挖断)。那有同学肯定会想,多弄几个机房,把集群中的节点分散到多个机房不就好了么?理论上讲,上面
转载 2021-03-28 21:05:00
1864阅读
2评论
# MongoDB 异地方案实现指南 在当前的云计算环境中,数据中心的灾备和高可用性至关重要。MongoDB 提供了多种机制来实现数据的高可用性,其中异地方案是一个广泛使用的策略。本指南将教你如何实现 MongoDB 的异地方案。 ## 流程概述 以下是实现 MongoDB 异地方案的概述步骤: | 步骤 | 描述
原创 2024-09-28 04:24:47
141阅读
对于数据实时同步,其核心是需要基于日志来实现,是可以实现准实时的数据同步,基于日志实现不会要求数据库本身在设计和实现中带来任何额外的约束。基于MySQL原生复制主主同步方案 这是常见的方案,一般来说,中小型规模的时候,采用这种架构是最省事的。两个节点可以采用简单的主模式,并且使用专线连接,在master_A节点发生故障后,应用连接快速切换到master_B节点,反之也亦然。有几个需要注意的地方,
摘要:GaussDB(for Redis)的解决方案,支持同域主备、同域主、异地主备、异地主四大应用场景,提供了安全可靠的容灾能力。 一场火灾引发的思考2021年3月10日,欧洲某云服务提供商的数据中心发生火灾,当地消防部门出动上百名消防员才将大火扑灭,受影响的服务器共托管了约360万个网站,火灾过后,这些受影响的网站大多处于关闭状态。机房火灾、网络异常、电力故障、自然灾害等极端场
1、 从地址http://dev.mysql.com/downloads/mysql/中选择windows的版本下载。2、 mysql各个版本的简介 (1) MySQL Community Server 社区版本,开源免费,但不提供官方技术支持。 (2) MySQL Enterprise Edition 企业版本,需付费,可以试用30天。 (3) MySQL Cluster 集群版,开源免费。可将
转载 2024-09-19 12:38:50
14阅读
前几天写了一篇关于业务数据切换思路设计,我今天把下半部分补充一下。首先整个业务的上游是流量入口,分为读流量和写流量,整体是分布式设计。在完成数据迁移,数据同步之后,目前的流量是在“已有数据服务”侧,如果要实现服务的平滑迁移,我们可以按照这个流程来进行设计。首先关闭两个数据服务间的数据旁路,类似下面的图。为了描述更加清晰,我们把读流量和写流量都标识出来,方便区分理解。所以上面步骤可以用下图来进
转载 2024-04-29 21:59:04
344阅读
在当今的信息化时代,数据库的高可用性和灾难恢复能力变得越来越重要。针对“mysql异地方案 分布式数据库”的设计和实现,以下是对整个过程的详细记录。 ## 环境预检 在开展项目之前,首先需要对当前环境进行预检与分析。以下是利用四象限图展示的环境兼容性分析。 ```mermaid quadrantChart title 环境兼容性分析 x-axis 项目复杂度 y-
原创 8月前
42阅读
#### 说明Mysql主主互备即为两个mysql的互为备份机 ##### Windows下安装步骤(Linux下步骤类似,基本就是装上mysql,然后修改配置来完成主从的设置)- step1、下载mysql的zip包(目前测试版本为5.7.28不带debug的包)并解压两次,文件夹改名为master和slave,要安装两台机器或者一台机器用不同的端口装两个实例- step2、在mste
简述之前的一篇文章异地基础之数据双向同步发出来后,很多用户开始测评该方案,有使用稳定的,但也有用户碰到了一些问题(性能和GTID空洞)。为了解决这些问题,我们在 MySQL 到 MySQL 双向同步方案上又多走了一步。相比之前的方案,优势明显。不依赖 GTID不依赖事务的顺序,可并行对端操作减少对云数据库(MySQL)的普遍支持支持表列裁剪、映射以及自定义数据处理技术点防冲突标记GTID 防
后台服务可以划分为两类,有状态和无状态。高可用对于无状态的应用来说是比较简单的,无状态的应用,只需要通过F5或者任何代理的方式就可以很好的解决。后文描述的主要是针对有状态的服务进行分析。服务端进行状态维护主要是通过磁盘或内存进行保存,比如MySQL数据库,redis等内存数据库。除了这两种类型的维护方式,还有jvm的内存的状态维持,但jvm的状态生命周期通常很短。高可用的一些解决方案高可用,从发展
转载 2021-03-28 10:17:29
1264阅读
 1. 异地介绍异地多活在近年越来越多大型互联网公司采用的方案,几乎也是大型应用发展到一定阶段的必然选择,综合比较一下各个互联网公司的方案,会发现有很多共性的东西,也有很多差异化的东西。1.1 什么是异地异地一般是指在不同城市建立独立的数据中心,“”是相对于冷备份而言的,冷备份是备份全量数据,平时不支撑业务需求,只有在主机房出现故障的时候才会切换到备用机房,而多,是指这些
  • 1
  • 2
  • 3
  • 4
  • 5