postgresql从库提升为主库

一、停主库

1、查看当前连接

select pid,datname,usename,client_addr,client_port, application_name from pg_stat_activity;

2、杀死当前账户连接

select pg_terminate_backend(pid) from pg_stat_activity where usename=‘postgres‘ ;

3、停止主库服务

pg_ctl stop -m fast -D /usr/local/postgresql/data

4、从库激活为主库

pg_ctl promote -D /usr/local/postgresql/data

5、检查从库是否提升为主库成功

pg_controldata  -D /usr/local/postgresql/data | grep cluster

Database cluster state:   in production   -- 说明: 如果值为 "in production" 说明是主库,如果值为 "in archive recovery" 说明是从库

参考:https://blog.51cto.com/lee90/2097494

原文地址:https://www.cnblogs.com/caidingyu/p/11801620.html

时间: 2024-08-02 08:09:11

postgresql从库提升为主库的相关文章

mysql5.7 迁移以及从库提升为主库

CHANGE MASTER TO MASTER_HOST='10.10.30.34',  MASTER_PORT=3306, MASTER_USER='slave', MASTER_PASSWORD='slave', MASTER_LOG_FILE='mysql-bin.000148', MASTER_LOG_POS=154; 从数据库变为主库 stop slave; reset slave; reset master; 从库变为刚才的主库(由从库变为主库的数据库) vim /etc/my.cn

主库down机,从库切换为主库的步骤

以1主2从架构为例,介绍主库down机后,将某一从库提升为库的步骤: 主库/从库 IP地址 端口 同步帐号 主 172.18.130.231 3306 从1 172.18.130.236 3306 rep/123456 从2 172.18.130.237 3306 rep/123456 一般主库突然down机,以主从库binlog的同步情况分为2种 两从与主库完全同步 两从与主库不同步,数据不一致. a.      主库down机(主库连不上,系统无法启动)后,直接选一台从库切换为主库: b. 

mysql主从复制、半同步复制、主主复制、及从库升级为主库讲解

一.主从复制结构 binlog dump --- io thread  ---  relay log ---- sql thread 1.总体讲解 主从复制时是异步的 半同步是在主从架构下安装插件来达到半同步的 半同步的优点:保证至少一个节点的数据和主节点的数据一致,缺点影响性能 导致主从不同步的原因是 现在的服务器都是单核多线程或者多核多线程,导致主节点可以同时执行多条读写操作,而记录二进制日志则必须按顺序有先后的记录,从节点在一条一条复制过去,生成中继日志,再执行语句. 多个库复制的话,可以

当主库发生宕机,从库如何接管主库

当主库发生宕机,从库如何接管主库 1.主库崩溃,日志不在情况(会丢数据) 查看从库已经同步到哪了,①确定数据丢失的时间范围,②确定从库的中继日志是否被SQL_thread进程解析完(即传输过来的中断日志是否在从库上重放完). 1.1.如何确定数据丢失的时间范围 登录从库服务器,进入mysql数据库,执行以下命令,查看相关的参数: mysql> show slave status\G Master_Log_File            表示IO thread读取到的binlog日志文件名 Rea

oracle dg 备库不同步主库数据

今天遇到一个数据库同步问题,主库被关闭,重启主库后,备库不能正常同步主库数据.只有当手动切换归档日志的时候,备库才能和主库一致. 这个问题的解决方法: 重启备库,重新应用归档日志. 操作步骤如下: //关闭备库监听器 lsnrctl stop //关闭备库 sqlplus / as sysdba alter database recover managed standby database cancel; shutdown immediate; //启动备库 startup nomount; a

postgresql从库搭建--逻辑复制

1 物理复制及逻辑复制对比 前文做了PostgreSQL物理复制的部署,其有如下主要优点 物理层面完全一致,是主要的复制方式,其类似于Oracle的DG 延迟低,事务执行过程中产生REDO record,实时的在备库apply,事务结束时,备库立马能见到数据 物理复制的一致性.可靠性高,不必担心数据逻辑层面不一致 但是其又在实际使用的场景中存在一些无法满足的需求,例如: 无法满足指定库或部分表的复制需求 将多个数据库实例的数据汇聚到同一个目标库或将一个库的数据分发到多个不同的库 不同的版本之间的

pgsql物理复制(pgsql 备库的搭建以及角色互换,提升)

结构图如下: Postgresql早在9.0版本开始支持物理复制,也称为流复制,通过从实例级复制出一个与主库一模一样的备库.流复制同步方式有同步,异步两种,如果主节点和备节点不是很忙,通常异步模式下备库和主库的延迟时间能够控制在毫秒级.物理复制只能复制整个实例. 逻辑复制也成为选择性复制,可以做到基于表级别的复制,选择需要逻辑复制的表,而不是复制实例上的所有数据库的表,10版本不支持内置的逻辑复制,通常使用第三方逻辑复制. WAL日志记录数据库变化,格式为二级制格式,尽管流复制都是基于WAL,但

mysql主从同步(3)-percona-toolkit工具(数据一致性监测、延迟监控)使用梳理

转自:http://www.cnblogs.com/kevingrace/p/6261091.html 在mysql工作中接触最多的就是mysql replication mysql在复制方面还是会有一些常规问题: 比如主库宕机或者从库宕机有可能会导致复制中断,通常需要进行人为修复, 或者很多时候需要把一个从库提升为主库,但对从库和主库的数据一致性不能保证一样. 这种情况下就需要使用percona-toolkit工具的pt-table-checksum组件来检查主从数据的一致性:如果发现不一致的

数据一致性-分区可用性-性能——多副本强同步数据库系统实现之我见(转:何登成)

原文地址:http://hedengcheng.com/?p=892 1    背景    1 2    问题一:数据一致性    3 3    问题二:分区可用性    6 4    问题三:性能    8 5    总结    10 6    问题四:一个极端场景的分析    10 背景 最近,@阿里正祥(阳老师)发了上面的一条微博,谁知一石激起千层浪,国内各路数据库领域的朋友在此条微博上发散出无数新的话题,争吵有之,激辩有之,抨击有之,不一而足. 总体来说,大家重点关注其中的一点: 在不使