第二次执行时不再提示输入yes，并且可以成功执行命令，则表示SSH对等性配置成功。
大家肯能注意到,最近一直都是各种数据库的灾难恢复的复盘, 本身作为一个TEAM 的LEADER 我想到的是在紧急情况下,我们应该有一个应对的措施,对每一个 TEAM 的 DBA 都应该在那个时候沉着冷静,并且知道那些是应该做的, 那些是不该做的.
接上期，（如果看不懂的，请从第一期看，否则可能和看天书没两样），最近在梳理一些问题的时候，发现一个现象，大部分出现问题后，解决就完了，网上很多文字，大多都是这样，先提出一个问题，然后就给出答案，然后就么有然后后了。而这样的结果一般是好不了的，这和狗熊掰棒子没啥区别。所以才有了这期，这期是要说说repmgr 的一些系统表，一些常见的被问及的问题，（一些深层的问题，还得继续研究）
应该是第三个关于PostgreSQL 高可用的文字了，Repmgr 在使用中的一些通用的命令和一些配置文件的含义，今天需要明确。
本文比较基础，主要介绍postgresql开源高可用工具repmgr的部署和使用，初学者可以根据本文步骤一步一步做下去，废话不多说，直接进入主题，本文以两台机器为例。
REPMGR 是一种方便简单的适合企业使用的高可用方式，为什么选择REPMGR作为单体PG的高可用方式
PostgreSQL 使用repmgr 进行主从数据的Clone是可以进行级联复制的，使用过MYSQL的同学可能会觉得，没有什么了不起，MYSQL 多少级的级联复制都可以。但PostgreSQL 的级联数据复制有些不同 1 PostgreSQL 中的复制是stream replication 而不是类似MYSQL 的逻辑复制。2 这里的复制不是指的和 mysql 一样的 从库套从库的复制，而是从PG的从库进行数据的CLONE 制作新的从节点，然后在将从节点连接到主库，这点也和MYSQL不一样。
最近要整理公司使用的POSTGRESQL 的高可用方式,既然是整理和梳理,不如就仔仔细细的来一边.
前面的文章介绍了postgresql基于repmgr的高可用及切换方案，这篇文章主要聊聊通过repmgrd实现failover及auto failover。
PostgreSQL 的高可用的方案，基本上不是原生的，大多是依靠第三方的公司来进行开发的，挂名的有那么几种 Patroni, PGPOOL-II, Repmgr , 等等几种。PGPOOL-II 在安装适用中遇到很多问题，按理说一家日本公司做的东西应该靠谱，可惜问题太多，所以不能被作为 HA 的方式使用。
最近问postgresql 那个高可用靠谱的人越来越多，其实我也试过几种postgresql 的高可用方案，而最近听到的声音是 PostgreSQL 没有靠谱的高可用方案。所以就有了这篇文字
本篇是POSTGRESQL 高可用的最后一篇文字，如果敢兴趣可以往前翻看之前的三篇文字，在安装完repmgr 后，创建对应repmgr的数据库后会有相关的表灌入到repmgr 数据库中。
此 PostgreSQL 集群解决方案包括 PostgreSQL 复制管理器(replication manager)，这是一种用于管理 PostgreSQL 集群上的复制(replication)和故障转移(failover)的开源工具。
repmgr -f /etc/repmgr.conf standby switchover -U repmgr --verbose
PostgreSQL 是一种流行的开源关系型数据库管理系统。它提供了标准的SQL语言接口用于操作数据库。
上期说到了见证服务器，见证服务器的功能到底有什么用，其实如同各种高可用中（这里说的是完备的高可用）大部分都是三台，因为怕什么，怕脑裂，因为高可用要面对的问题是很多的，尤其网络的问题，如果因为网络的原因造成服务器本身没有问题，但在网络断开的某个时间段造成了，主从切换，则就会造成双主的尴尬现象。所以在数据中心或比较关键的业务中，使用的数据库服务器的高可用也是要妥妥当当的。wintness不是一个成熟的备用节点，也没有集成到复制中，但是在决定哪个网络段占多数时，它有效地代表了“投票”。可以使用repmgr见证寄存器设置见证服务器。但前提是你必须使用repmgrd ，每个节点都需要运行这个程序（如果你不知道什么是repmgrd 请参看之前的文字 1 2 3 ）
1 failover='automatic' #如果侦测到失败，则进行自动切换，默认为手动
在众多postgresql 高可用模式中，主要的参与者有两位， Patroni VS repmgr 基于这二者的功能优点以及缺点相信大部分人都不是太明确，下面将根据两篇翻译的文字合并，来对两个高可用的程序来做一个比较， cons and pros。
接上期，上期大致比对了一下基本的指标，本期就的详细的比对一下两个高可用软件的信息的功能了。
（如果不知道在说什么的，请参见之前的 6期文字 谁说postgresql 没有靠谱的高可用 1-6）
PostgreSQL 的 Patroni 是一个系列, 目前已经写到了 4 , 实际我也不知道应该写到多少结束.
postgresql 的复制功能是比较全面的，物理流，逻辑复制，复制槽，全INSTANCE ，单表。但最近群里面的经常会问一个问题，到底高可用的方式PG 用哪个，哪个好用，你们用哪个诸如此类的问题。
问题的起因是，在做repmgr 恢复的时候，经常有同学说恢复的时候， repmgr rejion node 的时候pg_rewind 会报错，与时间线有关。（pg_rewind之前是写过的清参阅之前的文字）
PostgreSQL 作为这两年很火的开源数据库，众多功能大多数以轻量级插件形式提供，好多高可用技术也是通过插件的形式提供。作为开源关系型数据库广受众多开发者的喜爱，前景一片大好，我也网上扒了好几周，查了很多资料，据说 repmgr 和 Patroni 两种高可用方案使用最多，那么今天我们来一起聊聊 PostgreSQL 高可用都有哪些方案。
大家好，我是小碗汤，今天分享一篇搭建一个高可用镜像仓库的教程。详细中夹杂着简单~。篇幅较长，兄弟们不妨耐心看完~
优化一个分布式系统的吞吐能力，除了应用本身代码外，很大程度上是在优化它所依赖的中间件集群处理能力。如：kafka/redis/rabbitmq/postgresql/分布式存储(CephFS,JuiceFS,C urve,Longhorn)等集群的处理能力。
假如动物们也用GPS，突然有那么一天北极的公北极熊有点冲动，想刷一下附近有没有母熊。要求距离越近越好，不是澳大利亚动物园那只，也不是格陵兰岛上被囚禁的那群呆企鹅，要是有点共同的嗜好就再好不过了。这种应用场景如何解决？
作为一个系列,下面在介绍完什么要使用 patroni 以及为什么选择 etcd后, 今天就开始需要安装patroni , 由于patroni 是一个基于python 的程序,这就与patroni的版本和python有关.
事情的起因是，一家比较大的公司，要使用kong网关，就职的朋友问我postgresql 最简单的高可用方式有什么， 所以才有了此文PostgreSQL 的复制默认是异步的方式，如果primary server crash了一些已经commited的事务在primary server 但还没有传送到 standby server 则主从就会不一致，数据就丢失了，所以这是异步复制的模式。
👆点击“博文视点Broadview”，获取更多书讯 PostgreSQL 是一款非常优秀的开源数据库产品，堪比商业版Oracle。 近年来，在国内刮起去IOE的热潮中，PostgreSQL已成为企业替代Oracle的首选。 高度兼容ORACLE语法和特性，完美支持事务、子查询、多版本控制（MVCC）、数据完整性检查等特性，使其在去O、科学计算、位图数据等方面都有非常瞩目的成绩。 在高可用架构已经成为企业标配的当今，无论应用服务还是数据库硬件成本，成为高可用限制的影响已逐渐降低。 部分互联网要求业务7×2
6）通过pg_waldump --path=/tmp/sd/pg_wal -start=0/1C420B8看下日志文件里内容。使用的是步骤3中的起始LSN。注意WAL中包含创建物理文件的指令：
之前一直在用POSTGRESQL 11 , 对recovery,conf 的印象比较深,到了PG12 这个文件已经移动到了POSTGRESQL.CONF 文件中了. 是那么的简单吗? NO NO
关闭数据库,呵呵,看上去没有什么可以说的,或者说没有什么技术含量,属于只要脖子上有一双带眼睛的脑袋就可以进行操作. 事实是这样的吗? 关闭数据库看似简单的事情也能给评出个 3 6 9 等的LEVE
PostgreSQL 本身的复制方式和方法是有一个渐进的历史，这段历史也是证明POSTGRESQL 为何能走到今天越来越热的原因。
在一个生产系统中，通常都需要用高可用方案来保证系统的不间断运行。PostgreSQL 本身不支持任何多主群集解决方案，例如MySQL或Oracle。尽管如此，仍有许多商业和社区产品提供此实现，以及其他产品，例如PostgreSQL的复制或负载平衡。
数据库的连接池，众所周知没有不需要的，所以对于数据库的连接池给出答案，一定是需要的。
那等了这么多年的功能，到底怎么样，到底我们是不是已经可以升级到MYSQL 8 ，目前看还是的等等，主要是最近MYSQL 8 的更新速度太快，很多新功能还在发布中，如果莽然升级会遗漏更多的好功能，例如HASH JOIN。
最近一直在做公司整体数据库的灾难恢复的演练的组织工作，手下的几个DBA也是忙的不亦乐乎（真的乐的起来起不来我就不知道了）。
如同没有十全十美的人，一个产品哪里有十全十美的，不怕有缺点，就怕没认知。那么如果从“处女座” 挑剔的角度来看POSTGRESQL 那么到底怎么能从“鸡蛋里面”挑挑骨头，让PG 下不来台。
Pgpool 是一个高性能的连接池和负载均衡器，用于 PostgreSQL 数据库。Pgpool 可以作为中间层，位于客户端和 PostgreSQL 服务器之间，来管理连接请求并分配给不同的 PostgreSQL 服务器进行处理，以提高整体的系统性能和可用性。Pgpool 的一些主要功能包括：
酷 壳 – CoolShell http://coolshell.cn/articles/17680.html
昨天，Gitlab.com发生了一个大事，某同学误删了数据库，这个事看似是个低级错误，不过，因为Gitlab把整个过程的细节都全部暴露出来了，所以，可以看到很多东西，而对于类似这样的事情，我自己以前也干过，而在最近的两公司中我也见过（Amazon中见过一次，阿里中见过至少四次），正好通过这个事来说说一下自己的一些感想和观点吧。我先放个观点：你觉得有备份系统就不会丢数据了吗？ 事件回顾 整个事件的回顾Gitlab.com在第一时间就放到了Google Doc上，事后，又发了一篇Blog来说明这个事，在这里，
几年来，作为全球AI最著名的研究机构之一的DeepMind与东家谷歌之间的关系一直难说融洽。
2014年1月，Google宣布6亿美元收购这家当时名不见经传的公司。为此，Jeff Dean和Geoffrey Hinton还曾坐/躺在Google创始人拉里·佩奇的私人飞机里，专程赶赴伦敦对DeepMind进行了审查。
雷锋网 AI 科技评论按：今早，DeepMind 发出一篇年度总结文，盘点了 2017 年中自己在新的 AI 技术研发方面的研究成果，以及在 AI 技术的社会影响方面的所作所为。 可以说，AlphaGo 是大众眼中的 DeepMind 的重头戏，他们自撰的总结文也是以 AlphaGo 开头、以 AlphaGo Zero 结尾。不过 DeepMind 的技术成果和在社会责任方面的努力真的有很多，关注我们的读者在这一年中也看到了不少 DeepMind 的各方面研究成果，实验室地点也扩张到了加拿大蒙特利尔和美国加
机器之心报道 编辑：泽南、小舟 谷歌收购 DeepMind 花费了 6 亿美元。2020 年，DeepMind 交出了一份高达 6.49 亿美元（约 42 亿人民币）的年度亏损账单。人们担心 DeepMind 入不敷出会逐渐丧失领先技术研究的主导权，DeepMind 却无时无刻不在想重获自由。 有段时间，DeepMind 员工们将其称为「Watermelon 计划」；后来，高管们又称之为「Mario 计划」，不论如何它们都指代同一件事：让 DeepMind 重新从谷歌拆分出来的秘密计划。 DeepMind
领取专属 10元无门槛券
手把手带您无忧上云
云服务器
ICP备案
对象存储
腾讯会议
实时音视频
