首页
学习
活动
专区
圈层
工具
发布
    • 综合排序
    • 最热优先
    • 最新优先
    时间不限
  • 来自专栏JavaEdge

    、主从和区别

    两台都是主机,同时对外提供读写操作。客户端任意访问提供的一台。 主从

    3.5K20发布于 2021-10-18
  • 来自专栏JavaEdge

    、主从和区别

    两台都是主机,同时对外提供读写操作。客户端任意访问提供的一台。 主从

    2.3K21编辑于 2021-12-07
  • 来自专栏云攻略专区

    【最新】如何通过云联网和 VPN 连接实现混合云冗余通信?

    连接实现云上云下业务互通,为提升业务高可用性,可同时创建云联网和 VPN 连接服务,配置两条链路为主链路,来实现冗余通信。 本文指导您如何配置云联网和 VPN 链路来实现云上云下业务通信。 为了解路径的连接质量,需要分别配置两条路径的网络探测,实时监控到网络连接的时延、丢包率等关键指标,以探测路由的可用性。 登录 网络探测控制台。 配置完成后,即可查看云联网和VPN连接路径的网络探测时延和丢包率。说明: 更多详细配置请参考 网络探测。 步骤五:切换路由 当收到云联网主路径的网络探测异常告警时,您需要手动禁用主路由,将流量切换至 VPN 网关备份路由上。 登录 路由表控制台。

    6.1K21编辑于 2021-12-27
  • 来自专栏立权的博客

    Mysql 原理

    Mysql 支持互为主从,主库通过binlog 将执行的语句传给从库,具体的执行机构:

    2.4K10发布于 2020-11-27
  • 来自专栏白驹过隙

    Redis - Keepalived + redis 切换

    方案 硬件:server两台,分别用于master-redis及slave-redis 软件:redis、keepalived 实现目标: 由keepalived对外提供虚拟IP(VIP)进行 redis访问 主从redis正常工作,负责处理业务,从进行数据备份 当出现故障时,从切换为主,接替的业务进行工作 当恢复后,拷贝从的数据,恢复身份,从恢复从身份 数据采用aof方式进行持久化存储 当出现故障后能及时处理,切换从机提供业务。 2. 环境准备 利用虚拟机进行测试,安装ubuntu,安装完成后克隆ubuntu,利用两个虚拟机来构造服务器环境。 热测试 1. 主从启动所有服务 Service redis start Service keepalived start 2. 在master执行ip a查看虚拟IP是否绑定成功 ?

    4.3K110发布于 2018-05-18
  • YashanDB 知识库|切换怎么做?一 & 一完整操作指引

    在 YashanDB 的生产部署中,为保证业务连续性,架构是最常见的高可用模式。 本文将基于实际项目总结,一文讲清:切换的操作方式(手动与自动);一与一两备下的差异;切换过程中应注意的细节。 手动切换操作(1)Switchover —— 主动切换,适用于同步正常所有连接将被断开,切换过程中主库不可用;建议在业务低峰期执行;操作需在库执行:-- 检查状态yasboot cluster -d四、一架构下切换方式YashanDB 在一部署下,默认启用 最大保护模式 + 自动选主机制。 五、常见问题排查六、经验小结一默认关闭自动切换,需手动开启;一默认启用最大保护 + 自动选;Switchover 适用于可控切换场景,Failover 用于主库不可恢复场景;建议日常巡检时确认切换机制配置状态

    46700编辑于 2025-05-12
  • 来自专栏数据和云

    MogDBopenGauss 手动部署(非OM工具)单机、级联架构

    启动数据库 gs_ctl start -D /opt/mogdb/data 至此单机安装完成 三、安装 1. IP,remotehost为主库IP 构建关系 gs_ctl build -D /opt/mogdb/data/ -b full -M standby 查询状态 主库 [omm@mogdb-kernel : 100% channel : 172.16.0.245:60856<--172.16.0.106:26001 至此已安装完成 四、级联安装 1. 安装如上(一,二,三) 2. 构建关系 gs_ctl build -D /opt/mogdb/data/ -b full -M cascade_standby 4.查看级联状态 主库 [omm@mogdb-kernel-0001

    1.5K20发布于 2021-07-30
  • 来自专栏xuefly

    postgresql配置步骤

    启动postgressql: pg_ctl -D /opt/pgsql/data/ -l logfile start (192.168.205.145): 1. 说明该节点是从服务器 primary_conninfo = 'host=192.168.205.145 port=5432 user=postgres password=postgres' # 服务器的信息以及连接的用户 在从机上测试主机 su - postgres psql -h 192.168.205.145 -U postgres 验证同步状态: ps aux | grep wal 主机上有 wal

    2K30编辑于 2022-12-29
  • 来自专栏DataOps

    PostgreSQL库搭建

    pg库的搭建,首先需在2个节点安装pg软件,然后依次在2个节点配置。本文采用os为CentOS7.6,pg版本使用14.2,以下为详细部署步骤。 启停数据库pg_ctl statuspg_ctl startpg_ctl stop■ 客户端工具使用开源的pgAdminSet Master Password: postgres■■■ 主从配置■■ 节点

    3.2K21编辑于 2022-10-13
  • 来自专栏玉龙小栈

    【实验】VRRP部署

    VRRP部署 ? 实验需求: PC优选R1为网关,当R1失效选择R2作为网关 1、配置IP地址。 2、R1,R2,R3互联网段以及连接PC的网段还有R3的Loop0接口运行RIP 1。 4、验证: (1)验证VRRP的备选择情况。 (2)验证PC1、PC2访问3.3.3.3是否优选R1。 GigabitEthernet0/0/1 [R2-GigabitEthernet0/0/1] vrrp vrid 1 virtual-ip 192.168.1.254 4、验证: (1)验证VRRP的备选择情况

    1.3K20发布于 2021-02-24
  • 来自专栏JavaEdge

    分布式Redis复制复制流程断点续传

    当数据落在不同节点上时,如何保证数据节点之间的一致性是非常关键的 Redis采用复制的方式保证一致性,所有节点中,只有一个节点为主节点(master),它对外提供写服务,然后异步的将数据复制到其他节点上 复制流程 Redis包含master 和slave 2种节点: master 对外提供写服务 slave 节点作为master的数据备份,不可以提供写服务 复制由master 主动触发 ? 这一步在slave启动后触发,master 被动的将新slave节点加入主复制集群 2、master收到SYNC后,开启BGSAVE 操作。 Redis的 PSYNC(Partial Sync)可以用于代替SYNC,做到master-slave基于断点续传的同步协议。

    1.3K20发布于 2018-08-22
  • 来自专栏杨建荣的学习笔记

    PostgreSQL环境搭建

    关于环境的搭建,我使用的基于流复制的方式搭建,这是在PG 9.0之后提供的对WAL传递日志的方法,是基于物理复制,在9.4开始有了逻辑解码,而细粒度的逻辑复制在PG 10中会有较大的改进。 2 3 配置主库 使用的环境是两台服务器 192.168.179.128 主库 192.168.253.134 库 1)创建一个复制角色 CREATE ROLE replica login replication encrypted password 'replica'; 2)配置访问权限文件gp_hba.conf 添加一条记录,使得库可以访问,修改后需要重启 host replication replica 这个时候库上还没有初始化数据,我们模拟客户端的方式来访问,可能会有如下的错误。 max_standby_streaming_delay = 30 wal_receiver_status_interval = 1s hot_standby_feedback = on 4)启动PG

    2.2K60发布于 2018-03-30
  • YashanDB 单机()部署

    yasdb_data" # 为DATA目录,安装后修改也不会生效,除非重新安装 hostid = "host0001" # 安装后修改也不会生效,除非重新安装 role = 1 # 数据库角色 部署步骤 1:生成部署文件执行 yasboot package 命令生成配置文件,命令详细参数可查阅yasboot。 $ . 若所安装环境为高可用的 Raft 集群(自动选),还需参考高可用。 yasdb_data" # 为DATA目录,安装后修改也不会生效,除非重新安装 hostid = "host0001" # 安装后修改也不会生效,除非重新安装 role = 1 # 数据库角色 如需重建库请执行库 BUILD 操作。

    32810编辑于 2025-03-06
  • 来自专栏腾讯云大数据与AI专家服务

    Yarn ResourceManager 切换

    状态的 ResourceManager 转成 StandBy 状态,原先处于 StandBy 状态的 ResourceManager 转成 Active 状态Yarn ResourceManager 切换 / 持续切换可能影响:YARN 服务无响应作业无法提交无法查看当前任务状态处理建议:分析日志查看监控排查切换原因,分场景解决 场景1 新增或变革参数无效 YARN ResourceManager 日志搜索关键字 "Error" 或新变更参数,若存在则需要参考社区官网参数配置 场景2 RM多任务并发运行出现频繁切换 YARN ResourceManager的fullGC时间过长,RM与ZK 连接频繁超时导致RM频繁切换。 NM需要与RM响应任务状态,即定时心跳响应,当NM节点数量非常大且任务数量非常大会给Resourcemanager带来非常大的压力导致fullGC,fullGC过长引起RM与ZK的响应失败,从而出现频繁切换

    2.8K60编辑于 2022-09-07
  • YashanDB高可用

    当主库发生故障时,业务可以转移到库上继续执行,降低故障对业务的影响,提高数据库的可用性。YashanDB支持模式(一)和级联模式(不限层级)的高可用部署架构。 实例部署在不同的服务器上,两台服务器一般应连接到同一交换机,确保网络低时延,并应考虑交换机的冗余配置,保证高可用避免单点故障。 复制链路复制中,通过主库发送redo日志,库接收日志并回放,以实现库和主库的在线同步。 库复制链路:集群复制链路:切换YashanDB支持手动切换库和特定场景下无需外部干预的自动选。 ,包括自动选主和yasom仲裁选,降低运维复杂度。

    34600编辑于 2025-02-19
  • 来自专栏云生产力

    MySQL切换解析

    MySQL切换解析MySQL的切换是高可用性数据库架构中的重要一环。通过切换,可以在主库出现故障时迅速切换到库,从而保证系统的持续运行。 本文将详细解析MySQL切换的基本原理、实现方法以及相关的注意事项。一、MySQL基本原理在MySQL的架构中,通常有一个主库(Master)和一个或多个库(Slave)。 优点是节省空间,但可能因执行计划不同而导致不一致。Row格式:记录每一行数据的修改。优点是确保一致,但消耗空间较大。 三、切换实现方法实现MySQL自动切换,可以使用MySQL Replication和MySQL Cluster等工具。 五、注意事项延迟:延迟是指库执行完成事务的时间与主库执行完成事务的时间之间的差值。可以通过优化库的性能、减少大事务等方式来降低延迟。

    1.5K00编辑于 2024-12-04
  • 来自专栏微观技术

    京东一面:MySQL 延迟有哪些坑?切换策略

    此时会自动切换,进入 场景二 客户端读写,访问的是库(此时库升级为新主库) 看似天衣无缝,那是不是可以高枕无忧了呢???兄弟,想多了 切换,确实能满足高可用。 但有个前提,库的数据要同步。 不过,数据同步是个异步操作,不可能做到实时,所以说延迟是一定存在的 二、什么是延迟? 主库完成一个事务,写入binlog。 主要延迟花费在库执行binlog日志 三、延迟常见原因 1、库机器配置差 这个不难理解,“门当户对”、“志同道合”,如果机器的性能差别大,直接导致库的同步速度跟不上主库的生产节奏。 四、主库不可用,切换有哪些策略? 这个时间值取决于延迟的时间大小。 所以,我们应尽可能缩短库的延迟时间大小,这样一旦主库发生故障,库才会更快的同步完数据,切换才能完成,服务才能更快恢复。

    2.3K20编辑于 2022-04-07
  • 来自专栏凝神长老和他的朋友们

    MySQL备份与配置

    MySQL 配置 在主库上创建用户 repl,并给他权限。 延迟 最后需要说明的是,之间存在一个延迟。 主库 A 执行完成一个事务,写入 binlog,我们把这个时间记为 T1。 之后传给库 B,我们把库 B 接收完这个 binlog 的时刻记为 T2。 库 B 执行完成这个事务,我们把这个时刻记为 T3。 延迟即 T3 - T1 的差。 这是因为,延迟的来源有: 库的性能更差 库压力较大 大事务 必须执行完才会写入 binlog,然后传给库 在试验中并没有遇到这样的情况。 当然可以手动构造大量的数据来做个测试。 练习 2 尝试配置MySQL一及双结构。 上文已详述。

    2.4K20发布于 2020-04-17
  • 来自专栏蓝天

    简单的切换方案

        切换是很多高可用性系统都必须解决的问题,方法有很多,象基于ZooKeeper的切换就是一个很好的选择。 在这里提供一种更简单但不完美的切换方法: 1) 假设A和B是集群中的主控(Master)节点 2) 1~7是工作节点(如HDFS中的DataNode) 3) 在每个工作节点上,都同时配置了A和B的IP ,而且是对等的,无主之分 所谓:是指提供服务的主控,而是指不提供服务的主控,当故障时,由接管其它服务,但因网络原因,可能主和都未故障,这个是解决切换的关键问题所在。 选择A或B作为主的过程: 1) 未连接之前,如图1所示,A和B都不是 2) 1~7随机选择连接到A或B 3) 这个时候可能会出现如图2所示的情况 4) (关键点)在指定的时间内(如1秒),不管是A还是 B,发现到自己的连接数小于50%(这个值可修改)就主动切断连接,这个时候会将本来和自己建立连接的节点赶往另一边 5) 当A或B发现到自己的连接数超过60%(这个值可修改)时,就认为自己是了,并保持连接

    3.5K30发布于 2018-08-07
  • 来自专栏数据库架构之美

    PostgreSQL流复制搭建

    主从部署 Postgresql主从部署比较简单,首先你需要安装好主从两个实例,然后进行库配置,主要配置可以参考如下步骤: 主库配置: ①创建角色用于同步: create role replica login 主要分为以下几个流程: ①数据库启动,库启动walreceiver进程,wal进程向主库发送连接请求。 ④主库进行lsn对比,定期向库发送心跳信息来确认库可用性,并且将没有传递的wal日志进行发送,同时调用SyncRepWaitForLSN()函数来获取锁存器,并且等待库响应,锁存器的释放时机和同步模式的选择有关 synchronous_standby_names='ANY 2 (s1,s2,s3)' 代表s1,s2,s3三个机中任意两个机返回主库就可以提交,基于quorum协议。 wal_keep_segments: 设置“pg_xlog”目录下保留事务日志文件的最小数目用于流复制,如果机停机时间过长导致主库xlog被删除,那么关系会失败,但是如果开启了归档,机可以从归档日志中继续恢复

    3.5K10发布于 2019-12-18
领券