一.预期目的 主数据库(Primary pg ,假定主机名为A,后文不再赘述)和备用数据库(Standby pg,假定主机名为B,后文不再赘述)之间的数据能够相互备份. 主数据库发生故障时备用数据库可以接管工作,变为主数据库.旧的主数据库恢复后,能变为新的主数据库的备用数据库. 主数据库有写入.读取功能,备数据库只有读取功能. 二.使用的软件 Pgpool-II Postgresql 9.2 使用的特性: posgresql的streaming replication 功能 pgpool-II的

原文出处 http://mysql.taobao.org/monthly/2015/10/04/ PostgreSQL在9.0之后引入了主备流复制机制,通过流复制,备库不断的从主库同步相应的数据,并在备库apply每个WAL record,这里的流复制每次传输单位是WAL日志的record.而PostgreSQL9.0之前提供的方法是主库写完一个WAL日志文件后,才把WAL日志文件传送到备库,这样的方式导致主备延迟特别大.同时PostgreSQL9.0之后提供了Hot Standby,备库在应用

备库如何激活 在PostgreSQL(HOT-Standby)如主库出现异常.备库如何激活:来替换主库工作.有下列2种方式 备库在recovery.conf文件中有个配置项trigger_file.它是激活standby的触发文件.当它存在:就会激活standby. 使用pg_ctl promote来激活. 演示场景 模拟在主库异常挂掉.备库来替换主库工作一段时间.并原主库切换成新备库并恢复操作. 环境 主机名 IP地址 角色 数据目录 postgres202 192.168.1.202 pri

1.环境 OS: CentOS release 6.4 (Final) DB: postgresql 9.3.6 pgpool服务器: pgpool 172.16.0.240 数据库主服务器:master 172.16.0.241 数据库从服务器:slave 172.16.0.242 其中主从数据库使用的流复制,并且已经配置完毕,新配置的pgpool使用postgres用户进行管理.新架构使用的主备模式外加流复制,此架构支持流复制.负载均衡.故障恢复,不支持复制和并行查询,主库可以支持读写,从库

以下是工作上实现postgres主备切换功能所用到的代码和步骤,中间走了不少弯路,在此记录下.所用到的操作系统为centos 7.5,安装了两台服务器,hostname为VM7的为Master,VM8则为Slave. 1.安装pg10 vm7(Mater),vm8(Slave)均需安装: [root@springcloud-vm7 ~]# yum install –y https://download.postgresql.org/pub/repos/yum/reporpms/EL-7-x86_

二.主从搭建 2.1测试目标 测试postgresql主从搭建安装过程 2.2环境准备 实例级别的复制 流复制主库可读写,但从库只允许查询不允许写人, 而逻辑复制的从库可读写 流复制实验环境 主机 主机名 Ip地址 操作系统 Postgresql版本 主节点 pgsql 192.168.231.131 Redhat7.2 PostgreSQL10 备节点 pgstandby 192.168.231.132 Redhat7.2 PostgreSQL10 在 pgsql 和 pgstandby上创建

原文地址:http://mysql.taobao.org/monthly/2015/10/04/ PostgreSQL在9.0之后引入了主备流复制机制,通过流复制,备库不断的从主库同步相应的数据,并在备库apply每个WAL record,这里的流复制每次传输单位是WAL日志的record.而PostgreSQL9.0之前提供的方法是主库写完一个WAL日志文件后,才把WAL日志文件传送到备库,这样的方式导致主备延迟特别大.同时PostgreSQL9.0之后提供了Hot Standby,备库在应用

一.部署环境 主机列表: 主机名 Centos版本 ip docker version flannel version Keepalived version 主机配置 备注 master01 7.6.1810 172.27.34.3 18.09.9 v0.11.0 v1.3.5 4C4G control plane master02 7.6.1810 172.27.34.4 18.09.9 v0.11.0 v1.3.5 4C4G control plane master03 7.6.1810 1

​ 案例说明: 主库在业务高峰期间,客户执行建表等DDL操作,主库产生"AccessExclusiveLock "锁,导致大量的事务产生锁冲突,大量的会话堆积,客户端session访问主库失败.备库和主库之间的PQping的心跳通讯测试也受到阻塞,在指定阈值(10次)范围内,尝试连接失败后,触发主备切换. 一.案例故障信息 1)主库sys_log日志 =如下图所示,在主库上产生了"AccessExclusiveLock "锁,出现大量锁冲突= 2022-03-23

数据库性能优化普遍采用集群方式,oracle集群软硬件投入昂贵,今天花了一天时间搭建基于mysql的集群环境. 主要思路 简单说,实现mysql主备复制-->利用mycat实现负载均衡. 比较了常用的读写分离方式,推荐mycat,社区活跃,性能稳定. 测试环境 MYSQL版本:Server version: 5.5.53,到官网可以下载WINDWOS安装包. 注意:确保mysql版本为5.5以后,以前版本主备同步配置方式不同. linux实现思路类似,修改my.cnf即可. A主mysql.19

服务器基本环境: 两台centos6.4.iptables  diabled .selinux  disabled 两台的hosts解析 #yum install mysql -y  //这个一定要装,mysql和mysqldump命令全靠它 mysql安装(两台相同操作): mysql用户和组 #groupadd mysql #useradd -r -g mysql  mysql mysql的各种使用目录 数据目录挂载点:/data 数据库base目录:/usr/local/mysql 数据库

前提:redis中,主从切换场景中,没有绝对的主和从,只有初始化的主和从,然后当主down后,从就变成主了,而主即使连接上,也是从,不会变为主 1.redis-server的主备关系: 需要配置的机器,以及主备关系如下: master:10.118.36.10 slave1:10.118.36.74 slave2:10.118.36.161 2.修改redis-server的配置文件 切换到redis的根目录 # cd /home/admin/Downloads/redis- master配置不

部署准备: 两台CentOS 7主机HA1和HA2 CentOS 7 基于rpm包安装Nginx: 由于Base源中没有Nginx,所以要安装EPEL源,命令如下: wget http://dl.fedoraproject.org/pub/epel/epel-release-latest-7.noarch.rpm rpm -ivh epel-release-latest-7.noarch.rpm yum repolist ##检查是否已添加至源列表 然后就可以用yum安装相应的rpm包了 主备模

部署前准备: 1.至少4台主机:两个Director(HA1,HA2),两个Real Server(RS1,RS2) 2.Director之间时间必须同步,且关闭各主机的防火墙和Selinux 3.出于实验目的,各主机均使用一个网卡(桥接模式),且使用的是CentOS 7主机 部署流程: 1.分别在Director上执行: yum -y install ipvsadm keepalived 2.分别在Real Server上执行:并自行创建Web服务测试页 yum -y install http

实验环境:ubutu server 14 Master IP:172.16.34.212 Slave IP:172.16.34.34.156 Mycat server IP:172.16.34.219 不涉及过多理论,只有实现的过程.mysql读写分离和主备热切换,容灾,数据分片的实现手段目前比较流行的是Mycat.当然利用应用层代码去解决这些问题也是可以的. 1,首先到Github下载Mycat 1.6 版本的安装包,下载地址为:https://github.com/MyCATApache/M

LVS+MYCAT+读写分离+MYSQL主备同步部署手册 1          配置MYSQL主备同步…. 2 1.1       测试环境… 2 1.2       配置主数据库… 2 1.2.1         编辑my.cnf文件… 2 1.2.2         重启数据库… 2 1.3       锁定主数据库DDL操作… 2 1.4       主备已有数据同步… 2 1.5       停止从服务… 3 1.6       配置备用数据库… 3 1.6.1         编辑my

本文来自:http://www.woqutech.com/?p=1116 MySQL 本身通过 show slave status 提供了 Seconds_Behind_Master ,用于衡量主备之间的复制延迟,但是 今天碰到了一个场景,发现 Seconds_Behind_Master 为 0 , 备库的 show slave status 显示IO/SQL 线程都是正常的 , MySQL 的主库上的变更却长时间无法同步到备库上.如果没有人为干预,直到一个小时以后, MySQL 才会自动重连主

keepalived工作原理和配置说明 腾讯云VPC内通过keepalived搭建高可用主备集群 内网路由都用mac地址 一个mac地址绑定多个ip一个网卡只能一个mac地址,而且mac地址无法改,但是一个网卡可以绑定多个ip地址 keepalived是集群管理中保证集群高可用的一个服务软件,其功能类似于heartbeat,用来防止单点故障. keepalived工作原理 keepalived是以VRRP协议为实现基础的,VRRP全称Virtual Router Redundancy Proto

复制对于mysql的重要性不言而喻,mysql集群的负载均衡,读写分离和高可用都是基于复制实现.下文主要从4个方面展开,mysql的异步复制,半同步复制和并行复制,最后会简单聊下第三方复制工具.由于生产环境中,innodb存储引擎支持事务,并且行级复制使用广泛,所以下文的讨论都是基于这种假设. 1. 异步复制 异步复制是mysql自带的最原始的复制方式,主库和备库成功建立起复制关系后,在备库上会有一个IO线程去主库拉取binlog,并将binlog写到本地,就是图1中的Relay log,然后备

lvs主备可以自由切换,vip落在主上的时候,端口无法telnet,业务连接不了 解决:将主上的keepalived重启,故障解除 原因:不可知 lvs常见故障原因: real server上的脚步没有执行或者此脚步上的vip与服务器配置的不同