Pigsty English Documentation [DRAFT]
Pigsty是 PostgreSQL In Graphic STYle 的缩写，即 “图形化Postgres”。
pigsty 一词的的本意是猪圈，读作 Pig Style (/ˈpɪɡˌstaɪ/) 。
针对大规模数据库集群监控与管理而设计，提供业界顶尖的PostgreSQL监控系统与开箱即用的高可用数据库供给方案。
Pigsty基于开源生态构建，旨在降低PostgreSQL使用管理的门槛，为用户带来极致的可观测性与丝滑的数据库使用体验。
Pigsty经过长期迭代演进，久经实际生产环境考验。
Pigsty基于Apache 2.0协议开源，可免费用于测试生产，并提供可选的 专业支持 。
You can’t manage what you don’t measure.
监控系统提供了对系统状态的度量，是运维管理工作的基石。
PostgreSQL是世界上最好的开源关系型数据库，但其生态中却缺少一个足够好的监控系统。
Pigsty旨在解决这一问题：交付最好的PostgreSQL监控系统。
与同类产品相比，Pigsty在指标覆盖率与监控面板丰富程度上一骑绝尘，无出其右，详见 同类对比。
授人以鱼，不如授人以渔。
Pigsty还是高可用数据库集群 供给方案。
供给方案不是数据库，而是数据库工厂。用户向工厂提交订单，供给系统会自动根据表单的内容，创建出对应的数据库集群。
Pigsty通过声明式的配置定义数据库集群，通过幂等的预置剧本自动创建所需的数据库集群，提供近似私有云般的使用体验。
Pigsty创建的数据库集群是分布式、高可用的数据库集群。只要集群中有任意实例存活，集群就可以对外提供完整的读写服务与只读服务。数据库集群中的每个数据库实例在使用上都是幂等的，任意实例都可以通过内建负载均衡组件提供完整的读写服务，提供分布式数据库的使用体验。数据库集群可以自动进行故障检测与主从切换，普通故障能在几秒到几十秒内自愈，且期间只读流量不受影响。
Pigsty的监控系统可以脱离Pigsty供给方案独立部署，详见 仅监控部署。
Pigsty基于Apache 2.0协议开源，可以免费使用，也提供可选的商业支持。
Pigsty的监控系统与供给方案大多基于开源组件，而PostgreSQL本身也是世界上最先进的开源关系型数据库。基于开源生态，回馈开源社区。Pigsty可以极大地降低PostgreSQL的使用与管理门槛，让更多人享受到PostgreSQL的便利，体验数据库的乐趣。
开发Pigsty的初衷是：作者需要对一个大规模PostgreSQL集群进行管理，但找遍所有市面上的开源与商业监控系统方案后，发现没有一个是“足够好用”的。本着“我行我上”的精神，开发设计了Pigsty监控系统。而监控系统要想发行与演示，必须要先有被监控的对象，所以顺便开发了Pigsty供给方案。
Pigsty将主从复制，故障切换，流量代理，连接池，服务发现，基本权限系统等生产级成熟部署方案打包至本项目中，并提供了沙箱环境用于演示与测试。沙箱配置文件只微量修改即可应用于生产环境部署，用户在自己的笔记本电脑上就可以充分探索与体验Pigsty提供的功能，真正做到开箱即用。
Pigsty不是 管控平台。通常意义上的 管控平台， 提供了对数据库生命周期的完整运维支持，并通常带有美观便捷的图形化用户界面。
Pigsty供给方案在原则上只负责数据库集群的 创建，不提供管理UI，只提供命令行接口。Pigsty在实际上实现数据库集群的创建与销毁，扩缩容，监控、备份等功能，已经足以覆盖大多数使用场景，但这些功能在逻辑上仍然属于 管控平台 的一个子集。
在长期的 路线图 中，Pigsty将逐一实现完整的 管控 功能，并逐步改造为基于Kubernetes的云原生解决方案。成为监控、供给、管理 三位一体的PostgreSQL私有云解决方案。
本文介绍如何在笔记本或PC机上基于Vagrant与Virtualbox一键拉起Pigsty演示沙箱。Pigsty沙箱是本地的演示与测试环境，运行于由vagrant托管的本地virtualbox虚拟机上。如果希望在已有的虚拟机上进行Pigsty部署，请参考 部署 一章。
如果本地计算机上已经安装有vagrant ， virtualbox与ansible，那么只需要克隆并进入本项目后，依次执行以下命令即可：
cd /tmp && git clone https://github.com/Vonng/pigsty && cd pigsty
# 事前准备【一次性，下一次初始化不再需要】
make up # 拉起vagrant虚拟机
make ssh # 配置虚拟机ssh访问
sudo make dns # 写入Pigsty静态DNS域名（需要sudo,可选）
# 使用离线安装模式【可选，可以加速首次安装】
make fetch # 下载最新的离线软件包
make upload # 将离线软件包上传至元节点
# 执行初始化
make init # 初始化Pigsty
make mon-view # 打开Pigsty首页（默认用户密码：admin:admin）
正常执行结果详见 参考-标准流程。如果用户已经完成过本地Pigsty沙箱的初始化，想要重建新的环境，执行快捷命令make new 即可。
标准的Pigsty演示环境包含4个虚拟机节点，其中元节点一个，普通节点三个，最低配置的Pigsty演示环境仅包含单个元节点。
Pigsty沙箱默认使用基于Vagrant的本地虚拟机，宿主机最低配置为1核1GB，推荐配置为5CPU/10GB或更好。
如果资源不足或充裕，用户可以通过定制Vagrantfile调整创建的虚拟机规格与数量，详情参考 Vagrant虚拟机供给 。
只使用单个元节点的配置，包括一个单主数据库集群pg-meta与完整的监控系统。元节点最低配置为1核/1GB。
使用四个节点组成的完整演示环境，其中包含一个元节点与三个普通数据库节点。元节点配置为2核/4GB，数据库节点为配置1核/2GB x3。环境中包含了一个单主数据库pg-meta（位于元节点上），以及一个额外的名为pg-test的一主两从测试集群。
标准配置下的Pigsty可充分展示集群监控、管理、流量切换等功能。
在本机运行Pigsty沙箱前，用户需要在宿主机安装 vagrant 与 virtualbox。如果希望在宿主机发起管理与控制，还需要安装ansible。
软件的安装因平台而异，用户可以直接从官方网站下载vagrant和virtualbox的安装器，并按向导提示完成安装。
ansible可以通过包管理器安装：
brew install ansible # macos
yum install ansible # linux
检查安装的软件版本：
$ echo $(vagrant --version)
Vagrant 2.2.13
$ echo $(vbox-img --version)
6.1.16r140961
$ echo $(ansible --version)
ansible 2.10.3
建议使用2.9以上版本的Ansible，更低版本的Ansible可能遭遇兼容性问题。
首先，克隆并进入项目目录，后续操作均位于项目根目录中（以/tmp/pigsty为例）
cd /tmp && git clone https://github.com/Vonng/pigsty && cd pigsty
执行make up将调用vagrant up命令，根据Vagrantfile中的定义，使用Virtualbox创建四台虚拟机。
$ make up
cd vagrant && vagrant up
Bringing machine 'meta' up with 'virtualbox' provider...
Bringing machine 'node-1' up with 'virtualbox' provider...
Bringing machine 'node-2' up with 'virtualbox' provider...
Bringing machine 'node-3' up with 'virtualbox' provider...
==> meta: Cloning VM...
==> meta: Matching MAC address for NAT networking...
==> meta: Setting the name of the VM: vagrant_meta_1609817410777_92884
==> meta: Clearing any previously set network interfaces...
==> meta: Preparing network interfaces based on configuration...
meta: Adapter 1: nat
meta: Adapter 2: hostonly
==> meta: Forwarding ports...
meta: 22 (guest) => 2222 (host) (adapter 1)
==> meta: Running 'pre-boot' VM customizations...
==> meta: Booting VM...
==> meta: Waiting for machine to boot. This may take a few minutes...
meta: SSH address: 127.0.0.1:2222
......
==> node-3: Running provisioner: shell...
node-3: Running: /var/folders/_5/_0mbf4292pl9y4xgy0kn2r1h0000gn/T/vagrant-shell20210105-17045-1rj8hxd.sh
node-3: [INFO] write ssh config to /home/vagrant/.ssh
新拉起的虚拟机默认用户为vagrant，需要配置本机到虚拟机的免密ssh访问。
执行make ssh命令将调用vagrant的ssh-config命令，系统会将pigsty虚拟机节点的ssh配置文件写入~/.ssh/pigsty_config。
该命令仅需在首次拉起Pigsty时执行。
$ make ssh
cd vagrant && vagrant ssh-config > ~/.ssh/pigsty_config 2>/dev/null; true
if ! grep --quiet "pigsty_config" ~/.ssh/config ; then (echo 'Include ~/.ssh/pigsty_config' && cat ~/.ssh/config) > ~/.ssh/config.tmp; mv ~/.ssh/config.tmp ~/.ssh/config && chmod 0600 ~/.ssh/config; fi
if ! grep --quiet "StrictHostKeyChecking=no" ~/.ssh/config ; then (echo 'StrictHostKeyChecking=no' && cat ~/.ssh/config) > ~/.ssh/config.tmp; mv ~/.ssh/config.tmp ~/.ssh/config && chmod 0600 ~/.ssh/config; fi
Pigsty包含若干Web页面子系统，需要通过域名区分访问。您可以通过修改/etc/hosts中的静态解析记录做到这一点。make dns会将Pigsty涉及的静态DNS记录写入宿主机的/etc/hosts文件，以便您通过浏览器访问监控系统。
注意修改DNS需要sudo权限，您可能需要输入密码，该命令仅需在首次拉起Pigsty时执行。
$ sudo make dns
Password:
if ! grep --quiet "pigsty dns records" /etc/hosts ; then cat files/dns >> /etc/hosts; fi
默认会写入以下DNS域名记录：
# pigsty dns records
10.10.10.2 pg-meta # sandbox vip for pg-meta
10.10.10.3 pg-test # sandbox vip for pg-test
10.10.10.10 meta-1 # sandbox node meta-1 (node-0)
10.10.10.11 node-1 # sandbox node node-1
10.10.10.12 node-2 # sandbox node node-2
10.10.10.13 node-3 # sandbox node node-3
10.10.10.10 pigsty y.pigsty yum.pigsty
10.10.10.10 c.pigsty consul.pigsty
10.10.10.10 g.pigsty grafana.pigsty
10.10.10.10 p.pigsty prometheus.pigsty
10.10.10.10 a.pigsty alertmanager.pigsty
10.10.10.10 n.pigsty ntp.pigsty
10.10.10.10 h.pigsty haproxy.pigsty
Pigsty是一个复杂的软件系统，为了确保系统的稳定，Pigsty会在初始化过程中从互联网下载所有依赖的软件包并建立本地Yum源。
所有依赖的软件总大小约1GB左右，下载速度取决于您的网络情况。尽管Pigsty已经尽量使用镜像源以加速下载，但少量包的下载仍可能受到防火墙的阻挠，可能出现非常慢的情况。您可以通过proxy_env配置项设置下载代理以完成首次下载，或直接下载预先打包好的离线安装包。例如最新的离线安装包地址为：
https://github.com/Vonng/pigsty/releases/download/v0.5.0/pkg.tgz
将该软件包拷贝至项目根目录的files/pkg.tgz，然后执行make upload，即可将离线软件包上传至元节点的目标位置。
make upload
为了快速拉起Pigsty，建议使用离线下载软件包并上传的方式完成安装。
默认的离线软件包基于CentOS 7.8，用于生产环境时，我们强烈建议您依据生产环境的实际情况完成一次完整的网络下载，并通过make cache缓存离线安装包。
完成上述操作后，执行make init即会调用ansible完成Pigsty系统的初始化。
$ make init
./sandbox.yml # 快速初始化，并行初始化元节点与普通数据库节点
如果您已经将离线安装包上传至元节点，那么初始化环境会比较快，视机器配置可能总共需要5～10分钟不等。
如果离线安装包不存在，那么Pigsty会在初始化过程中从互联网下载约1GB数据，视网络条件可能需要20分钟或更久。
强烈建议您在第一次完成初始化后执行 make cache 命令，该命令会将下载好的软件打为离线缓存包，并放置于files/pkg.tgz中。这样当下一次创建新的pigsty环境时，只要宿主机内操作系统一致，就可以直接复用该离线包，省去大量下载时间。
sandbox.yml是专门为本地沙箱环境准备的初始化剧本，通过同时初始化元节点和数据库节点节省了一半时间。
生产环境建议使用meta.yml与pgsql.yml分别依次完成元节点与普通节点的初始化。
初始化完毕后，您可以通过浏览器访问 http://pigsty 前往监控系统主页。默认的用户名与密码均为admin
如果没有配置DNS，或者没有使用默认的IP地址，也可以直接访问 http://meta_ip_address:3000前往监控系统首页。
同时，用户也可以通过以下域名访问其他附属系统：
Pigsty在逻辑上由两部分组成：监控系统 与 供给方案 。
监控系统负责监控PostgreSQL数据库集群，供给方案负责创建PostgreSQL数据库集群。
Pigsty的监控系统与供给方案可以独立使用，用户可以在不使用Pigsty供给方案的情况下，使用Pigsty监控系统监控现有PostgreSQL集群与实例，详见 仅监控部署（monly）。但这里都将以标准Pigsty部署作为介绍对象。
了解Pigsty的 监控系统 与 供给方案 前，建议先了解 Pigsty 所使用的 命名原则。
You can’t manage what you don’t measure.
监控系统提供了对系统状态的度量，是运维管理工作的基石。Pigsty提供最好的开源PostgreSQL监控系统。
Pigsty的监控系统在物理上分为两个部分：
Pigsty监控系统的核心概念如下：
授人以鱼，不如授人以渔
供给方案（Provisioning Solution） ，指的是向用户交付数据库服务与监控系统的系统。供给方案不是数据库，而是数据库工厂，用户向供给系统提交一份配置，供给系统便会按照用户所需的规格在环境中创建出所需的数据库集群来，这类似于通过向Kubernetes提交YAML文件来创建系统所需的各类资源。
Pigsty的供给方案在部署上分为两个部分：
Pigsty的供给方案的部署对象分为两种：
Pigsty供给方案的相关概念如下：
名之必可言也，言之必可行也。
概念及其命名是非常重要的东西，命名风格体现了工程师对系统架构的认知。定义不清的概念将导致沟通困惑，随意设定的名称将产生意想不到的额外负担。因此需要审慎地设计。本文介绍 Pigsty 中的相关实体，以及其命名所遵循的原则。
Pigsty中，核心的四类实体为：集群（Cluster），服务（Service），实例（Instance），节点（Node）
[a-zA-Z0-9-]+）。-，再接一个整数序号（建议从0开始分配，与k8s保持一致）${cluster}-${seq}的方式。-连接服务具体内容，如primary, replica,offline,delayed等。
以上图为例，用于测试的数据库集群名为“pg-test”，该集群由一主两从三个数据库服务器实例组成，部署在集群所属的三个节点上。pg-test集群集群对外提供两种服务，读写服务pg-test-primary与只读副本服务pg-test-replica。
在Postgres集群管理中，有如下实体概念：
集群是基本的自治业务单元，这意味着集群能够作为一个整体组织对外提供服务。类似于k8s中Deployment的概念。注意这里的集群是软件层面的概念，不要与PG Cluster（数据库集簇，即包含多个PG Database的单个PG实例的数据目录）或Node Cluster（机器集群）混淆。
集群是管理的基本单位之一，是用于统合各类资源的组织单位。例如一个PG集群可能包括：
每个集群都有用户根据业务需求定义的唯一标识符，本例中定义了一个名为pg-test的数据库集群。
节点是对硬件资源的一种抽象，通常指代一台工作机器，无论是物理机（bare metal）还是虚拟机（vm），或者是k8s中的Pod。这里注意k8s中Node是硬件资源的抽象，但在实际管理使用上，是k8s中的Pod而不是Node更类似于这里Node概念。总之，节点的关键要素是：
尽管可以使用lan_ip地址作为节点唯一标识符，但为了便于管理，节点应当拥有一个人类可读的充满意义的名称作为节点的Hostname，作为另一个常用的节点唯一标识。
服务是对软件服务（例如Postgres，Redis）的一种命名抽象（named abastraction）。服务可以有各种各样的实现，但其的关键要素在于：
pg-test-primary）同一个数据集簇中通常包括主库与从库，两者分别提供读写服务（primary）和只读副本服务(replica)。
实例指带一个具体的数据库服务器，它可以是单个进程，也可能是共享命运的一组进程，也可以是一个Pod中几个紧密关联的容器。实例的关键要素在于：
例如，我们可以把一个Postgres进程，为之服务的独占Pgbouncer连接池，PgExporter监控组件，高可用组件，管理Agent看作一个提供服务的整体，视为一个数据库实例。
实例隶属于集群，每个实例在集群范围内都有着自己的唯一标识用于区分。
实例由服务负责解析，实例提供被寻址的能力，而Service将请求流量解析到具体的实例组上。
一个对象可以有很多组标签（Tag）与元数据（Metadata/Annotation），但通常只能有一个名字（Name）。
管理数据库和软件与管理宠物类似，都需要花心思照顾。而起名字就是其中非常重要的一项工作。肆意的名字（例如 XÆA-12，NULL，史珍香）很可能会引入不必要的麻烦（额外复杂度），而设计得当的名字则可能会有意想不到的惊喜效果。
总体而言，对象起名应当遵循一些原则：
简洁直白，人类可读：名字是给人看的，因此要好记，便于使用。
体现功能，反映特征：名字需要反映对象的关键特征
独一无二，唯一标识：名字在命名空间内，自己的类目下应当是独一无二，可以惟一标识寻址的。
不要把太多无关的东西塞到名字里去：在名字中嵌入很多重要元数据是一个很有吸引力的想法，但维护起来会非常痛苦，例如反例：pg:user:profile:10.11.12.13:5432:replica:13。
集群名称，其实类似于命名空间的作用。所有隶属本集群的资源，都会使用该命名空间。
集群命名的形式，建议采用符合DNS标准 RFC1034 的命名规则，以免给后续改造埋坑。例如哪一天想要搬到云上去，发现以前用的名字不支持，那就要再改一遍名，成本巨大。
我认为更好的方式是采用更为严格的限制：集群的名称不应该包括点（dot）。应当仅使用小写字母，数字，以及减号连字符（hyphen）-。这样，集群中的所有对象都可以使用这个名称作为前缀，用于各种各样的地方，而不用担心打破某些约束。即集群命名规则为：
cluster_name := [a-z][a-z0-9-]*
之所以强调不要在集群名称中用点，是因为以前很流行一种命名方式，例如com.foo.bar。即由点分割的层次结构命名法。这种命名方式虽然简洁名快，但有一个问题，就是用户给出的名字里可能有任意多的层次，数量不可控。如果集群需要与外部系统交互，而外部系统对于命名有一些约束，那么这样的名字就会带来麻烦。一个最直观的例子是K8s中的Pod，Pod的命名规则中不允许出现.。
集群命名的内涵，建议采用-分隔的两段式，三段式名称，例如：
<集群类型>-<业务>-<业务线>
比如：pg-test-tt就表示tt 业务线下的test集群，类型为pg。pg-user-fin表示fin业务线下的user服务。
节点命名建议采用与k8s Pod一致的命名规则，即
<cluster_name>-<seq>
Node的名称会在集群资源分配阶段确定下来，每个节点都会分配到一个序号${seq}，从0开始的自增整型。这个与k8s中StatefulSet的命名规则保持一致，因此能够做到云上云下一致管理。
例如，集群pg-test有三个节点，那么这三个节点就可以命名为：
pg-test-1, pg-test-2和pg-test-3。
节点的命名，在整个集群的生命周期中保持不变，便于监控与管理。
对于数据库来说，通常都会采用独占式部署方式，一个实例占用整个机器节点。PG实例与Node是一一对应的关系，因此可以简单地采用Node的标识符作为Instance的标识符。例如，节点pg-test-1上的PG实例名即为：pg-test-1，以此类推。
采用独占部署的方式有很大优势，一个节点即一个实例，这样能最小化管理复杂度。混部的需求通常来自资源利用率的压力，但虚拟机或者云平台可以有效解决这种问题。通过vm或pod的抽象，即使是每个redis（1核1G）实例也可以有一个独占的节点环境。
作为一种约定，每个集群中的0号节点（Pod），会作为默认主库。因为它是初始化时第一个分配的节点。
通常来说，数据库对外提供两种基础服务：primary 读写服务，与replica只读副本服务。
那么服务就可以采用一种简单的命名规则：
<cluster_name>-<service_name>
例如这里pg-test集群就包含两个服务：读写服务pg-test-primary与只读副本服务pg-test-replica。
一种流行的实例/节点命名规则：<cluster_name>-<service_role>-<sequence>，即把数据库的主从身份嵌入到实例名称中。这种命名方式有好处也有坏处。好处是管理的时候一眼就能看出来哪一个实例/节点是主库，哪些是从库。缺点是一但发生Failover，实例与节点的名称必须进行调整才能维持一执性，这就带来的额外的维护工作。此外，服务与节点实例是相对独立的概念，这种Embedding命名方式扭曲了这一关系，将实例唯一隶属至服务。但复杂的场景下这一假设可能并不满足。例如，集群可能有几种不同的服务划分方式，而不同的划分方式之间很可能会出现重叠。
因此不要把服务角色嵌入实例名称，而是在服务中维护目标实例列表。毕竟名字并非全能，不要把太多非必要的信息嵌入到对象名称中。
对于系统管理来说，最重要到问题之一就是可观测性（Observability），下图展示了Postgres的可观测性。
原图地址：https://pgstats.dev/
PostgreSQL 提供了丰富的观测接口，包括系统目录，统计视图，辅助函数。 这些都是用户可以观测的信息。这里列出的信息全部为Pigsty所收录。Pigsty通过精心的设计，将晦涩的指标数据，转换成了人类可以轻松理解的洞察。
经典的监控模型中，有三类重要信息：
Pigsty重点关注 指标 信息，也会在后续加入对 日志 的采集、处理与展示，但Pigsty不会收集数据库的 追踪 信息。
下面让以一个具体的例子来介绍指标的获取及其加工产物。
pg_stat_statements是Postgres官方提供的统计插件，可以暴露出数据库中执行的每一类查询的详细统计指标。
图：
pg_stat_statements原始数据视图
这里pg_stat_statements提供的原始指标数据以表格的形式呈现。每一类查询都分配有一个查询ID，紧接着是调用次数，总耗时，最大、最小、平均单次耗时，响应时间都标准差，每次调用平均返回的行数，用于块IO的时间这些指标，（如果是PG13，还有更为细化的计划时间、执行时间、产生的WAL记录数量等新指标）。
这些系统视图与系统信息函数，就是Pigsty中指标数据的原始来源。直接查阅这种数据表很容易让人眼花缭乱，失去焦点。需要将这种指标转换为洞察，也就是以直观图表的方式呈现。
图：加工后的相关监控面板，PG Cluster Query看板部分截图
这里的表格数据经过一系列的加工处理，最终呈现为若干监控面板。最基本的数据加工是对表格中的原始数据进行标红上色，但也足以提供相当实用的改进：慢查询一览无余，但这不过是雕虫小技。重要的是，原始数据视图只能呈现当前时刻的快照；而通过Pigsty，用户可以回溯任意时刻或任意时间段。获取更深刻的性能洞察。
上图是集群视角下的查询看板 （PG Cluster Query），用户可以看到整个集群中所有查询的概览，包括每一类查询的QPS与RT，平均响应时间排名，以及耗费的总时间占比。
当用户对某一类具体查询感兴趣时，就可以点击查询ID，跳转到查询详情页（PG Query Detail）中。如下图所示。这里会显示查询的语句，以及一些核心指标。
图：呈现单类查询的详细信息，PG Query Detail 看板截图
上图是实际生产环境中的一次慢查询优化记录，用户可以从右侧中间的Realtime Response Time 面板中发现一个突变。该查询的平均响应时间从七八秒突降到了七八毫秒。我们定位到了这个慢查询并添加了适当的索引，那么优化的效果就立刻在图表上以直观的形式展现出来，给出实时的反馈。
这就是Pigsty需要解决的核心问题：From observability to insight。
除了指标外，还有一类重要的观测数据：日志（Log），日志是对离散事件的记录与描述。
如果说指标是对数据库系统的被动观测，那么日志就是数据库系统及其周边组件主动上报的信息。
Pigsty目前尚未对数据库日志进行挖掘，但在后续的版本中将集成pgbadger与mtail，引入日志统一收集、分析、处理的基础设施。并添加数据库日志相关的监控指标。
用户可以自行使用开源组件对PostgreSQL日志进行分析。
PostgreSQL提供了对DTrace的支持，用户也可以使用采样探针分析PostgreSQL查询执行时的性能瓶颈。但此类数据仅在某些特定场景会用到，实用性一般，因此Pigsty不会针对数据库收集Trace数据。
只有指标并不够，我们还需要将这些信息组织起来，才能构建出体系来。阅读 监控层级 了解更多信息
正如 Pigsty实体与命名规则 中所介绍，Pigsty中的对象分为多个层次：集群，服务，实例，节点。
Pigsty的监控系统中有着更多的层次，除了实例与集群这两个最为普遍层次，整个系统中还有着其他层次的组织。自顶向下可以分为7个层级：概览，分片，集群，服务，实例，数据库，对象。
图：Pigsty的监控面板被划分为7个逻辑层级与5个实现层级
生产环境的数据库往往是以集群为单位组织的，集群是基本的业务服务单元，也是最为重要的监控层次。
集群是一个由主从复制所关联的一组数据库实例所构成的，实例是最基本的监控层次。
而多套数据库集群共同组成一个现实世界中的生产环境，概览（Overview） 层次的监控提供了对整个环境的整体描述。
按照水平拆分的模式服务于同一业务的多个数据库集群称为分片（Shard），分片层次的监控对于定位数据分布、倾斜等问题很有帮助。
服务 是夹在集群与实例中间的层次，服务通常与DNS，域名，VIP，NodePort等资源紧密关联。
数据库（Database） 是亚实例级对象，一个数据库集群/实例可能会同时有多个数据库存在，数据库层面的监控关注单个数据库内的活动。
对象（Object） 是数据库内的实体，包括表，索引，序列号，函数，查询，连接池等，对象层面的监控关注这些对象的统计指标，与业务紧密相关。
作为一种精简，正如网络的OSI 7层模型在实际中被简化为TCP/IP五层模型一样，这七个层次也以 集群 和 实例 为界，简化为五个层次： 概览（Overview） ，集群（Cluster） ， 服务（Service），实例（Instance） ，数据库（Database） 。
这样，最终的层次划分也变得十分简洁：所有集群层次以上的信息，都是 概览 层次，所有实例以下的监控都算作 数据库 层次，夹在 集群 与 实例 中间的，就是 服务 层次。
分完层次后，最重要的问题就是命名问题：
需要一种方式来标识、引用系统中不同层次内的各个组件，
这种命名方式，应当合理地反映出系统中各个实体的层次关系
这种命名方式，应当可以按照规则自动生成，只有这样，才可以在集群扩容缩容，Failover时做到免维护自动化运行，
当我们理清了系统中存在的层次后，就可以着手为系统中的每个实体起名。
Pigsty所遵循的基本命名规则，请参考 命名规则 一节。
Pigsty使用独立的名称管理机制，实体的命名自成体系。
如果需要与外部系统对接，用户可以直接使用这套命名体系，或通过转接适配的方式采用自己的命名体系。
Pigsty的集群名称由用户指定，满足[a-z0-9][a-z0-9-]*的正则表达式，形如pg-test，pg-meta。
Pigsty的节点从属于集群。Pigsty的节点名称由两部分组成：集群名 与 节点编号，并使用-连接。
形式为${pg_cluster}-${pg_seq}，例如pg-meta-1，pg-test-2。
在形式上，节点编号是长度合理的自然数（包括0），在集群范围内唯一，每个节点都有自己的编号。
实例的编号可以由用户显式指定并分配，通常采用从0或1开始分配，一旦分配，在集群生命周期内不再变更。
Pigsty的实例从属于集群，采用独占节点式部署。
因为实例与节点存在一一对应关系，因此实例名与节点命保持一致。
Pigsty的服务从属于集群。Pigsty的服务名称由两部分组成：集群名 与 角色（Role），并使用-连接。
形式为${pg_cluster}-${pg_role}，例如pg-meta-primary，pg-test-replica。
pg_role的可选项包括：primary|replica|offline|delayed。
primary是特殊的角色，每个集群必须，且只能定义一个pg_role = primary的实例作为主库。
其他的角色大体上由用户定义，其中replica|offline|delayed 是Pigsty预定义的角色。
划分好监控的层级后，需要对为监控对象赋予身份，方能进行管理。
所有的实例都具有身份（Identity），身份信息是与实例关联的元数据，用于标识实例。
图：使用Consul服务发现时，Postgres服务带有的身份信息
身份信息主要包括：
pg_cluster）pg_role）pg_seq）pg_instance）pg_service）其中，集群， 角色， 序号 为核心身份参数， 实例 和 服务 属于衍生身份参数，具体来说：
pg_service = ${pg_cluster}-${pg_role}pg_instance = ${pg_cluster}-${pg_seq}为系统中的对象命名后，还需要将 身份信息 关联至具体的实例上。
身份信息属于业务赋予的元数据，数据库实例本身不会意识到这些身份信息，它不知道自己为谁而服务，从属于哪个业务，或者自己是集群中的几号实例。
身份赋予可以有多种形式，最朴素的身份关联方式就是运维人员的记忆：DBA在脑海中记住了IP地址为10.2.3.4上的数据库实例，是用于支付的实例，而另一台上的数据库实例则用于用户管理。更好的管理方式是通过配置文件，或者采用服务发现的方式来管理集群成员的身份。
Pigsty同时提供这两种身份管理的方式：基于Consul的服务发现，与基于配置文件的服务发现
参数 prometheus_sd_method (consul|static) 控制这一行为：
consul：基于Consul进行服务发现，默认配置static：基于本地配置文件进行服务发现Pigsty建议使用consul服务发现，当服务器发生Failover时，监控系统会自动更正目标实例所注册的身份。
Pigsty默认采用 Consul服务发现的方式管理环境中的服务。
Pigsty内置了基于DCS的配置管理与自动服务发现，用户可以直观地察看系统中的所有节点与服务信息，以及健康状态。Pigsty中的所有服务都会自动注册至DCS中，因此创建、销毁、修改数据库集群时，元数据会自动修正，监控系统能够自动发现监控目标，无需手动维护配置。
用户亦可通过Consul提供的DNS与服务发现机制，实现基于DNS的自动流量切换。
Consul采用了Client/Server架构，整个环境中存在1～5个不等的Consul Server，用于实际的元数据存储。所有节点上都部署有Consul Agent，代理本机服务与Consul Server的通信。Pigsty默认通过本地Consul配置文件的方式注册服务。
在每个节点上，都运行有 consul agent。服务通过JSON配置文件的方式，由consul agent注册至DCS中。
JSON配置文件的默认位置是/etc/consul.d/，采用svc-<service>.json的命名规则，以postgres为例：
{
"service": {
"name": "postgres",
"port": {{ pg_port }},
"tags": [
"{{ pg_role }}",
"{{ pg_cluster }}"
],
"meta": {
"type": "postgres",
"role": "{{ pg_role }}",
"seq": "{{ pg_seq }}",
"instance": "{{ pg_instance }}",
"service": "{{ pg_service }}",
"cluster": "{{ pg_cluster }}",
"version": "{{ pg_version }}"
},
"check": {
"tcp": "127.0.0.1:{{ pg_port }}",
"interval": "15s",
"timeout": "1s"
}
}
}
其中meta与tags部分是服务的元数据，存储有实例的身份信息。
用户可以通过Consul提供的DNS服务，或者直接调用Consul API发现注册到Consul中的服务
使用DNS API查阅consul服务的方式，请参阅Consul文档。
图：查询
pg-bench-1上的pg_exporter服务。
Prometheus会自动通过consul_sd_configs发现环境中的监控对象。同时带有pg和exporter标签的服务会自动被识别为抓取对象：
- job_name: pg
# https://prometheus.io/docs/prometheus/latest/configuration/configuration/#consul_sd_config
consul_sd_configs:
- server: localhost:8500
refresh_interval: 5s
tags:
- pg
- exporter
图：被Prometheus发现的服务，身份信息已关联至实例的指标维度上。
有时候，因为数据库主从发生切换，导致注册的角色与数据库实例的实际角色出现偏差。这时候需要通过反熵过程处理这种异常。
基于Patroni的故障切换可以正常地通过回调逻辑修正注册的角色，但人工完成的角色切换则需要人工介入处理。
使用以下脚本可以自动检测并修复数据库的服务注册。建议在数据库实例上配置Crontab，或在元节点上设置定期巡检任务。
/pg/bin/pg-register $(pg-role)
static服务发现依赖/etc/prometheus/targets/*.yml中的配置进行服务发现。采用这种方式的优势是不依赖Consul。
当Pigsty监控系统与外部管控方案集成时，这种模式对原系统的侵入性较小。但是缺点是，当集群内发生主从切换时，用户需要自行维护实例角色信息。手动维护时，可以根据以下命令从配置文件生成Prometheus所需的监控对象配置文件并载入生效。
详见 Prometheus目标。
./infra.yml --tags=prometheus_targtes,prometheus_reload
Pigsty默认生成的静态监控对象文件示例如下：
#==============================================================#
# File : targets/all.yml
# Ctime : 2021-02-18
# Mtime : 2021-02-18
# Desc : Prometheus Static Monitoring Targets Definition
# Path : /etc/prometheus/targets/all.yml
# Copyright (C) 2018-2021 Ruohang Feng
#==============================================================#
#======> pg-meta-1 [primary]
- labels: {cls: pg-meta, ins: pg-meta-1, ip: 10.10.10.10, role: primary, svc: pg-meta-primary}
targets: [10.10.10.10:9630, 10.10.10.10:9100, 10.10.10.10:9631, 10.10.10.10:9101]
#======> pg-test-1 [primary]
- labels: {cls: pg-test, ins: pg-test-1, ip: 10.10.10.11, role: primary, svc: pg-test-primary}
targets: [10.10.10.11:9630, 10.10.10.11:9100, 10.10.10.11:9631, 10.10.10.11:9101]
#======> pg-test-2 [replica]
- labels: {cls: pg-test, ins: pg-test-2, ip: 10.10.10.12, role: replica, svc: pg-test-replica}
targets: [10.10.10.12:9630, 10.10.10.12:9100, 10.10.10.12:9631, 10.10.10.12:9101]
#======> pg-test-3 [replica]
- labels: {cls: pg-test, ins: pg-test-3, ip: 10.10.10.13, role: replica, svc: pg-test-replica}
targets: [10.10.10.13:9630, 10.10.10.13:9100, 10.10.10.13:9631, 10.10.10.13:9101]
无论是通过Consul服务发现，还是静态文件服务发现。最终的效果是实现身份信息与实例监控指标相互关联。
这一关联，是通过 监控指标 的维度标签实现的。
| 身份参数 | 维度标签 | 取值样例 |
|---|---|---|
pg_cluster |
cls |
pg-test |
pg_instance |
ins |
pg-test-1 |
pg_services |
svc |
pg-test-primary |
pg_role |
role |
primary |
node_ip |
ip |
10.10.10.11 |
阅读下一节 监控指标 ，了解这些指标是如何通过标签组织起来的。
指标（Metric） 是Pigsty监控系统的核心概念。
指标在形式上是可累加的，原子性的逻辑计量单元，可在时间段上进行更新与统计汇总。
指标通常以 带有维度标签的时间序列 的形式存在。举个例子，Pigsty沙箱中的pg:ins:qps_realtime指展示了所有实例的实时QPS。
pg:ins:qps_realtime{cls="pg-meta", ins="pg-meta-1", ip="10.10.10.10", role="primary"} 0
pg:ins:qps_realtime{cls="pg-test", ins="pg-test-1", ip="10.10.10.11", role="primary"} 327.6
pg:ins:qps_realtime{cls="pg-test", ins="pg-test-2", ip="10.10.10.12", role="replica"} 517.0
pg:ins:qps_realtime{cls="pg-test", ins="pg-test-3", ip="10.10.10.13", role="replica"} 0
用户可以对指标进行运算：求和、求导，聚合，等等。例如：
$ sum(pg:ins:qps_realtime) by (cls) -- 查询按集群聚合的 实时实例QPS
{cls="pg-meta"} 0
{cls="pg-test"} 844.6
$ avg(pg:ins:qps_realtime) by (cls) -- 查询每个集群中 所有实例的平均 实时实例QPS
{cls="pg-meta"} 0
{cls="pg-test"} 280
$ avg_over_time(pg:ins:qps_realtime[30m]) -- 过去30分钟内实例的平均QPS
pg:ins:qps_realtime{cls="pg-meta", ins="pg-meta-1", ip="10.10.10.10", role="primary"} 0
pg:ins:qps_realtime{cls="pg-test", ins="pg-test-1", ip="10.10.10.11", role="primary"} 130
pg:ins:qps_realtime{cls="pg-test", ins="pg-test-2", ip="10.10.10.12", role="replica"} 100
pg:ins:qps_realtime{cls="pg-test", ins="pg-test-3", ip="10.10.10.13", role="replica"} 0
每一个指标（Metric），都是一类数据，通常会对应多个时间序列（time series）。同一个指标对应的不同时间序列通过维度进行区分。
指标 + 维度，可以具体定位一个时间序列。每一个时间序列都是由 （时间戳，取值）二元组构成的数组。
Pigsty采用Prometheus的指标模型，其逻辑概念可以用以下的SQL DDL表示。
-- 指标表，指标与时间序列构成1:n关系
CREATE TABLE metrics (
id INT PRIMARY KEY, -- 指标标识
name TEXT UNIQUE -- 指标名称，[...其他指标元数据，例如类型]
);
-- 时间序列表，每个时间序列都对应一个指标。
CREATE TABLE series (
id BIGINT PRIMARY KEY, -- 时间序列标识
metric_id INTEGER REFERENCES metrics (id), -- 时间序列所属的指标
dimension JSONB DEFAULT '{}' -- 时间序列带有的维度信息，采用键值对的形式表示
);
-- 时许数据表，保存最终的采样数据点。每个采样点都属于一个时间序列
CREATE TABLE series_data (
series_id BIGINT REFERENCES series(id), -- 时间序列标识
ts TIMESTAMP, -- 采样点时间戳
value FLOAT, -- 采样点指标值
PRIMARY KEY (series_id, ts) -- 每个采样点可以通过 所属时间序列 与 时间戳 唯一标识
);
这里我们以pg:ins:qps指标为例：
-- 样例指标数据
INSERT INTO metrics VALUES(1, 'pg:ins:qps'); -- 该指标名为 pg:ins:qps ，是一个 GAUGE。
INSERT INTO series VALUES -- 该指标包含有四个时间序列，通过维度标签区分
(1001, 1, '{"cls": "pg-meta", "ins": "pg-meta-1", "role": "primary", "other": "..."}'),
(1002, 1, '{"cls": "pg-test", "ins": "pg-test-1", "role": "primary", "other": "..."}'),
(1003, 1, '{"cls": "pg-test", "ins": "pg-test-2", "role": "replica", "other": "..."}'),
(1004, 1, '{"cls": "pg-test", "ins": "pg-test-3", "role": "replica", "other": "..."}');
INSERT INTO series_data VALUES -- 每个时间序列底层的采样点
(1001, now(), 1000), -- 实例 pg-meta-1 在当前时刻QPS为1000
(1002, now(), 1000), -- 实例 pg-test-1 在当前时刻QPS为1000
(1003, now(), 5000), -- 实例 pg-test-2 在当前时刻QPS为1000
(1004, now(), 5001); -- 实例 pg-test-3 在当前时刻QPS为5001
pg_up 是一个指标，包含有4个时间序列。记录了整个环境中所有实例的存活状态。pg_up{ins": "pg-test-1", ...}是一个时间序列，记录了特定实例pg-test-1 的存活状态Pigsty的监控数据主要有四种主要来源： 数据库，连接池，操作系统，负载均衡器。通过相应的exporter对外暴露。
完整来源包括：
关于全部可用的指标清单，请查阅 参考-指标清单 一节
那么，Pigsty总共包含了多少指标呢？ 这里是一副各个指标来源占比的饼图。我们可以看到，右侧蓝绿黄对应的部分是数据库及数据库相关组件所暴露的指标，而左下方红橙色部分则对应着机器节点相关指标。左上方紫色部分则是负载均衡器的相关指标。
数据库指标中，与postgres本身有关的原始指标约230个，与中间件有关的原始指标约50个，基于这些原始指标，Pigsty又通过层次聚合与预计算，精心设计出约350个与DB相关的衍生指标。
因此，对于每个数据库集群来说，单纯针对数据库及其附件的监控指标就有621个。而机器原始指标281个，衍生指标83个一共364个。加上负载均衡器的170个指标，我们总共有接近1200类指标。
注意，这里我们必须辨析一下指标（metric）与时间序列（ Time-series）的区别。
这里我们使用的量词是 类 而不是个 。 因为一个指标可能对应多个时间序列。例如一个数据库中有20张表，那么 pg_table_index_scan 这样的指标就会对应有20个对应的时间序列。
截止至2021年，Pigsty的指标覆盖率在所有作者已知的开源/商业监控系统中一骑绝尘，详情请参考横向对比。
Pigsty还会基于现有指标进行加工处理，产出 衍生指标（Derived Metrics） 。
例如指标可以按照不同的层次进行聚合
从原始监控时间序列数据，到最终的成品图表，中间还有着若干道加工工序。
这里以TPS指标的衍生流程为例。
原始数据是从Pgbouncer抓取得到的事务计数器，集群中有四个实例，而每个实例上又有两个数据库，所以一个实例总共有8个DB层次的TPS指标。
而下面的图表，则是整个集群内每个实例的QPS横向对比，因此在这里，我们使用预定义的规则，首先对原始事务计数器求导获取8个DB层面的TPS指标，然后将8个DB层次的时间序列聚合为4个实例层次的TPS指标，最后再将这四个实例级别的TPS指标聚合为集群层次的TPS指标。
Pigsty共定义了360类衍生聚合指标，后续还会不断增加。衍生指标定义规则详见 参考-衍生指标
目录（Catalog） 是一种特殊的指标
Catalog与Metrics比较相似但又不完全相同，边界比较模糊。最简单的例子，一个表的页面数量和元组数量，应该算Catalog还是算Metrics？
跳过这种概念游戏，实践上Catalog和Metrics主要的区别是，Catalog里的信息通常是不怎么变化的，比如表的定义之类的，如果也像Metrics这样比如几秒抓一次，显然是一种浪费。所以我们会将这一类偏静态的信息划归Catalog。
Catalog主要由定时任务（例如巡检）负责抓取，而不由Prometheus采集。一些特别重要的Catalog信息，例如pg_class中的一些信息，也会转换为指标被Prometheus所采集。
了解了Pigsty指标后，不妨了解一下Pigsty的报警系统是如何将这些指标数据用于实际生产用途的。
报警对于日常故障响应，提高系统可用性至关重要。
漏报会导致可用性降低，误报会导致敏感性下降，有必要对报警规则进行审慎的设计。
按紧急程度分类
P0：FATAL：产生重大场外影响的事故，需要紧急介入处理。例如主库宕机，复制中断。（严重事故）
P1：ERROR：场外影响轻微，或有冗余处理的事故，需要在分钟级别内进行响应处理。（事故）
P2：WARNING：即将产生影响，放任可能在小时级别内恶化，需在小时级别进行响应。（关注事件）
P3：NOTICE：需要关注，不会有即时的影响，但需要在天级别内进行响应。（偏差现象）
按报警层次分类
按指标类型分类
Pigsty使用条状图呈现报警信息。横轴代表时间段，一段色条代表报警事件。只有处于 激发（Firing） 状态的报警才会显示在报警图表中。
报警规则按类型可粗略分为四类：错误，延迟，饱和度，流量。其中：
Postgres实例宕机区分主从，主库宕机触发P0报警，从库宕机触发P1报警。两者都需要立即介入，但从库通常有多个实例，且可以降级到主库上查询，有着更高的处理余量，所以从库宕机定为P1。
# primary|master instance down for 1m triggers a P0 alert
- alert: PG_PRIMARY_DOWN
expr: pg_up{instance=~'.*master.*'}
for: 1m
labels:
team: DBA
urgency: P0
annotations:
summary: "P0 Postgres Primary Instance Down: {{$labels.instance}}"
description: "pg_up = {{ $value }} {{$labels.instance}}"
# standby|slave instance down for 1m triggers a P1 alert
- alert: PG_STANDBY_DOWN
expr: pg_up{instance!~'.*master.*'}
for: 1m
labels:
team: DBA
urgency: P1
annotations:
summary: "P1 Postgres Standby Instance Down: {{$labels.instance}}"
description: "pg_up = {{ $value }} {{$labels.instance}}"
Pgbouncer实例因为与Postgres实例一一对应，其存活性报警规则与Postgres统一。
# primary pgbouncer down for 1m triggers a P0 alert
- alert: PGB_PRIMARY_DOWN
expr: pgbouncer_up{instance=~'.*master.*'}
for: 1m
labels:
team: DBA
urgency: P0
annotations:
summary: "P0 Pgbouncer Primary Instance Down: {{$labels.instance}}"
description: "pgbouncer_up = {{ $value }} {{$labels.instance}}"
# standby pgbouncer down for 1m triggers a P1 alert
- alert: PGB_STANDBY_DOWN
expr: pgbouncer_up{instance!~'.*master.*'}
for: 1m
labels:
team: DBA
urgency: P1
annotations:
summary: "P1 Pgbouncer Standby Instance Down: {{$labels.instance}}"
description: "pgbouncer_up = {{ $value }} {{$labels.instance}}"
Prometheus Exporter的存活性定级为P1，虽然Exporter宕机本身并不影响数据库服务，但这通常预示着一些不好的情况，而且监控数据的缺失也会产生某些相应的报警。Exporter的存活性是通过Prometheus自己的up指标检测的，需要注意某些单实例多DB的特例。
# exporter down for 1m triggers a P1 alert
- alert: PG_EXPORTER_DOWN
expr: up{port=~"(9185|9127)"} == 0
for: 1m
labels:
team: DBA
urgency: P1
annotations:
summary: "P1 Exporter Down: {{$labels.instance}} {{$labels.port}}"
description: "port = {{$labels.port}}, {{$labels.instance}}"
所有存活性检测的持续时间阈值设定为1分钟，对15s的默认采集周期而言是四个样本点。常规的重启操作通常不会触发存活性报警。
与复制延迟有关的报警有三个：复制中断，复制延迟高，复制延迟异常，分别定级为P1, P2, P3
其中复制中断是一种错误，使用指标：pg_repl_state_count{state="streaming"}进行判断，当前streaming状态的从库如果数量发生负向变动，则触发break报警。walsender会决定复制的状态，从库直接断开会产生此现象，缓冲区出现积压时会从streaming进入catchup状态也会触发此报警。此外，采用-Xs手工制作备份结束时也会产生此报警，此报警会在10分钟后自动Resolve。复制中断会导致客户端读到陈旧的数据，具有一定的场外影响，定级为P1。
复制延迟可以使用延迟时间或者延迟字节数判定。以延迟字节数为权威指标。常规状态下，复制延迟时间在百毫秒量级，复制延迟字节在百KB量级均属于正常。目前采用的是5s,15s的时间报警阈值。根据历史经验数据，这里采用了时间8秒与字节32MB的阈值，大致报警频率为每天个位数个。延迟时间更符合直觉，所以采用8s的P2报警，但并不是所有的从库都能有效取到该指标所以使用32MB的字节阈值触发P3报警补漏。
特例：antispam,stats,coredb均经常出现复制延迟。
# replication break for 1m triggers a P0 alert. auto-resolved after 10 minutes.
- alert: PG_REPLICATION_BREAK
expr: pg_repl_state_count{state="streaming"} - (pg_repl_state_count{state="streaming"} OFFSET 10m) < 0
for: 1m
labels:
team: DBA
urgency: P0
annotations:
summary: "P0 Postgres Streaming Replication Break: {{$labels.instance}}"
description: "delta = {{ $value }} {{$labels.instance}}"
# replication lag greater than 8 second for 3m triggers a P1 alert
- alert: PG_REPLICATION_LAG
expr: pg_repl_replay_lag{application_name="walreceiver"} > 8
for: 3m
labels:
team: DBA
urgency: P1
annotations:
summary: "P1 Postgres Replication Lagged: {{$labels.instance}}"
description: "lag = {{ $value }} seconds, {{$labels.instance}}"
# replication diff greater than 32MB for 5m triggers a P3 alert
- alert: PG_REPLICATOIN_DIFF
expr: pg_repl_lsn{application_name="walreceiver"} - pg_repl_replay_lsn{application_name="walreceiver"} > 33554432
for: 5m
labels:
team: DBA
urgency: P3
annotations:
summary: "P3 Postgres Replication Diff Deviant: {{$labels.instance}}"
description: "delta = {{ $value }} {{$labels.instance}}"
饱和度指标主要资源，包含很多系统级监控的指标。主要包括：CPU，磁盘（这两个属于系统监控但对于DB非常重要所以纳入），连接池排队，数据库后端连接数，年龄（本质是可用事物号的饱和度），SSD寿命等。
堆积检测
堆积主要包含两类指标，一方面是PG本身的后端连接数与活跃连接数，另一方面是连接池的排队情况。
PGB排队是决定性的指标，它代表用户端可感知的阻塞已经出现，因此，配置排队超过15持续1分钟触发P0报警。
# more than 8 client waiting in queue for 1 min triggers a P0 alert
- alert: PGB_QUEUING
expr: sum(pgbouncer_pool_waiting_clients{datname!="pgbouncer"}) by (instance,datname) > 8
for: 1m
labels:
team: DBA
urgency: P0
annotations:
summary: "P0 Pgbouncer {{ $value }} Clients Wait in Queue: {{$labels.instance}}"
description: "waiting clients = {{ $value }} {{$labels.instance}}"
后端连接数是一个重要的报警指标，如果后端连接持续达到最大连接数，往往也意味着雪崩。连接池的排队连接数也能反映这种情况，但不能覆盖应用直连数据库的情况。后端连接数的主要问题是它与连接池关系密切，连接池在短暂堵塞后会迅速打满后端连接，但堵塞恢复后这些连接必须在默认约10min的Timeout后才被释放。因此收到短暂堆积的影响较大。同时外晚上1点备份时也会出现这种情况，容易产生误报。
注意后端连接数与后端活跃连接数不同，目前报警使用的是活跃连接数。后端活跃连接数通常在0～1，一些慢库在十几左右，离线库可能会达到20～30。但后端连接/进程数（不管活跃不活跃），通常均值可达50。后端连接数更为直观准确。
对于后端连接数，这里使用两个等级的报警：超过90持续3分钟P1，以及超过80持续10分钟P2，考虑到通常数据库最大连接数为100。这样做可以以尽可能低的误报率检测到雪崩堆积。
# num of backend exceed 90 for 3m
- alert: PG_BACKEND_HIGH
expr: sum(pg_db_numbackends) by (node) > 90
for: 3m
labels:
team: DBA
urgency: P1
annotations:
summary: "P1 Postgres Backend Number High: {{$labels.instance}}"
description: "numbackend = {{ $value }} {{$labels.instance}}"
# num of backend exceed 80 for 10m (avoid pgbouncer jam false alert)
- alert: PG_BACKEND_WARN
expr: sum(pg_db_numbackends) by (node) > 80
for: 10m
labels:
team: DBA
urgency: P2
annotations:
summary: "P2 Postgres Backend Number Warn: {{$labels.instance}}"
description: "numbackend = {{ $value }} {{$labels.instance}}"
空闲事务
目前监控使用IDEL In Xact的绝对数量作为报警条件，其实 Idle In Xact的最长持续时间可能会更有意义。因为这种现象其实已经被后端连接数覆盖了。长时间的空闲是我们真正关注的，因此这里使用所有空闲事务中最高的闲置时长作为报警指标。设置3分钟为P2报警阈值。经常出现IDLE的非Offline库有：moderation, location, stats,sms, device, moderationdevice
# max idle xact duration exceed 3m
- alert: PG_IDLE_XACT
expr: pg_activity_max_duration{instance!~".*offline.*", state=~"^idle in transaction.*"} > 180
for: 3m
labels:
team: DBA
urgency: P2
annotations:
summary: "P2 Postgres Long Idle Transaction: {{$labels.instance}}"
description: "duration = {{ $value }} {{$labels.instance}}"
资源报警
CPU, 磁盘，AGE
默认清理年龄为2亿，超过10Y报P1，既留下了充分的余量，又不至于让人忽视。
# age wrap around (progress in half 10Y) triggers a P1 alert
- alert: PG_XID_WRAP
expr: pg_database_age{} > 1000000000
for: 3m
labels:
team: DBA
urgency: P1
annotations:
summary: "P1 Postgres XID Wrap Around: {{$labels.instance}}"
description: "age = {{ $value }} {{$labels.instance}}"
磁盘和CPU由运维配置，不变
因为各个业务的负载情况不一，为流量指标设置绝对值是相对困难的。这里只对TPS和Rollback设置绝对值指标。而且较为宽松。
Rollback OPS超过4则发出P3警告，TPS超过24000发P2，超过30000发P1
# more than 30k TPS lasts for 1m triggers a P1 (pgbouncer bottleneck)
- alert: PG_TPS_HIGH
expr: rate(pg_db_xact_total{}[1m]) > 30000
for: 1m
labels:
team: DBA
urgency: P1
annotations:
summary: "P1 Postgres TPS High: {{$labels.instance}} {{$labels.datname}}"
description: "TPS = {{ $value }} {{$labels.instance}}"
# more than 24k TPS lasts for 3m triggers a P2
- alert: PG_TPS_WARN
expr: rate(pg_db_xact_total{}[1m]) > 24000
for: 3m
labels:
team: DBA
urgency: P2
annotations:
summary: "P2 Postgres TPS Warning: {{$labels.instance}} {{$labels.datname}}"
description: "TPS = {{ $value }} {{$labels.instance}}"
# more than 4 rollback per seconds lasts for 5m
- alert: PG_ROLLBACK_WARN
expr: rate(pg_db_xact_rollback{}[1m]) > 4
for: 5m
labels:
team: DBA
urgency: P2
annotations:
summary: "P2 Postgres Rollback Warning: {{$labels.instance}}"
description: "rollback per sec = {{ $value }} {{$labels.instance}}"
QPS的指标与业务高度相关，因此不适合配置绝对值，可以为QPS突增配置一个报警项
短时间（和10分钟）前比突增30%会触发一个P2警报，同时避免小QPS下的突发流量，设置一个绝对阈值10k
# QPS > 10000 and have a 30% inc for 3m triggers P2 alert
- alert: PG_QPS_BURST
expr: sum by(datname,instance)(rate(pgbouncer_stat_total_query_count{datname!="pgbouncer"}[1m]))/sum by(datname,instance) (rate(pgbouncer_stat_total_query_count{datname!="pgbouncer"}[1m] offset 10m)) > 1.3 and sum by(datname,instance) (rate(pgbouncer_stat_total_query_count{datname!="pgbouncer"}[1m])) > 10000
for: 3m
labels:
team: DBA
urgency: P1
annotations:
summary: "P2 Pgbouncer QPS Burst 30% and exceed 10000: {{$labels.instance}}"
description: "qps = {{ $value }} {{$labels.instance}}"
完整的报警规则详见：参考-报警规则
所谓供给方案（Provisioning Solution），指的是一套向用户交付数据库服务与监控系统的系统。
供给方案不是数据库，而是数据库工厂：
用户向供给系统提交一份配置，供给系统便会按照用户所需的规格在环境中创建出所需的数据库集群来。
这比较类似于向Kubernetes提交YAML文件，创建所需的各类资源。
例如，以下配置信息声明了一套名为pg-test的PostgreSQL数据库集群。
#-----------------------------
# cluster: pg-test
#-----------------------------
pg-test: # define cluster named 'pg-test'
# - cluster members - #
hosts:
10.10.10.11: {pg_seq: 1, pg_role: primary, ansible_host: node-1}
10.10.10.12: {pg_seq: 2, pg_role: replica, ansible_host: node-2}
10.10.10.13: {pg_seq: 3, pg_role: replica, ansible_host: node-3, pg_offline_query: true}
# - cluster configs - #
vars:
# basic settings
pg_cluster: pg-test # define actual cluster name
pg_version: 13 # define installed pgsql version
node_tune: tiny # tune node into oltp|olap|crit|tiny mode
pg_conf: tiny.yml # tune pgsql into oltp/olap/crit/tiny mode
# business users, adjust on your own needs
pg_users:
- name: test # example production user have read-write access
password: test # example user's password
roles: [dbrole_readwrite] # dborole_admin|dbrole_readwrite|dbrole_readonly|dbrole_offline
pgbouncer: true # production user that access via pgbouncer
comment: default test user for production usage
pg_databases: # create a business database 'test'
- name: test # use the simplest form
pg_default_database: test # default database will be used as primary monitor target
# proxy settings
vip_enabled: true # enable/disable vip (require members in same LAN)
vip_address: 10.10.10.3 # virtual ip address
vip_cidrmask: 8 # cidr network mask length
vip_interface: eth1 # interface to add virtual ip
当我们执行 数据库供给 脚本 ./pgsql.yml 时，供给系统会根据清单中的定义，在10.10.10.11，10.10.10.12，10.10.10.13这三台机器上生成一主两从的PostgreSQL集群pg-test。并创建名为test的用户与数据库。同时，Pigsty还会根据要求，声明一个10.10.10.3的VIP绑定在集群的主库上面。结构如下图所示。
您能够定义的不仅仅是数据库集群，还包括了整个基础设施。
Pigsty通过130+个变量实现了对数据库运行时环境的完整表述。
详细的可配置项，请参考 配置指南
供给方案通常只负责集群的创建。一旦集群创建完毕，日常的管理应当由管控平台负责。
尽管如此，Pigsty目前不包含管控平台部分，因此也提供了简单的资源回收销毁脚本，并亦可用于资源的更新与管理。但须知此并非供给方案的本职工作。
Pigsty的架构在部署上分为两个部分：
Pigsty的部署对象也可以分为两种：
以Pigsty附带的四节点沙箱环境为例，Pigsty中涉及的主要组件及其分布如下图所示：
图：Pigsty沙箱中包含的节点与组件
上图中 meta 即为元节点，部署有额外的基础设施组件。 node-1，node-2，node-3 为普通数据库节点，部署有数据库集群pg-test。
meta被复用为普通数据库节点，部署有单主数据库集群pg-meta。
每一套 环境（Environment） 中，都需要有一些基础设施，才能使整个系统正常工作。
基础设施通常由专业的运维团队或云厂商负责，但Pigsty作为一个开箱即用的产品解决方案，将基本的基础设施集成至供给方案中。
包括：
基础设施部署于 元节点 上。一套环境中包含一个或多个元节点，用于基础设施部署。
除了**分布式配置存储（DCS）**之外，所有基础设施组件都采用副本式部署；如果有多个元节点，元节点上的DCS（etcd/consul）会共同作为DCS Server。
在每套环境中，Pigsty最少需要一个元节点，该节点将作为整个环境的控制中心。
元节点负责各种管理工作：保存状态，管理配置，发起任务，收集指标，等等。
整个环境的基础设施组件，Nginx，Grafana，Prometheus，Alertmanager，NTP，DNS Nameserver，DCS都将部署在元节点上。
同时，元节点也将用于部署元数据库 （Consul 或 Etcd），用户也可以使用已有的外部DCS集群。
如果将DCS部署至元节点上，建议在生产环境使用3个元节点，以充分保证DCS服务的可用性。
DCS外的基础设施组件都将以对等副本的方式部署在所有元节点上。
元节点的数量要求最少1个，推荐3个，建议不超过5个。
元节点上运行的服务如下所示：
| 组件 | 端口 | 默认域名 | 说明 |
|---|---|---|---|
| Grafana | 3000 | g.pigsty |
Pigsty监控系统图形界面 |
| Prometheus | 9090 | p.pigsty |
监控时序数据库 |
| AlterManager | 9093 | a.pigsty |
报警聚合管理组件 |
| Consul | 8500 | c.pigsty |
分布式配置管理，服务发现 |
| Consul DNS | 8600 | - | Consul提供的DNS服务 |
| Nginx | 80 | pigsty |
所有服务的入口代理 |
| Yum Repo | 80 | yum.pigsty |
本地Yum源 |
| Haproxy Index | 80 | h.pigsty |
所有Haproxy管理界面的访问代理 |
| NTP | 123 | n.pigsty |
环境统一使用的NTP时间服务器 |
| Dnsmasq | 53 | - | 环境统一使用的DNS域名解析服务器 |
生产环境的数据库以集群为单位进行组织，集群是一个由主从复制所关联的一组数据库实例所构成的逻辑实体。每个数据库集群是一个自组织的业务服务单元，由至少一个数据库实例组成。
集群是基本的业务服务单元，下图展示了沙箱环境中的复制拓扑。其中pg-meta-1单独构成一个数据库集群pg-meta，而pg-test-1，pg-test-2，pg-test-3共同构成另一个逻辑集群pg-test。
pg-meta-1
(primary)
pg-test-1 -------------> pg-test-2
(primary) | (replica)
|
^-------> pg-test-3
(replica)
下图从数据库集群的视角重新排列pg-test集群中相关组件的位置。
图：从数据库集群的逻辑视角看架构
Pigsty是数据库供给方案，可以按需创建高可用数据库集群。只要集群中有任意实例存活，集群就可以对外提供完整的读写服务与只读服务。Pigsty可以自动进行故障切换，业务方只读流量不受影响；读写流量的影响视具体配置与负载，通常在几秒到几十秒的范围。
在Pigsty中，每个“数据库实例”在使用上是幂等的，采用类似NodePort的方式对外暴露服务。默认情况下，访问任意实例的5433端口即可访问主库，访问任意实例的5434端口即可访问从库。用户也可以灵活地同时使用不同的方式访问数据库。
数据库节点负责运行数据库实例，数据库实例采用独占式部署，一个节点上有且仅有一个数据库实例。
一个典型的数据库节点上运行的服务如下所示：
| 组件 | 端口 | 说明 |
|---|---|---|
| Postgres | 5432 | Postgres数据库服务 |
| Pgbouncer | 6432 | Pgbouncer连接池服务 |
| Patroni | 8008 | Patroni高可用组件 |
| Consul | 8500 | 分布式配置管理，服务发现组件Consul的本地Agent |
| Haproxy Primary | 5433 | 集群读写服务（主库）代理 |
| Haproxy Replica | 5434 | 集群只读服务（从库）代理 |
| Haproxy Admin | 9101 | Haproxy 监控指标与管理页面 |
| PG Exporter | 9630 | Postgres监控指标导出器 |
| PGBouncer Exporter | 9631 | Pgbouncer监控指标导出器 |
| Node Exporter | 9100 | 机器节点监控指标导出器 |
| Consul DNS | 8600 | Consul提供的DNS服务 |
| vip-manager | x | 将VIP绑定至集群主库上 |
Pigsty创建的数据库集群是分布式、高可用的数据库集群。
从效果上讲，只要集群中有任意实例存活，集群就可以对外提供完整的读写服务与只读服务。
数据库集群中的每个数据库实例在使用上都是幂等的，任意实例都可以通过内建负载均衡组件提供完整的读写服务。
数据库集群可以自动进行故障检测与主从切换，普通故障能在几秒到几十秒内自愈，且期间只读流量不受影响。
两个核心场景：Switchover，Failover
四个核心问题：故障检测，Fencing，选主，流量切换
关于高可用的核心场景演练，请参考 高可用演练 一节。
基于Patroni的高可用方案部署简单，不需要使用特殊硬件，具有大量实际生产使用案例背书。
Pigsty的高可用方案基于Patroni，vip-manager，haproxy，Patroni基于DCS（etcd/consul/zookeeper）达成选主共识。
Patroni的故障检测基于DCS判定，采用心跳包保活，租约机制，主库持有租约。秦失其鹿，则天下共逐之。
Patroni的Fencing基于Linux内核模块watchdog。
Patroni提供了主从健康检查，便于与外部负载均衡器相集成。
Haproxy幂等地部署在集群的每个实例上，任何一个或多个Haproxy实例都可以作为集群的负载均衡器。
Haproxy采用类似Node Port的方式对外暴露服务，默认情况下，5433端口提供集群的读写服务，而5434端口提供集群的只读服务。
Haproxy本身的高可用性可通过以下几种方式达成：
详细信息，请参考 数据库访问 一节。
以下参数与Pigsty目录结构相关
/var/lib/pgsql/usr/pgsql/bin//pg/data/export/var/backups（可选，也可以选择备份到主数据盘上）#------------------------------------------------------------------------------
# Create Directory
#------------------------------------------------------------------------------
# this assumes that
# /pg is shortcut for postgres home
# {{ pg_fs_main }} contains the main data (MUST ALREADY MOUNTED)
# {{ pg_fs_bkup }} contains archive and backup data (MUST ALREADY MOUNTED)
# cluster-version is the default parent folder for pgdata (e.g pg-test-12)
#------------------------------------------------------------------------------
# default variable:
# pg_fs_main = /export fast ssd
# pg_fs_bkup = /var/backups cheap hdd
#
# /pg -> /export/postgres/pg-test-12
# /pg/data -> /export/postgres/pg-test-12/data
#------------------------------------------------------------------------------
- name: Create postgresql directories
tags: pg_dir
become: yes
block:
- name: Make sure main and backup dir exists
file: path={{ item }} state=directory owner=root mode=0777
with_items:
- "{{ pg_fs_main }}"
- "{{ pg_fs_bkup }}"
# pg_cluster_dir: "{{ pg_fs_main }}/postgres/{{ pg_cluster }}-{{ pg_version }}"
- name: Create postgres directory structure
file: path={{ item }} state=directory owner={{ pg_dbsu }} group=postgres mode=0700
with_items:
- "{{ pg_fs_main }}/postgres"
- "{{ pg_cluster_dir }}"
- "{{ pg_cluster_dir }}/bin"
- "{{ pg_cluster_dir }}/log"
- "{{ pg_cluster_dir }}/tmp"
- "{{ pg_cluster_dir }}/conf"
- "{{ pg_cluster_dir }}/data"
- "{{ pg_cluster_dir }}/meta"
- "{{ pg_cluster_dir }}/stat"
- "{{ pg_cluster_dir }}/change"
- "{{ pg_backup_dir }}/postgres"
- "{{ pg_backup_dir }}/arcwal"
- "{{ pg_backup_dir }}/backup"
- "{{ pg_backup_dir }}/remote"
在RedHat/CentOS上，默认的Postgres发行版安装位置为
/usr/pgsql-${pg_version}/
安装剧本会自动创建指向当前安装版本的软连接，例如，如果安装了13版本的Postgres，则有：
/usr/pgsql -> /usr/pgsql-13
因此，默认的pg_bin_dir为/usr/pgsql/bin/，该路径会在/etc/profile.d/pgsql.sh中添加至所有用户的PATH环境变量中。
Pigsty假设用于部署数据库实例的单个节点上至少有一块主数据盘（pg_fs_main），以及一块可选的备份数据盘（pg_fs_bkup）。通常主数据盘是高性能SSD，而备份盘是大容量廉价HDD。
#------------------------------------------------------------------------------
# Create Directory
#------------------------------------------------------------------------------
# this assumes that
# /pg is shortcut for postgres home
# {{ pg_fs_main }} contains the main data (MUST ALREADY MOUNTED)
# {{ pg_fs_bkup }} contains archive and backup data (MAYBE ALREADY MOUNTED)
# {{ pg_cluster }}-{{ pg_version }} is the default parent folder
# for pgdata (e.g pg-test-12)
#------------------------------------------------------------------------------
# default variable:
# pg_fs_main = /export fast ssd
# pg_fs_bkup = /var/backups cheap hdd
#
# /pg -> /export/postgres/pg-test-12
# /pg/data -> /export/postgres/pg-test-12/data
# basic
{{ pg_fs_main }} /export # contains all business data (pg,consul,etc..)
{{ pg_dir_main }} /export/postgres # contains postgres main data
{{ pg_cluster_dir }} /export/postgres/pg-test-13 # contains cluster `pg-test` data (of version 13)
/export/postgres/pg-test-13/bin # binary scripts
/export/postgres/pg-test-13/log # misc logs
/export/postgres/pg-test-13/tmp # tmp, sql files, records
/export/postgres/pg-test-13/conf # configurations
/export/postgres/pg-test-13/data # main data directory
/export/postgres/pg-test-13/meta # identity information
/export/postgres/pg-test-13/stat # stats information
/export/postgres/pg-test-13/change # changing records
{{ pg_fs_bkup }} /var/backups # contains all backup data (pg,consul,etc..)
{{ pg_dir_bkup }} /var/backups/postgres # contains postgres backup data
{{ pg_backup_dir }} /var/backups/postgres/pg-test-13 # contains cluster `pg-test` backup (of version 13)
/var/backups/postgres/pg-test-13/backup # base backup
/var/backups/postgres/pg-test-13/arcwal # WAL archive
/var/backups/postgres/pg-test-13/remote # mount NFS/S3 remote resources here
# links
/pg -> /export/postgres/pg-test-12 # pg root link
/pg/data -> /export/postgres/pg-test-12/data # real data dir
/pg/backup -> /var/backups/postgres/pg-test-13/backup # base backup
/pg/arcwal -> /var/backups/postgres/pg-test-13/arcwal # WAL archive
/pg/remote -> /var/backups/postgres/pg-test-13/remote # mount NFS/S3 remote resources here
Pgbouncer使用Postgres用户运行，配置文件位于/etc/pgbouncer。配置文件包括：
pgbouncer.ini，主配置文件userlist.txt：列出连接池中的用户pgb_hba.conf：列出连接池用户的访问权限database.txt：列出连接池中的数据库PostgreSQL提供了两类访问控制机制：认证（Authentication） 与 权限（Privileges）
Pigsty附带有基本的访问控制模型，足以覆盖绝大多数应用场景。
Pigsty的默认权限系统包含四个默认用户与四类默认角色，覆盖绝大多数业务场景。
用户可以通过修改配置文件修改默认用户的名字，但默认角色的名字不建议新用户自行修改。
Pigsty带有四个默认角色：
dbrole_readonly）：只读dbrole_readwrite）：读写，继承dbrole_readonlydbrole_admin）：执行DDL变更，继承dbrole_readwritedbrole_offline）：只读，用于执行慢查询/ETL/交互查询，仅允许在特定实例上访问。Pigsty带有四个默认用户：
postgres），数据库的拥有者与创建者，与操作系统用户一致replicator），用于主从复制的用户。dbuser_monitor），用于监控数据库指标的用户。dbuser_admin），执行日常管理操作与数据库变更。| name | attr | roles | desc |
|---|---|---|---|
| dbrole_readonly | Cannot login | role for global readonly access | |
| dbrole_readwrite | Cannot login | dbrole_readonly | role for global read-write access |
| dbrole_offline | Cannot login | role for restricted read-only access (offline instance) | |
| dbrole_admin | Cannot login Bypass RLS |
pg_monitor pg_signal_backend dbrole_readwrite |
role for object creation |
| postgres | Superuser Create role Create DB Replication Bypass RLS |
system superuser | |
| replicator | Replication | pg_monitor dbrole_readonly |
system replicator |
| dbuser_monitor | 16 connections | pg_monitor dbrole_readonly |
system monitor user |
| dbuser_admin | Bypass RLS | dbrole_admin | system admin user |
以下是8个默认用户/角色的相关变量
# - system roles - #
pg_replication_username: replicator # system replication user
pg_replication_password: DBUser.Replicator # system replication password
pg_monitor_username: dbuser_monitor # system monitor user
pg_monitor_password: DBUser.Monitor # system monitor password
pg_admin_username: dbuser_admin # system admin user
pg_admin_password: DBUser.Admin # system admin password
# - default roles - #
# chekc http://pigsty.cc/zh/docs/concepts/provision/acl/ for more detail
pg_default_roles:
# common production readonly user
- name: dbrole_readonly # production read-only roles
login: false
comment: role for global readonly access
# common production read-write user
- name: dbrole_readwrite # production read-write roles
login: false
roles: [dbrole_readonly] # read-write includes read-only access
comment: role for global read-write access
# offline have same privileges as readonly, but with limited hba access on offline instance only
# for the purpose of running slow queries, interactive queries and perform ETL tasks
- name: dbrole_offline
login: false
comment: role for restricted read-only access (offline instance)
# admin have the privileges to issue DDL changes
- name: dbrole_admin
login: false
bypassrls: true
comment: role for object creation
roles: [dbrole_readwrite,pg_monitor,pg_signal_backend]
# dbsu, name is designated by `pg_dbsu`. It's not recommend to set password for dbsu
- name: postgres
superuser: true
comment: system superuser
# default replication user, name is designated by `pg_replication_username`, and password is set by `pg_replication_password`
- name: replicator
replication: true
roles: [pg_monitor, dbrole_readonly]
comment: system replicator
# default replication user, name is designated by `pg_monitor_username`, and password is set by `pg_monitor_password`
- name: dbuser_monitor
connlimit: 16
comment: system monitor user
roles: [pg_monitor, dbrole_readonly]
# default admin user, name is designated by `pg_admin_username`, and password is set by `pg_admin_password`
- name: dbuser_admin
bypassrls: true
comment: system admin user
roles: [dbrole_admin]
# default stats user, for ETL and slow queries
- name: dbuser_stats
password: DBUser.Stats
comment: business offline user for offline queries and ETL
roles: [dbrole_offline]
默认用户有专用的用户名与密码配置选项，会覆盖pg_default_roles中的选项。因此无需在pg_default_roles中为默认用户配置密码。
出于安全考虑，不建议为DBSU配置密码，故pg_dbsu没有专门的密码配置项。如有需要，用户可以在pg_default_roles中为超级用户指定密码。
Pgbouncer的操作系统用户将与数据库超级用户保持一致，默认都使用postgres。
Pigsty默认会使用Postgres管理用户作为Pgbouncer的管理用户，使用Postgres的监控用户同时作为Pgbouncer的监控用户。
Pgbouncer的用户权限通过/etc/pgbouncer/pgb_hba.conf进行控制。
Pgbounce的用户列表通过/etc/pgbouncer/userlist.txt文件进行控制。
定义用户时，只有显式添加pgbouncer: true 的用户，才会被加入到Pgbouncer的用户列表中。
Pigsty中的用户可以通过以下两个参数进行声明，两者使用同样的形式：
pg_default_roles：默认角色与用户pg_users：业务用户Pigsty的用户可以通过 pgsql-createuser.yml 剧本完成创建
默认情况下，角色拥有的权限如下所示
GRANT USAGE ON SCHEMAS TO dbrole_readonly
GRANT SELECT ON TABLES TO dbrole_readonly
GRANT SELECT ON SEQUENCES TO dbrole_readonly
GRANT EXECUTE ON FUNCTIONS TO dbrole_readonly
GRANT USAGE ON SCHEMAS TO dbrole_offline
GRANT SELECT ON TABLES TO dbrole_offline
GRANT SELECT ON SEQUENCES TO dbrole_offline
GRANT EXECUTE ON FUNCTIONS TO dbrole_readonly
GRANT INSERT, UPDATE, DELETE ON TABLES TO dbrole_readwrite
GRANT USAGE, UPDATE ON SEQUENCES TO dbrole_readwrite
GRANT TRUNCATE, REFERENCES, TRIGGER ON TABLES TO dbrole_admin
GRANT CREATE ON SCHEMAS TO dbrole_admin
GRANT USAGE ON TYPES TO dbrole_admin
其他业务用户默认都应当属于四种默认角色之一：只读，读写，管理员，离线访问。
所有用户都可以访问所有模式，只读用户可以读取所有表，读写用户可以对所有表进行DML操作，管理员可以执行DDL变更操作。离线用户与只读用户类似，但只允许访问pg_role == 'offline' 或带有 pg_offline_query = true 的实例。
数据库有三种权限：CONNECT, CREATE, TEMP，以及特殊的属主OWNERSHIP。数据库的定义由参数 pg_database 控制。一个完整的数据库定义如下所示：
pg_databases:
- name: meta # name is the only required field for a database
owner: postgres # optional, database owner
template: template1 # optional, template1 by default
encoding: UTF8 # optional, UTF8 by default
locale: C # optional, C by default
allowconn: true # optional, true by default, false disable connect at all
revokeconn: false # optional, false by default, true revoke connect from public # (only default user and owner have connect privilege on database)
tablespace: pg_default # optional, 'pg_default' is the default tablespace
connlimit: -1 # optional, connection limit, -1 or none disable limit (default)
extensions: # optional, extension name and where to create
- {name: postgis, schema: public}
parameters: # optional, extra parameters with ALTER DATABASE
enable_partitionwise_join: true
pgbouncer: true # optional, add this database to pgbouncer list? true by default
comment: pigsty meta database # optional, comment string for database
默认情况下，如果数据库没有配置属主，那么数据库超级用户dbsu将会作为数据库的默认OWNER，否则将为指定用户。
默认情况下，所有用户都具有对新创建数据库的CONNECT 权限，如果希望回收该权限，设置 revokeconn == true，则该权限会被回收。只有默认用户（dbsu|admin|monitor|replicator）与数据库的属主才会被显式赋予CONNECT权限。同时，admin|owner将会具有CONNECT权限的GRANT OPTION，可以将CONNECT权限转授他人。
如果希望实现不同数据库之间的访问隔离，可以为每一个数据库创建一个相应的业务用户作为owner，并全部设置revokeconn选项。这种配置对于多租户实例尤为实用。
默认情况下，出于安全考虑，Pigsty会撤销PUBLIC用户在数据库下CREATE新模式的权限，同时也会撤销PUBLIC用户在public模式下创建新关系的权限。数据库超级用户与管理员不受此限制，他们总是可以在任何地方执行DDL变更。
Pigsty非常不建议使用业务用户执行DDL变更，因为PostgreSQL的ALTER DEFAULT PRIVILEGE仅针对“由特定用户创建的对象”生效，默认情况下超级用户postgres和dbuser_admin创建的对象拥有默认的权限配置，如果用户希望授予业务用户dbrole_admin，请在使用该业务管理员执行DDL变更时首先执行：
SET ROLE dbrole_admin; -- dbrole_admin 创建的对象具有正确的默认权限
在数据库中创建对象的权限与用户是否为数据库属主无关，这只取决于创建该用户时是否为该用户赋予管理员权限。
pg_users:
- {name: test1, password: xxx , groups: [dbrole_readwrite]} # 不能创建Schema与对象
- {name: test2, password: xxx , groups: [dbrole_admin]} # 可以创建Schema与对象
HBA是Host Based Authentication的缩写，可以将其视作IP黑白名单。
在Pigsty中，所有实例的HBA都由配置文件生成而来，最终生成的HBA规则取决于实例的角色（pg_role）
Pigsty的HBA由下列变量控制：
pg_hba_rules: 环境统一的HBA规则pg_hba_rules_extra: 特定于实例或集群的HBA规则pgbouncer_hba_rules: 链接池使用的HBA规则pgbouncer_hba_rules_extra: 特定于实例或集群的链接池HBA规则每个变量都是由下列样式的规则组成的数组：
- title: allow intranet admin password access
role: common
rules:
- host all +dbrole_admin 10.0.0.0/8 md5
- host all +dbrole_admin 172.16.0.0/12 md5
- host all +dbrole_admin 192.168.0.0/16 md5
role = common的HBA规则组会安装到所有的实例上，而其他的取值，例如（role : primary）则只会安装至pg_role = primary的实例上。因此用户可以通过角色体系定义灵活的HBA规则。
作为一个特例，role: offline 的HBA规则，除了会安装至pg_role == 'offline'的实例，也会安装至pg_offline_query == true的实例上。
在默认配置下，主库与从库会使用以下的HBA规则：
pg_role == 'offline' 或带有pg_offline_query == true的实例上，会添加允许dbrole_offline分组用户访问的HBA规则。#==============================================================#
# Default HBA
#==============================================================#
# allow local su with ident"
local all postgres ident
local replication postgres ident
# allow local user password access
local all all md5
# allow local/intranet replication with password
local replication replicator md5
host replication replicator 127.0.0.1/32 md5
host all replicator 10.0.0.0/8 md5
host all replicator 172.16.0.0/12 md5
host all replicator 192.168.0.0/16 md5
host replication replicator 10.0.0.0/8 md5
host replication replicator 172.16.0.0/12 md5
host replication replicator 192.168.0.0/16 md5
# allow local role monitor with password
local all dbuser_monitor md5
host all dbuser_monitor 127.0.0.1/32 md5
#==============================================================#
# replica HBA
#==============================================================#
#==============================================================#
# special HBA for instance marked with 'pg_offline_query = true'
#==============================================================#
# allow offline query (ETL,SAGA,Interactive) on offline instance
host all +dbrole_offline 10.0.0.0/8 md5
host all +dbrole_offline 172.16.0.0/12 md5
host all +dbrole_offline 192.168.0.0/16 md5
#==============================================================#
# Common HBA
#==============================================================#
# allow meta node password access
host all all 10.10.10.10/32 md5
# allow intranet admin password access
host all +dbrole_admin 10.0.0.0/8 md5
host all +dbrole_admin 172.16.0.0/12 md5
host all +dbrole_admin 192.168.0.0/16 md5
# allow intranet password access
host all all 10.0.0.0/8 md5
host all all 172.16.0.0/12 md5
host all all 192.168.0.0/16 md5
# allow local read/write (local production user via pgbouncer)
local all +dbrole_readonly md5
host all +dbrole_readonly 127.0.0.1/32 md5
#==============================================================#
# Extra HBA
#==============================================================#
# add extra hba rules here
#==============================================================#
# Ad Hoc HBA
#==============================================================#
# manual maintained hba rules
Pigsty提供了专业且易用的PostgreSQL监控系统，浓缩了业界监控的最佳实践。您可以方便地进行修改与定制；复用监控基础设施，或与其他监控系统相集成。下表是每个监控面板介绍页面的快速导航连接。
注：加粗的面板是Pigsty默认提供的监控面板，其他则是专业版提供的额外特性。
默认的监控已经足以覆盖绝大多数场景，如果需要更加深入的掌控与洞察，请联系 商业支持
注：加粗的面板是Pigsty默认提供的监控面板，其他则是专业版提供的额外特性。
默认的监控已经足以覆盖绝大多数场景，如果需要更加深入的掌控与洞察，请联系 商业支持
Home Dashboard是Pigsty的默认主页，包含了到其他系统的导航连接。
您可以在这里发布公告，添加业务系统的导航，集成其他的监控面板等。
PG Overview是总揽整个环境中所有数据库集群的地方。
这里提供了到所有数据库集群与数据库实例的快捷导航，并直观地呈现出整个环境的资源状态，异常事件，系统饱和度等等。
PG Overview的图表主要以集群为基本单位进行呈现，主要用于从全局视角快速定位异常集群。
PG Shard针对水平分片的并行集群而专门设计。
水平分片是Pigsty专业版本提供的高级特性，可以将较大（TB到PB）的业务数据拆分为多个水平的业务集群对外提供服务。
PG Shard提供的指标与PG Overview类似，但会通过预定义的正则表达式筛选出所有同属于一个Shard的所有Cluster。
因此用户可以直观的比较不同分片之间的活动与负载，对于定位数据倾斜问题特别有帮助。
PG Alert是总揽整个环境中所有报警信息的地方。包括所有与报警相关指标的快速面板。
PG KPI 展示了环境中关键指标的概览，您可以在这里快速定位整个环境中的异常指标与异常实例。
PG Capacity 展示了数据库的水位状态，这是Pigsty专业版提供的面板。
PG Change包含了整个环境中所发布的历史DDL变更。
该面板必须与 Pigsty专业版特性： DDL发布系统 共同使用，在此不列出
PG Monitor是监控系统的自我监控，包括Grafana，Prometheus，Consul，Nginx的监控。
自我监控属于Pigsty企业版特性。
PG集群监控是最常用的Dashboard，因为PG以集群为单位提供服务，因此集群层面集合了最完整全面的信息。
大多数监控图都是实例级监控的泛化与上卷，即从展示单个实例内的细节，变为展现集群内每个实例的信息，以及集群和服务层次聚合后的指标。
Cluster级别的集群概览相比实例级别多了一些东西：
PG Cluster 关注单个集群的整体情况，并提供到其他集群信息的导航。
PG集群监控是最常用的Dashboard，因为PG以集群为单位提供服务，因此Cluster集合了最完整全面的信息。
大多数监控图都是实例级监控的泛化与上卷，即从展示单个实例内的细节，变为展现集群内每个实例的信息，以及集群和服务层次聚合后的指标。
Cluster级别的集群概览相比实例级别多了一些东西：
Cluster级别的Dashboard与Instance级别Dashboard最重要的区别之一就是提供了整个集群的复制全景。包括：
集群中的主库与级联桥接库。集群是否启用同步提交，同步从库名称。桥接库与级联库数量，最大从库配置
成对出现的Walsender与Walreceiver列表，体现一对主从关系的复制状态
以秒和字节衡量的复制延迟（通常1秒的复制延迟对应10M~100M不等的字节延迟），复制槽堆积量。
从库视角的复制延迟
集群中从库的数量，备份或拉取从库时可以从这里看到异常。
集群的LSN进度，用于整体展示集群的复制状态与持久化状态。
PG机器的相关指标，按照集群进行聚合。
与实例级别的类似，但添加了Service层次的聚合（一个集群通常提供primary与standby两种Service）。
其他指标与实例级别差别不大。
PG Cluster Replication 关注单个集群内的复制活动。
PG Cluster Activity 关注单个集群的活动，包括事务，查询，锁，等等。
PG Cluster Session 关注特定集群中连接、连接池的工作状态。
PG Cluster Node关注整个集群的机器资源使用情况
PG Cluster Persist 关注集群的持久化，检查点与IO状态。
PG Cluster Activity 关注单个集群的活动，包括事务，查询，锁，等等。
PG Cluster Stat 用于展示集群在过去一段统计周期内的用量信息
PG Cluster Table 关注单个集群中所有表的增删改查情况
PG Cluster Table Detail关注单个集群中某张特定表的增删改查情况
您可以从该面板跳转到
PG Cluster Query 关注特定集群内所有的查询状况
显示慢查询相关的指标，上方是本实例的查询总览。鼠标悬停查询ID可以看到查询语句，点击查询ID会跳转到对应的查询细分指标页（Query Detail）。
PG Cluster Health基于规则对集群进行健康度评分。
PG Cluster Log 关注单个集群内的所有日志事件。
该面板提供了到外部的日志摘要平台的连接，这是一个Pigsty高级特性，仅在企业版中提供。
PG Cluster All 包含了集群中所有的监控信息，用于细节对比与分析。
一个典型的数据库集群提供两种服务
读写服务：主库
只读服务：从库
而服务往往与域名、解析、负载均衡，路由，流量分发紧密相关
服务级监控主要关注以下内容
主从流量分发与权重
后端服务器健康检测
负载均衡器统计信息
PG Service关注数据库角色层次的聚合信息，DNS解析，域名，代理流量权重等。
PG DNS 关注服务域名的解析情况。以及与之绑定的VIP
但是鉴于各个用户定义与管理服务的方式不一，Pigsty不在公开发行版本提供更多关于服务级别的监控面板
实例级监控关注于单个实例，无论是一台机器，一个数据库实例，一个连接池实例，还是负载均衡器，指标导出器，都可以在实例级监控中找到最详细的信息。
PG Instance 详细展示了单个数据库实例的完整指标信息
以最近1日为周期的统计信息（从当前时刻算起的前24小时），比如最近一天的查询总数，返回的记录总数等。上面两行是节点级别的统计，下面两行是主要是PG相关的统计指标。
对于计量计费，水位评估特别有用。
事务部分用于洞悉实例中的活动情况，包括TPS，响应时间，锁等。
TPS概览信息：TPS，TPS与过去两天的DoD环比。DB事务数与回滚数
回滚事务数量与回滚率
TPS详情：绿色条带为±1σ，黄色条带为±3σ，以过去30分钟作为计算标准，通常超出黄色条带可认为TPS波动过大
Xact RT，事务平均响应时间，从连接池抓取。绿色条带为±1σ，黄色条带为±3σ。
TPS与RT的偏离程度，是一个无量纲的可横向比较的值，越大表示指标抖动越厉害。$(μ/σ)^2$
按照DB细分的TPS与事务响应时间，通常一个实例只有一个DB，但少量实例有多个DB。
事务数，回滚数（TPS来自连接池，而这两个指标直接来自DB本身）
锁的数量，按模式聚合（8种表锁），按大类聚合（读锁，写锁，排他锁）
大多数指标与事务中的指标类似，不过统计单位从事务变成了查询语句。查询部分可用于分析实例上的慢查询，定位性能瓶颈。
语句展示了查询中按语句细分的指标。每条语句（查询语法树抽离常量变量后如果一致，则算同一条查询）都会有一个查询ID，可以在慢查询平台中获取到具体的语句与详细指标与统计。
pg_stat_statments中的平均响应时间从大到小排序的，点击查询ID会自动跳转到慢查询平台后端进程用于显示与PG本身的连接，后端进程相关的统计指标。特别是按照各种维度进行聚合的结果，特别适合定位雪崩，慢查询，其他疑难杂症。
连接池部分与后端进程部分类似，但全都是从Pgbouncer中间件上获取的监控指标
Database部分主要来自pg_stat_database与pg_database，包含数据库相关的指标：
持久化主要包含数据落盘，Checkpoint，块访问相关的指标
Exporter展示了监控系统组件本身的监控指标，包括：
Node详细展示了单个机器节点的指标，该面板可用于任何安装有Node Exporter的节点
PG Pgbouncer 详细展示了单个数据库连接池实例的完整指标信息
PG Proxy 详细展示了单个数据库代理 Haproxy 的状态信息
PG Exporter 详细展示了单个数据库实例的监控指标导出器本身的健康状态
PG Setting 详细展示了单个数据库实例的完整指标信息
PG Stat Activity 详细展示了单个数据库实例内的实时活动，注意这里的数据是从Catalog中实时获取，而非监控系统采集。
PG Stat Statements 详细展示了单个数据库实例内实时的查询状态统计
数据库级监控更像是“业务级”监控，它会展现出系统中每一张表，每一个索引，每一个函数的详细使用情况。
对于业务优化与故障分析而言有着巨大的作用。
但是当心监控信息也可能透露出关键的业务数据，例如对用户表的更新QPS可能反映出业务的日活数。请在生产环境中对Grafana做好权限控制，避免不必要的风险。
PG Database 关注单个数据库内发生的详细情况，对于单实例多DB的情况尤其实用。
PG Pool关注连接池中的单个User-DB对，当您使用多租户特性时，这个面板对于连接池问题的排查会很有帮助。
PG Query 关注单个数据库内发生的整体查询细节
您可以用本面板定位出实例内的具体异常查询，然后跳转到PG Query Detail面板查看具体查询的详细信息
PG Catalog可以直接从数据库目录中获取并展示特定表的元数据
请注意，Catalog类型的信息是直接连接至数据库目录进行查询的，可能导致不必要的安全风险。
PG Table关注单个数据库中的所有表，增删改查，访问等。
您可以点击具体的表，跳转至PG Table Detail查阅这张表的详细指标。
PG Table Detail关注单个数据库中的单张表
您可以在本面板中跳转至 PG Cluster Table Detail，来了解这张表在整个集群的不同实例上的工作状态。
PG Query Detail关注单个数据库内发生的单个查询的细节。
请注意，这里的查询都使用QueryID进行标识。 您可以使用PG Stat Statementes面板提供的实时查询接口获取查询对应的语句。 直接在面板中展示SQL语句可能会导致不必要的安全风险，但该特性会在Pigsty专业版中提供。
本章介绍Pigsty的配置部署。如果只希望使用Pigsty的监控系统部分，请参考 仅监控部署 一节。
无论是沙箱环境还是实际生产环境，Pigsty都采用同样的三步走部署流程：准备资源，修改配置，执行剧本
Pigsty采用声明式的接口设计，部署的主要工作在于第二部分 —— 配置修改。
根据实际环境完成配置参数调整后，执行对应的预置剧本，即可将系统调整至期望的状态。
sudo权限。meta）执行infra.yml 剧本pgsql.yml初始化数据库集群pgsql.yml以应用变更pgsql-rm.yml移除数据库集群与实例并回收节点。部署Pigsty前需要做好准备工作，包括：
sudoansiblefiles目录（可选）在部署Pigsty前，需要进行一些重要的技术决策。
在每套环境中，Pigsty最少需要一个元节点，该节点将作为整个环境的控制中心。
元节点负责各种管理工作：保存状态，管理配置，发起任务，收集指标，等等。
整个环境的基础设施组件，Nginx，Grafana，Prometheus，Alertmanager，NTP，DNS Nameserver，DCS都将部署在元节点上。
同时，元节点也将用于部署元数据库 （Consul 或 Etcd），用户也可以使用已有的外部DCS集群。
如果将DCS部署至元节点上，建议在生产环境使用3个元节点，以充分保证DCS服务的可用性。
DCS外的基础设施组件都将以对等副本的方式部署在所有元节点上。
元节点的数量要求最少1个，推荐3个，建议不超过5个。
部署前需要准备一系列机器节点。用户可以使用任意节点：物理机、虚拟机、容器等。
Pigsty推荐使用物理机与虚拟机进行部署。
使用本地沙箱环境时，Pigsty基于Vagrant与Virtualbox快速拉起虚拟机资源，详情请参考 Vagrant教程 。
Pigsty需要一个管理用户，可以从元节点上免密码SSH登陆其他节点，并免密码执行sudo命令。
详情请参考：管理用户
Pigsty提供的基础设施对外提供WebUI以供访问，该Web服务由元节点上的Nginx负责代理。
元节点上的Nginx默认监听80端口，并负责一系列服务的转发。
如果用户希望访问Pigsty提供的图形界面，则需要确保可以直接或间接访问到元节点的80端口。
nginx_upstream:
- { name: home, host: pigsty, url: "127.0.0.1:3000"}
- { name: consul, host: c.pigsty, url: "127.0.0.1:8500" }
- { name: grafana, host: g.pigsty, url: "127.0.0.1:3000" }
- { name: prometheus, host: p.pigsty, url: "127.0.0.1:9090" }
- { name: alertmanager, host: a.pigsty, url: "127.0.0.1:9093" }
- { name: haproxy, host: h.pigsty, url: "127.0.0.1:9091" }
在Pigsty沙箱环境中，用户可以选择从沙箱内的元节点，或沙箱外的宿主机发起控制。在生产环境，用户通常只能从从元节点发起控制
用户需要在发起控制的节点上安装Ansible，Ansible的安装可以通过系统包管理器完成：
yum install ansible # centos
brew install ansible # macos
如果用户的元节点没有互联网访问，可以考虑下载或制作离线安装包，离线安装Ansible 。
Pigsty项目可以通过git直接克隆至本地。
git clone https://github.com/Vonng/pigsty
如果元节点没有互联网访问，用户也可以从Release页面手工下载源代码包 Source code (tar.gz)，通过FTP或其他方式上传至元节点。
在这种情况下，Pigsty强烈推荐一并下载离线安装包，执行离线安装，详情参见 离线安装 。
完成资源准备后，便可以开始 配置 Pigsty
通常为了测试“数据库集群”这样的系统，您需要事先准备若干台虚拟机。尽管云服务已经非常方便，但本地虚拟机访问通常比云虚拟机访问方便，响应迅速，成本低廉。但是，本地虚拟机配置相对繁琐，vagrant 可解决这一问题。
Pigsty用户无需了解vagrant的原理，只需要知道vagrant可以简单、快捷地按照用户的需求，在笔记本、PC或Mac上拉起若干台虚拟机。用户需要完成的工作，就是将自己的虚拟机需求，以vagrant配置文件（Vagrantfile）的形式表达出来。
https://github.com/Vonng/pigsty/blob/master/vagrant/Vagrantfile 提供了一个Vagrantfile样例。
这是Pigsty沙箱所使用的Vagrantfile，定义了四台虚拟机，包括一台2核/4GB的中控机/元节点，和3台 1核/1GB 的数据库节点。
vagrant 二进制程序根据 Vagrantfile 中的定义，默认会调用 Virtualbox 完成本地虚拟机的创建工作。
进入Pigsty根目录下的vagrant目录，执行vagrant up，即可拉起所有的四台虚拟机。
IMAGE_NAME = "centos/7"
N=3 # 数据库机器节点数量，可修改为0
Vagrant.configure("2") do |config|
config.vm.box = IMAGE_NAME
config.vm.box_check_update = false
config.ssh.insert_key = false
# 元节点
config.vm.define "meta", primary: true do |meta| # 元节点默认的ssh别名为`meta`
meta.vm.hostname = "meta"
meta.vm.network "private_network", ip: "10.10.10.10"
meta.vm.provider "virtualbox" do |v|
v.linked_clone = true
v.customize [
"modifyvm", :id,
"--memory", 4096, "--cpus", "2", # 元节点的内存与CPU核数：默认为2核/4GB
"--nictype1", "virtio", "--nictype2", "virtio",
"--hwv·irtex", "on", "--ioapic", "on", "--rtcuseutc", "on", "--vtxvpid", "on", "--largepages", "on"
]
end
meta.vm.provision "shell", path: "provision.sh"
end
# 初始化N个数据库节点
(1..N).each do |i|
config.vm.define "node-#{i}" do |node| # 数据库节点默认的ssh别名分别为`node-{1,2,3}`
node.vm.box = IMAGE_NAME
node.vm.network "private_network", ip: "10.10.10.#{i + 10}"
node.vm.hostname = "node-#{i}"
node.vm.provider "virtualbox" do |v|
v.linked_clone = true
v.customize [
"modifyvm", :id,
"--memory", 2048, "--cpus", "1", # 数据库节点的内存与CPU核数：默认为1核/2GB
"--nictype1", "virtio", "--nictype2", "virtio",
"--hwvirtex", "on", "--ioapic", "on", "--rtcuseutc", "on", "--vtxvpid", "on", "--largepages", "on"
]
end
node.vm.provision "shell", path: "provision.sh"
end
end
end
如果您的笔记本配置不足，可以考虑将N修改为更小的数值，以减少数据库节点的数量。如果您只需要运行单个元节点，将其修改为0即可。
用户还可以修改每台机器的CPU核数和内存资源等，如配置文件中的注释所述。
沙箱环境默认使用IMAGE_NAME = "centos/7"，首次执行时会从vagrant官方下载centos 7.8 virtualbox 镜像，确保您的宿主机拥有合适的网络访问权限（科学上网）！
Pigsty已经提供了对常用vagrant命令的包装，用户可以在项目的Makefile中看到虚拟机管理的相关命令：
make # 启动集群
make new # 销毁并创建新集群
make dns # 将Pigsty域名记录写入本机/etc/hosts （需要sudo权限）
make ssh # 将虚拟机SSH配置信息写入 ~/.ssh/config
make clean # 销毁现有本地集群
make cache # 制作离线安装包，并拷贝至宿主机本地，加速后续集群创建
make upload # 将离线安装缓存包 pkg.tgz 上传并解压至默认目录 /www/pigsty
更多信息，请参考Makefile
###############################################################
# vm management
###############################################################
clean:
cd vagrant && vagrant destroy -f --parallel; exit 0
up:
cd vagrant && vagrant up
halt:
cd vagrant && vagrant halt
down: halt
status:
cd vagrant && vagrant status
suspend:
cd vagrant && vagrant suspend
resume:
cd vagrant && vagrant resume
provision:
cd vagrant && vagrant provision
# sync ntp time
sync:
echo meta node-1 node-2 node-3 | xargs -n1 -P4 -I{} ssh {} 'sudo ntpdate pool.ntp.org'; true
# echo meta node-1 node-2 node-3 | xargs -n1 -P4 -I{} ssh {} 'sudo chronyc -a makestep'; true
# show vagrant cluster status
st: status
start: up ssh sync
stop: halt
# only init partial of cluster
meta-up:
cd vagrant && vagrant up meta
node-up:
cd vagrant && vagrant up node-1 node-2 node-3
node-new:
cd vagrant && vagrant destroy -f node-1 node-2 node-3
cd vagrant && vagrant up node-1 node-2 node-3
Pigsty是一个复杂的软件系统，为了确保系统的稳定，Pigsty会在初始化过程中从互联网下载所有依赖的软件包并建立本地Yum源。
所有依赖的软件总大小约1GB左右，下载速度取决于您的网络情况。尽管Pigsty已经尽量使用镜像源以加速下载，但少量包的下载仍可能受到防火墙的阻挠，可能出现非常慢的情况。您可以通过proxy_env配置项设置下载代理以完成首次下载。
如果您希望跳过漫长的下载过程，或者执行控制的元节点没有互联网访问，则可以考虑下载预先打包好的离线安装包。
为了快速拉起Pigsty，建议使用离线下载软件包并上传的方式完成安装。
离线安装包收纳了本地Yum源的所有软件包。默认情况下，Pigsty会在初始化基础设施时创建本地Yum源，
{{ repo_home }}
|---- {{ repo_name }}.repo
^---- {{ repo_name}}/repo_complete
^---- {{ repo_name}}/**************.rpm
默认情况下，{{ repo_home }} 是Nginx静态文件服务器的根目录，默认为/www，repo_name是自定义的本地源名称，默认为pigsty
以默认情况为例，/www/pigsty 目录包含了所有 RPM 软件包，离线安装包实际上就是 /www/pigsty 目录的压缩包 。
离线安装包的原理是，Pigsty在执行基础设施初始化的过程中，会检查本地Yum源相关文件是否已经存在。如果已经存在，则会跳过下载软件包及其依赖的过程。
检测所用的标记文件为{{ repo_home }}/{{ repo_name }}/repo_complete，默认情况下为/www/pigsty/repo_complete，如果该标记文件存在，（通常是由Pigsty在创建本地源之后设置），则表示本地源已经建立完成，可以直接使用。否则，Pigsty会执行常规的下载逻辑。下载完毕后，您可以将该目录压缩复制归档，用于加速其他环境的初始化。
Pigsty自带了一个沙箱环境，沙箱环境的离线安装包默认放置于files目录中，可以从Github Release页面下载。
cd <pigsty>/files/
wget https://github.com/Vonng/pigsty/releases/download/v0.6.0/pkg.tgz
下载后，如果放置于files目录中，则可以直接使用 Makefile 提供的快捷指令上传离线安装包至元节点上。
使用 Pigsty 沙箱时，可以通过 make cache 制作离线安装包并拷贝到本地。
# cache rpm packages from meta controller
cache:
rm -rf pkg/* && mkdir -p pkg;
ssh -t meta "sudo tar -zcf /tmp/pkg.tgz -C /www pigsty; sudo chmod a+r /tmp/pkg.tgz"
scp -r meta:/tmp/pkg.tgz files/pkg.tgz
ssh -t meta "sudo rm -rf /tmp/pkg.tgz"
同理，使用 make upload，也会将本地的离线安装包（Yum缓存）拷贝至元节点上。
# upload rpm cache to meta controller
upload:
ssh -t meta "sudo rm -rf /tmp/pkg.tgz"
scp -r files/pkg.tgz meta:/tmp/pkg.tgz
ssh -t meta "sudo mkdir -p /www/pigsty/; sudo rm -rf /www/pigsty/*; sudo tar -xf /tmp/pkg.tgz --strip-component=1 -C /www/pigsty/"
使用离线安装包前，您必须确保生产环境的操作系统与制作该安装包的机器操作系统一致。Pigsty提供的离线安装包默认使用CentOS 7.8。
使用不同操作系统版本的离线安装包可能会出错，也可能不会，我们强烈建议不要这么做。
如果您使用了CentOS 7.8以外的操作系统，建议在安装有该版本操作系统，且带有互联网访问的元节点上完成完整的初始化流程（不使用离线安装包），然后使用make cache类似的命令制作符合您的环境操作系统版本的离线安装包。
tar -zcf /tmp/pkg.tgz -C /www pigsty
然后pkg.tgz即可用于其他带有同版本操作系统的生产环境中。
在生产环境使用离线安装包与沙箱环境类似，用户需要将pkg.tgz复制到元节点上，然后将离线安装包解压至目标地址。
这里以默认的 /www/pigsty 为例，将压缩包中的所有内容（RPM包，repo_complete标记文件，repodata 源的元数据库等）解压至目标目录/www/pigsty中，可以使用以下命令。
mkdir -p /www/pigsty/
sudo rm -rf /www/pigsty/*
sudo tar -xf /tmp/pkg.tgz --strip-component=1 -C /www/pigsty/
Pigsty依赖Ansible进行环境初始化。那么就有一个问题，如果元节点本身没有安装Ansible，也没有互联网访问怎么办？
离线安装包本身带有ansible，可以直接通过本地文件Yum源的方式使用，假设您已经将离线安装包解压至/www/pigsty。
将以下Repo文件写入/etc/yum.repos.d/pigsty-local.repo 中，就可以直接使用该源了。
[pigsty-local]
name=Local Yum Repo pigsty
baseurl=file:///www/pigsty
skip_if_unavailable = 1
enabled = 1
priority = 1
gpgcheck = 0
执行以下命令，在元节点上离线安装Ansible
yum clean all
yum makecache
yum install ansible
Pigsty需要一个管理用户，可以从元节点上免密码SSH登陆其他节点，并免密码执行sudo命令。
Pigsty推荐的最佳实践是：将管理用户的创建，权限配置与密钥分发放在虚拟机的Provisioning阶段完成。
沙箱环境的默认用户vagrant默认已经配置有免密登陆和免密sudo，您可以从宿主机或沙箱元节点使用vagrant登陆所有的数据库节点。
对于生产环境来说，即虚拟机交付时，应当已经配置有这样一个具有免密远程SSH登陆并执行免密sudo的用户。
如果没有，则需要用户自行创建。如果用户拥有root权限，也可以用root身份直接执行初始化，Pigsty可以在初始化过程中完成管理用户的创建。相关配置参数包括：
是否在每个节点上创建管理员用户（免密sudo与ssh），默认会创建。
Pigsty默认会创建名为admin (uid=88)的管理用户，可以从元节点上通过SSH免密访问环境中的其他节点并执行免密sudo。
管理员用户的uid，默认为88
管理员用户的名称，默认为admin
是否在当前执行命令的机器之间相互交换管理员用户的SSH密钥？
默认会执行交换，这样管理员可以在机器间快速跳转。
写入到管理员~/.ssh/authorized_keys中的密钥
持有对应私钥的用户可以以管理员身份登陆。
Pigsty默认会创建uid=88的管理员用户admin，并将该用户的密钥在集群范围内进行交换。
node_admin_pks 中给出的公钥会被安装至管理员账户的authorized_keys中，持有对应私钥的用户可以直接远程免密登陆。
在元节点上，假设执行命令的用户名为vagrant。
以vagrant用户的身份执行以下命令，会为vagrant生成公私钥对，用于登陆。
ssh-keygegn
~/.ssh/id_rsa.pub~/.ssh/id_rsa将公钥添加至需要登陆机器的对应用户上：/home/vagrant/.ssh/authorized_keys
如果您已经可以直接通过密码访问远程机器，可以直接通过ssh-copy-id的方式拷贝公钥。
# 输入密码以完成公钥拷贝
ssh-copy-id <ip>
# 直接将密码嵌入命令中，避免交互式密码输入
sshpass -p <password> ssh-copy-id <ip>
然后便可以通过该用户免密码SSH登陆远程机器。
假设用户名为vagrant，则通过visudo 命令，或创建/etc/sudoers.d/vagrant 文件添加以下记录：
%vagrant ALL=(ALL) NOPASSWD: ALL
则 vagrant 用户即可免密sudo执行所有命令
Pigsty采用声明式配置：用户在配置文件中描述系统的状态，供给系统负责将真实环境中的组件调整至期待的状态。
大多数参数针对整体环境进行描述，并不需要修改。对于数据库集群来说，只有三个必选参数：
Pigsty采用遵循Ansible规则的配置文件，默认使用单个YAML文件pigsty.yml进行配置。
但您可以使用任何符合Ansible规则的配置管理方式。详情请参考：拆分配置文件
Pigsty的配置文件默认位于pigsty.yml，配置文件需要与Ansible配合使用。
您可以在当前目录的ansible.cfg中指定默认配置文件路径。或者在命令行执行剧本时通过-i conf/your-config.yml的方式，手工指定自定义配置文件路径。详情请参考 执行剧本 一节。
这里展示了YAML配置文件的顶层结构，一个最外层的all对象，其中all.children定义了环境中的数据库集群，
而all.vars定义了整个环境中的全局配置变量。
---
# top-level namespace, match all hosts
all:
#==================================================================#
# Clusters #
#==================================================================#
# top-level groups, one group per database cluster (and special group 'meta')
children:
#-----------------------------
# meta controller
#-----------------------------
meta: <2 keys>
#-----------------------------
# cluster: pg-meta
#-----------------------------
pg-meta: <2 keys>
#-----------------------------
# cluster: pg-test
#-----------------------------
pg-test: <2 keys>
#==================================================================#
# Globals #
#==================================================================#
vars: <123 keys>
...
下沉至某一个具体的集群，例如all.children.pg-test，则是单个数据库集群的定义部分。
这里hosts中定义了数据库集群的成员，包括序号，角色，以及ansible连接方式（可选）
这里
ansible_host指示ansible通过SSH Alias的方式，而不是IP直连的方式访问连接远程节点，对于需要跳板机代理的机器非常实用。
集群内部的vars中定义的变量会覆盖全局变量，因此您可以有的放矢的针对不同集群进行不同的配置与定制。
#-----------------------------
# cluster: pg-test
#-----------------------------
pg-test: # define cluster named 'pg-test'
# - cluster members - #
hosts:
10.10.10.11: {pg_seq: 1, pg_role: primary, ansible_host: node-1}
10.10.10.12: {pg_seq: 2, pg_role: replica, ansible_host: node-2}
10.10.10.13: {pg_seq: 3, pg_role: replica, ansible_host: node-3}
# - cluster configs - #
vars:
# basic settings
pg_cluster: pg-test # define actual cluster name
pg_version: 13 # define installed pgsql version
node_tune: tiny # tune node into oltp|olap|crit|tiny mode
pg_conf: tiny.yml # tune pgsql into oltp/olap/crit/tiny mode
pg_users:
- username: test
password: test
comment: default test user
groups: [ dbrole_readwrite ] # dborole_admin|dbrole_readwrite|dbrole_readonly
pg_databases: # create a business database 'test'
- name: test
extensions: [{name: postgis}] # create extra extension postgis
parameters: # overwrite database meta's default search_path
search_path: public,monitor
pg_default_database: test # default database will be used as primary monitor target
# proxy settings
vip_enabled: true # enable/disable vip (require members in same LAN)
vip_address: 10.10.10.3 # virtual ip address
vip_cidrmask: 8 # cidr network mask length
vip_interface: eth1 # interface to add virtual ip
Pigsty中的变量遵循Ansible的合并规则，所有变量最后会按优先级顺序覆盖式合并，最终压平到主机层次。参见Ansible变量优先级
- command line values (for example,
-u my_user, these are not variables)- role defaults (defined in role/defaults/main.yml) 1
- inventory file or script group vars 2
- inventory group_vars/all 3
- playbook group_vars/all 3
- inventory group_vars/* 3
- playbook group_vars/* 3
- inventory file or script host vars 2
- inventory host_vars/* 3
- playbook host_vars/* 3
- host facts / cached set_facts 4
- play vars
- play vars_prompt
- play vars_files
- role vars (defined in role/vars/main.yml)
- block vars (only for tasks in block)
- task vars (only for the task)
- include_vars
- set_facts / registered vars
- role (and include_role) params
- include params
- extra vars (for example,
-e "user=my_user")(always win precedence)
配置文件中的变量只有三个层级：
group_vars/all
全局变量，定义于all.vars
设置整个环境统一的参数（如基础设施信息），优先级最低。
group_vars/*
集群变量，定义于all.children.<cluster-name>.vars中
用于设置某个集群的特定配置，如集群名称。
host_vars/*
实例变量，定义于all.children.<cluster-name>.hosts.<host-name>
用于设置特定实例的配置，如实例标号。
您可以在执行剧本时，通过-e的命令行参数覆盖配置文件中的选项，例如：
./initdb.yml -e pg_exists_action=clean
这里-e pg_exists_action=clean就会覆盖配置文件中的选项，在初始化的过程中强制抹除已经存在的数据库实例（危险）。
Pigsty带有很多配置项变量，分为10个部分
详细列表如下：
#------------------------------------------------------------------------------
# CONNECTION PARAMETERS
#------------------------------------------------------------------------------
proxy_env
#------------------------------------------------------------------------------
# REPO PROVISION
#------------------------------------------------------------------------------
repo_enabled
repo_name
repo_address
repo_port
repo_home
repo_rebuild
repo_remove
repo_upstreams
repo_packages
repo_url_packages
#------------------------------------------------------------------------------
# NODE PROVISION
#------------------------------------------------------------------------------
node_dns_hosts
node_dns_server
node_dns_servers
node_dns_options
node_repo_method
node_repo_remove
node_local_repo_url
node_packages
node_extra_packages
node_meta_packages
node_disable_numa
node_disable_swap
node_disable_firewall
node_disable_selinux
node_static_network
node_disk_prefetch
node_kernel_modules
node_tune
node_sysctl_params
node_admin_setup
node_admin_uid
node_admin_username
node_admin_ssh_exchange
node_admin_pks
node_ntp_service
node_ntp_config
node_timezone
node_ntp_servers
#------------------------------------------------------------------------------
# META PROVISION
#------------------------------------------------------------------------------
ca_method
ca_subject
ca_homedir
ca_cert
ca_key
nginx_upstream
dns_records
prometheus_data_dir
prometheus_options
prometheus_reload
prometheus_sd_method
prometheus_scrape_interval
prometheus_scrape_timeout
prometheus_sd_interval
grafana_url
grafana_admin_password
grafana_plugin
grafana_cache
grafana_customize
grafana_plugins
grafana_git_plugins
#------------------------------------------------------------------------------
# DCS PROVISION
#------------------------------------------------------------------------------
service_registry
dcs_type
dcs_name
dcs_servers
dcs_exists_action
dcs_disable_purge
consul_data_dir
etcd_data_dir
#------------------------------------------------------------------------------
# POSTGRES INSTALLATION
#------------------------------------------------------------------------------
pg_dbsu
pg_dbsu_uid
pg_dbsu_sudo
pg_dbsu_home
pg_dbsu_ssh_exchange
pg_version
pgdg_repo
pg_add_repo
pg_bin_dir
pg_packages
pg_extensions
#------------------------------------------------------------------------------
# POSTGRES PROVISION
#------------------------------------------------------------------------------
pg_cluster
pg_seq
pg_role
pg_hostname
pg_nodename
pg_exists
pg_exists_action
pg_data
pg_fs_main
pg_fs_bkup
pg_listen
pg_port
pg_localhost
patroni_mode
pg_namespace
patroni_port
patroni_watchdog_mode
pg_conf
pgbouncer_port
pgbouncer_poolmode
pgbouncer_max_db_conn
#------------------------------------------------------------------------------
# POSTGRES TEMPLATE
#------------------------------------------------------------------------------
pg_init
pg_replication_username
pg_replication_password
pg_monitor_username
pg_monitor_password
pg_admin_username
pg_admin_password
pg_default_roles
pg_default_privilegs
pg_default_schemas
pg_default_extensions
pg_offline_query
pg_hba_rules
pg_hba_rules_extra
pgbouncer_hba_rules
pgbouncer_hba_rules_extra
#------------------------------------------------------------------------------
# MONITOR PROVISION
#------------------------------------------------------------------------------
exporter_metrics_path
exporter_binary_install
node_exporter_enabled
node_exporter_port
pg_exporter_config
pg_exporter_enabled
pgbouncer_exporter_enabled
pg_exporter_port
pgbouncer_exporter_port
#------------------------------------------------------------------------------
# PROXY PROVISION
#------------------------------------------------------------------------------
haproxy_enabled
haproxy_policy
haproxy_admin_auth_enabled
haproxy_admin_username
haproxy_admin_password
haproxy_client_timeout
haproxy_server_timeout
haproxy_exporter_port
haproxy_check_port
haproxy_primary_port
haproxy_replica_port
haproxy_backend_port
haproxy_weight
haproxy_weight_fallback
vip_enabled
vip_address
vip_cidrmask
vip_interface
Pigsty采用遵循Ansible规则的配置文件，默认使用单个YAML文件 pigsty.yml进行配置。
用户可以使用任何符合Ansible规则的配置管理方式。详情请参考：拆分单一配置文件。
建议在调整配置组织方式前，首先熟悉Ansible的Inventory组织模式。
一种典型的配置拆分方式是，按照数据库集群进行拆分。即，每一个数据库集群的定义有一个单独的配置清单。
这样做的好处是如果发生误操作，影响范围会局限在这个集群中。
试想一下如果有用户绕过重重阻挠执行数据库清除操作，本想清理一个集群，结果把整个生产环境的所有数据库都抹掉了，这肯定令人无法接受。
在这种要求下，我们会将全局变量与集群定义相剥离。
group_vars/all.yml 包含所有全局变量部分pgsql/<cluster>.yml包含<cluster>数据库集群的定义那么使用时，您必须通过-i pgsql/<cluster>.yml 显式指明需要操作的集群。而不再是使用-l <cluster>筛选目标集群。
以Pigsty沙箱配置文件为例：
pigsty
|
^- group_vars # group variables definition
| ^------ all.yml # global variablies
|
^- pgsql
^------ meta.yml # meta node definition
^------ pg-meta.yml # pg-meta database cluster definition
^------ pg-test.yml # pg-test database cluster definition
^------ <cluster>.yml # <cluster> database cluster definition
group_vars/all.yml 包含了原pigsty.yml 中all.vars中对应的内容，形如：
#!/usr/bin/env ansible-playbook
---
#==============================================================#
# File : group_vars/all.yml
# Ctime : 2020-11-24
# Mtime : 2021-02-22
# Desc : PostgreSQL Inventory Global Vars
# Path : group_vars/all.yml
# Maintainer : Ruohang Feng
# Copyright (C) 2019-2021 Ruohang Feng
#==============================================================#
#-----------------------------
# CONNECTION PARAMETERS
#-----------------------------
# ansible_user: admin # admin user with ssh access and sudo privilege
# proxy_env: {}
proxy_env: # global proxy env when downloadinidg packages
no_proxy: "localhost,127.0.0.1,10.0.0.0/8,192.168.0.0/16,*.pigsty,*.aliyun.com"
#-----------------------------
# REPO PROVISION
#-----------------------------
# this section defines how to build a local repo
repo_enabled: true # build local yum repo on meta nodes?
repo_name: pgsql-el7 # local repo name
...
注意这里所有的全局变量都是顶层键值。
每一个集群都使用独立的清单文件定义。
即，原本pigsty.yml中all.children中的每一个配置项（集群定义），都被单独拆分为位于pgsql/<cluster_name>.yml中的一个文件。文件的内容都是all.children.<cluster>对应的配置项，但需要保留顶层的all.children结构。
例如，pg-test集群的分立定义文件如下所示：
all:
children:
pg-test:
# - cluster members - #
hosts:
10.10.10.11: {pg_seq: 1, pg_role: primary, ansible_host: node-1}
10.10.10.12: {pg_seq: 2, pg_role: replica, ansible_host: node-2}
10.10.10.13: {pg_seq: 3, pg_role: replica, ansible_host: node-3, pg_offline_query: true}
# - cluster configs - #
vars:
# basic settings
pg_cluster: pg-test # define actual cluster name
pg_version: 13 # define installed pgsql version
node_tune: tiny # tune node into oltp|olap|crit|tiny mode
pg_conf: tiny.yml # tune pgsql into oltp/olap/crit/tiny mode
# business users, adjust on your own needs
pg_users:
- name: test # example production user have read-write access
password: test # example user's password
roles: [dbrole_readwrite] # dborole_admin|dbrole_readwrite|dbrole_readonly|dbrole_offline
pgbouncer: true # production user that access via pgbouncer
comment: default test user for production usage
pg_databases: # create a business database 'test'
- name: test # use the simplest form
pg_default_database: test # default database will be used as primary monitor target
# proxy settings
vip_enabled: true # enable/disable vip (require members in same LAN)
vip_address: 10.10.10.3 # virtual ip address
vip_cidrmask: 8 # cidr network mask length
vip_interface: eth1 # interface to add virtual ip
进行拆分后，执行剧本时需要显式指定需要操作的集群。如：
./pgsql -i pgsql/pg-test.yml
一些基于完整全量Inventory的功能，目前仍然需要完整的全量Inventory，例如，生成所有Haproxy实例的导航界面。
如果用户使用拆分式配置文件，生成的页面只包含该集群内的实例成员。这一问题将在后续版本中解决
#------------------------------------------------------------------------------
# CONNECTION PARAMETERS
#------------------------------------------------------------------------------
proxy_env
ansible_host
在某些受到“互联网封锁”的地区，有些软件的下载会受到影响。
例如，从中国大陆访问PostgreSQL的官方源，下载速度可能只有几KB每秒。但如果使用了合适的HTTP代理，则可以达到几MB每秒。
因此如果用户有代理服务器，请通过proxy_env进行配置，样例如下：
proxy_env: # global proxy env when downloading packages
http_proxy: 'http://username:password@proxy.address.com'
https_proxy: 'http://username:password@proxy.address.com'
all_proxy: 'http://username:password@proxy.address.com'
no_proxy: "localhost,127.0.0.1,10.0.0.0/8,192.168.0.0/16,*.pigsty,*.aliyun.com"
如果用户的环境使用了跳板机，或者进行了某些定制化修改，无法通过简单的ssh <ip>方式访问，那么可以考虑使用Ansible的连接参数。ansible_host是ansiblel连接参数中最典型的一个。
ansible_host
The name of the host to connect to, if different from the alias you wish to give to it.
ansible_port
The ssh port number, if not 22
ansible_user
The default ssh user name to use.
ansible_ssh_pass
The ssh password to use (never store this variable in plain text; always use a vault. See Variables and Vaults)
ansible_ssh_private_key_file
Private key file used by ssh. Useful if using multiple keys and you don’t want to use SSH agent.
ansible_ssh_common_args
This setting is always appended to the default command line for sftp, scp, and ssh. Useful to configure a
ProxyCommandfor a certain host (or group).ansible_sftp_extra_args
This setting is always appended to the default sftp command line.
ansible_scp_extra_args
This setting is always appended to the default scp command line.
ansible_ssh_extra_args
This setting is always appended to the default ssh command line.
ansible_ssh_pipelining
Determines whether or not to use SSH pipelining. This can override the
pipeliningsetting inansible.cfg.
最简单的用法是将ssh alias配置为ansible_host，只要您可以通过ssh <name>的方式访问目标机器，那么将ansible_host配置为<name>即可。注意这些变量都是实例级别的变量。
请注意，沙箱环境的默认配置使用了 SSH 别名 作为连接参数，这是因为vagrant宿主机访问虚拟机时使用了SSH别名配置。
对于生产环境，建议直接使用IP连接。
pg-meta:
hosts:
10.10.10.10: {pg_seq: 1, pg_role: primary, ansible_host: meta}
Pigsty是一个复杂的软件系统，为了确保系统的稳定，Pigsty会在初始化过程中从互联网下载所有依赖的软件包并建立本地Yum源。
所有依赖的软件总大小约1GB左右，下载速度取决于您的网络情况。尽管Pigsty已经尽量使用镜像源以加速下载，但少量包的下载仍可能受到防火墙的阻挠，可能出现非常慢的情况。您可以通过proxy_env配置项设置下载代理以完成首次下载，或直接下载预先打包好的离线安装包。
建立本地Yum源时，如果{{ repo_home }}/{{ repo_name }}目录已经存在，而且里面有repo_complete的标记文件，Pigsty会认为本地Yum源已经初始化完毕，因此跳过软件下载阶段，显著加快速度。离线安装包即是把{{ repo_home }}/{{ repo_name }}目录整个打成压缩包。
repo_enabled: true # 是否启用本地源功能
repo_name: pigsty # 本地源名称
repo_address: yum.pigsty # 外部可访问的源地址 (ip:port 或 url)
repo_port: 80 # 源HTTP服务器监听地址
repo_home: /www # 默认根目录
repo_rebuild: false # 强制重新下载软件包
repo_remove: true # 移除已有的yum源
repo_upstreams: [...] # 上游Yum源
repo_packages: [...] # 需要下载的软件包
repo_url_packages: [...] # 通过URL下载的软件
如果为true（默认情况），执行正常的本地yum源创建流程，否则跳过构建本地yum源的操作。
本地yum源的名称，默认为pigsty，您可以改为自己喜欢的名称，例如pgsql-rhel7等。
本地yum源对外提供服务的地址，可以是域名也可以是IP地址，默认为yum.pigsty。
如果使用域名，您必须确保在当前环境中该域名会解析到本地源所在的服务器，也就是元节点。
如果您的本地yum源没有使用标准的80端口，您需要在地址中加入端口，并与repo_port变量保持一致。
您可以通过节点参数中的静态DNS配置来为环境中的所有节点写入Pigsty本地源的域名，沙箱环境中即是采用这种方式来解析默认的yum.pigsty域名。
本地yum源使用的HTTP端口，默认为80端口。
本地yum源的根目录，默认为www。
该目录将作为HTTP服务器的根对外暴露。
如果为false（默认情况），什么都不发生，如果为true，那么在任何情况下都会执行Repo重建的工作。
在执行本地源初始化的过程中，是否移除/etc/yum.repos.d中所有已有的repo？默认为true。
原有repo文件会备份至/etc/yum.repos.d/backup中。
因为操作系统已有的源内容不可控，建议强制移除并通过repo_upstreams进行显式配置。
所有添加到/etc/yum.repos.d中的Yum源，Pigsty将从这些源中下载软件。
Pigsty默认使用阿里云的CentOS7镜像源，清华大学Grafana镜像源，PackageCloud的Prometheus源，PostgreSQL官方源，以及SCLo，Harbottle，Nginx, Haproxy等软件源。
- name: base
description: CentOS-$releasever - Base - Aliyun Mirror
baseurl:
- http://mirrors.aliyun.com/centos/$releasever/os/$basearch/
- http://mirrors.aliyuncs.com/centos/$releasever/os/$basearch/
- http://mirrors.cloud.aliyuncs.com/centos/$releasever/os/$basearch/
gpgcheck: no
failovermethod: priority
- name: updates
description: CentOS-$releasever - Updates - Aliyun Mirror
baseurl:
- http://mirrors.aliyun.com/centos/$releasever/updates/$basearch/
- http://mirrors.aliyuncs.com/centos/$releasever/updates/$basearch/
- http://mirrors.cloud.aliyuncs.com/centos/$releasever/updates/$basearch/
gpgcheck: no
failovermethod: priority
- name: extras
description: CentOS-$releasever - Extras - Aliyun Mirror
baseurl:
- http://mirrors.aliyun.com/centos/$releasever/extras/$basearch/
- http://mirrors.aliyuncs.com/centos/$releasever/extras/$basearch/
- http://mirrors.cloud.aliyuncs.com/centos/$releasever/extras/$basearch/
gpgcheck: no
failovermethod: priority
- name: epel
description: CentOS $releasever - EPEL - Aliyun Mirror
baseurl: http://mirrors.aliyun.com/epel/$releasever/$basearch
gpgcheck: no
failovermethod: priority
- name: grafana
description: Grafana - TsingHua Mirror
gpgcheck: no
baseurl: https://mirrors.tuna.tsinghua.edu.cn/grafana/yum/rpm
- name: prometheus
description: Prometheus and exporters
gpgcheck: no
baseurl: https://packagecloud.io/prometheus-rpm/release/el/$releasever/$basearch
- name: pgdg-common
description: PostgreSQL common RPMs for RHEL/CentOS $releasever - $basearch
gpgcheck: no
baseurl: https://download.postgresql.org/pub/repos/yum/common/redhat/rhel-$releasever-$basearch
- name: pgdg13
description: PostgreSQL 13 for RHEL/CentOS $releasever - $basearch - Updates testing
gpgcheck: no
baseurl: https://download.postgresql.org/pub/repos/yum/13/redhat/rhel-$releasever-$basearch
- name: centos-sclo
description: CentOS-$releasever - SCLo
gpgcheck: no
mirrorlist: http://mirrorlist.centos.org?arch=$basearch&release=7&repo=sclo-sclo
- name: centos-sclo-rh
description: CentOS-$releasever - SCLo rh
gpgcheck: no
mirrorlist: http://mirrorlist.centos.org?arch=$basearch&release=7&repo=sclo-rh
- name: nginx
description: Nginx Official Yum Repo
skip_if_unavailable: true
gpgcheck: no
baseurl: http://nginx.org/packages/centos/$releasever/$basearch/
- name: haproxy
description: Copr repo for haproxy
skip_if_unavailable: true
gpgcheck: no
baseurl: https://download.copr.fedorainfracloud.org/results/roidelapluie/haproxy/epel-$releasever-$basearch/
# for latest consul & kubernetes
- name: harbottle
description: Copr repo for main owned by harbottle
skip_if_unavailable: true
gpgcheck: no
baseurl: https://download.copr.fedorainfracloud.org/results/harbottle/main/epel-$releasever-$basearch/
需要下载的rpm安装包列表，默认下载的软件包如下所示：
# - what to download - #
repo_packages:
# repo bootstrap packages
- epel-release nginx wget yum-utils yum createrepo # bootstrap packages
# node basic packages
- ntp chrony uuid lz4 nc pv jq vim-enhanced make patch bash lsof wget unzip git tuned # basic system util
- readline zlib openssl libyaml libxml2 libxslt perl-ExtUtils-Embed ca-certificates # basic pg dependency
- numactl grubby sysstat dstat iotop bind-utils net-tools tcpdump socat ipvsadm telnet # system utils
# dcs & monitor packages
- grafana prometheus2 pushgateway alertmanager # monitor and ui
- node_exporter postgres_exporter nginx_exporter blackbox_exporter # exporter
- consul consul_exporter consul-template etcd # dcs
# python3 dependencies
- ansible python python-pip python-psycopg2 # ansible & python
- python3 python3-psycopg2 python36-requests python3-etcd python3-consul # python3
- python36-urllib3 python36-idna python36-pyOpenSSL python36-cryptography # python3 patroni extra deps
# proxy and load balancer
- haproxy keepalived dnsmasq # proxy and dns
# postgres common Packages
- patroni patroni-consul patroni-etcd pgbouncer pg_cli pgbadger pg_activity # major components
- pgcenter boxinfo check_postgres emaj pgbconsole pg_bloat_check pgquarrel # other common utils
- barman barman-cli pgloader pgFormatter pitrery pspg pgxnclient PyGreSQL pgadmin4 tail_n_mail
# postgres 13 packages
- postgresql13* postgis31* citus_13 pgrouting_13 # postgres 13 and postgis 31
- pg_repack13 pg_squeeze13 # maintenance extensions
- pg_qualstats13 pg_stat_kcache13 system_stats_13 bgw_replstatus13 # stats extensions
- plr13 plsh13 plpgsql_check_13 plproxy13 plr13 plsh13 plpgsql_check_13 pldebugger13 # PL extensions # pl extensions
- hdfs_fdw_13 mongo_fdw13 mysql_fdw_13 ogr_fdw13 redis_fdw_13 pgbouncer_fdw13 # FDW extensions
- wal2json13 count_distinct13 ddlx_13 geoip13 orafce13 # MISC extensions
- rum_13 hypopg_13 ip4r13 jsquery_13 logerrors_13 periods_13 pg_auto_failover_13 pg_catcheck13
- pg_fkpart13 pg_jobmon13 pg_partman13 pg_prioritize_13 pg_track_settings13 pgaudit15_13
- pgcryptokey13 pgexportdoc13 pgimportdoc13 pgmemcache-13 pgmp13 pgq-13
- pguint13 pguri13 prefix13 safeupdate_13 semver13 table_version13 tdigest13
采用URL直接下载，而非yum下载的软件包。您可以将自定义的软件包连接添加到这里。
Pigsty默认会通过URL下载三款软件：
pg_exporter（必须，监控系统核心组件）vip-manager（可选，启用VIP时必须）polysh（可选，多机管理便捷工具）repo_url_packages:
- https://github.com/Vonng/pg_exporter/releases/download/v0.3.1/pg_exporter-0.3.1-1.el7.x86_64.rpm
- https://github.com/cybertec-postgresql/vip-manager/releases/download/v0.6/vip-manager_0.6-1_amd64.rpm
- http://guichaz.free.fr/polysh/files/polysh-0.4-1.noarch.rpm
Pigsty中关于机器与操作系统、基础设施的配置参数
#------------------------------------------------------------------------------
# NODE PROVISION
#------------------------------------------------------------------------------
node_dns_hosts
node_dns_server
node_dns_servers
node_dns_options
node_repo_method
node_repo_remove
node_local_repo_url
node_packages
node_extra_packages
node_meta_packages
node_disable_numa
node_disable_swap
node_disable_firewall
node_disable_selinux
node_static_network
node_disk_prefetch
node_kernel_modules
node_tune
node_sysctl_params
node_admin_setup
node_admin_uid
node_admin_username
node_admin_ssh_exchange
node_admin_pks
node_ntp_service
node_ntp_config
node_timezone
node_ntp_servers
#------------------------------------------------------------------------------
# NODE PROVISION
#------------------------------------------------------------------------------
# this section defines how to provision nodes
# - node dns - #
node_dns_hosts: # static dns records in /etc/hosts
- 10.10.10.10 yum.pigsty
node_dns_server: add # add (default) | none (skip) | overwrite (remove old settings)
node_dns_servers: # dynamic nameserver in /etc/resolv.conf
- 10.10.10.10
node_dns_options: # dns resolv options
- options single-request-reopen timeout:1 rotate
- domain service.consul
# - node repo - #
node_repo_method: local # none|local|public (use local repo for production env)
node_repo_remove: true # whether remove existing repo
# local repo url (if method=local, make sure firewall is configured or disabled)
node_local_repo_url:
- http://yum.pigsty/pigsty.repo
# - node packages - #
node_packages: # common packages for all nodes
- wget,yum-utils,ntp,chrony,tuned,uuid,lz4,vim-minimal,make,patch,bash,lsof,wget,unzip,git,readline,zlib,openssl
- numactl,grubby,sysstat,dstat,iotop,bind-utils,net-tools,tcpdump,socat,ipvsadm,telnet,tuned,pv,jq
- python3,python3-psycopg2,python36-requests,python3-etcd,python3-consul
- python36-urllib3,python36-idna,python36-pyOpenSSL,python36-cryptography
- node_exporter,consul,consul-template,etcd,haproxy,keepalived,vip-manager
node_extra_packages: # extra packages for all nodes
- patroni,patroni-consul,patroni-etcd,pgbouncer,pgbadger,pg_activity
node_meta_packages: # packages for meta nodes only
- grafana,prometheus2,alertmanager,nginx_exporter,blackbox_exporter,pushgateway
- dnsmasq,nginx,ansible,pgbadger,polysh
# - node features - #
node_disable_numa: false # disable numa, important for production database, reboot required
node_disable_swap: false # disable swap, important for production database
node_disable_firewall: true # disable firewall (required if using kubernetes)
node_disable_selinux: true # disable selinux (required if using kubernetes)
node_static_network: true # keep dns resolver settings after reboot
node_disk_prefetch: false # setup disk prefetch on HDD to increase performance
# - node kernel modules - #
node_kernel_modules:
- softdog
- br_netfilter
- ip_vs
- ip_vs_rr
- ip_vs_rr
- ip_vs_wrr
- ip_vs_sh
- nf_conntrack_ipv4
# - node tuned - #
node_tune: tiny # install and activate tuned profile: none|oltp|olap|crit|tiny
node_sysctl_params: # set additional sysctl parameters, k:v format
net.bridge.bridge-nf-call-iptables: 1 # for kubernetes
# - node user - #
node_admin_setup: true # setup an default admin user ?
node_admin_uid: 88 # uid and gid for admin user
node_admin_username: admin # default admin user
node_admin_ssh_exchange: true # exchange ssh key among cluster ?
node_admin_pks: # public key list that will be installed
- 'ssh-rsa AAAAB3NzaC1yc2EAAAADAQABAAAAgQC7IMAMNavYtWwzAJajKqwdn3ar5BhvcwCnBTxxEkXhGlCO2vfgosSAQMEflfgvkiI5nM1HIFQ8KINlx1XLO7SdL5KdInG5LIJjAFh0pujS4kNCT9a5IGvSq1BrzGqhbEcwWYdju1ZPYBcJm/MG+JD0dYCh8vfrYB/cYMD0SOmNkQ== vagrant@pigsty.com'
# - node ntp - #
node_ntp_service: ntp # ntp or chrony
node_ntp_config: true # overwrite existing ntp config?
node_timezone: Asia/Shanghai # default node timezone
node_ntp_servers: # default NTP servers
- pool cn.pool.ntp.org iburst
- pool pool.ntp.org iburst
- pool time.pool.aliyun.com iburst
- server 10.10.10.10 iburst
机器节点的默认静态DNS解析记录，每一条记录都会在机器节点初始化时写入/etc/hosts中，特别适合用于配置基础设施地址。
node_dns_hosts是一个数组，每一个元素都是形如ip domain_name的字符串，代表一条DNS解析记录。
默认情况下，Pigsty会向/etc/hosts中写入10.10.10.10 yum.pigsty，这样可以在DNS Nameserver启动之前，采用域名的方式访问本地yum源。
机器节点默认的动态DNS服务器的配置方式，有三种模式：
add：将node_dns_servers中的记录追加至/etc/resolv.conf，并保留已有DNS服务器。（默认）overwrite：使用将node_dns_servers中的记录覆盖/etc/resolv.confnone：跳过DNS服务器配置如果node_dns_server配置为add或overwrite，则node_dns_servers中的记录会被追加或覆盖至/etc/resolv.conf中。具体格式请参考Linux文档关于/etc/resolv.conf的说明。
Pigsty默认会添加元节点作为DNS Server，元节点上的DNSMASQ会响应环境中的DNS请求。
node_dns_servers: # dynamic nameserver in /etc/resolv.conf
- 10.10.10.10
如果node_dns_server配置为add或overwrite，则node_dns_options中的记录会被追加或覆盖至/etc/resolv.conf中。具体格式请参考Linux文档关于/etc/resolv.conf的说明
Pigsty默认添加的解析选项为：
- options single-request-reopen timeout:1 rotate
- domain service.consul
机器节点Yum软件源的配置方式，有三种模式：
local：使用元节点上的本地Yum源，默认行为，推荐。public：直接使用互联网源安装，将repo_upstream中的公共repo写入/etc/yum.repos.d/none：不对本地源进行配置与修改。原有Yum源的处理方式，是否移除节点上原有的Yum源？
Pigsty默认会移除/etc/yum.repos.d中原有的配置文件，并备份至/etc/yum.repos.d/backup
如果node_repo_method配置为local，则这里列出的Repo文件URL会被下载至/etc/yum.repos.d中
这里是一个Repo File URL 构成的数组，Pigsty默认会将元节点上的本地Yum源加入机器的源配置中。
node_local_repo_url:
- http://yum.pigsty/pigsty.repo
通过yum安装的软件包列表。
软件包列表为数组，但每个元素可以包含由逗号分隔的多个软件包，Pigsty默认安装的软件包列表如下：
node_packages: # common packages for all nodes
- wget,yum-utils,ntp,chrony,tuned,uuid,lz4,vim-minimal,make,patch,bash,lsof,wget,unzip,git,readline,zlib,openssl
- numactl,grubby,sysstat,dstat,iotop,bind-utils,net-tools,tcpdump,socat,ipvsadm,telnet,tuned,pv,jq
- python3,python3-psycopg2,python36-requests,python3-etcd,python3-consul
- python36-urllib3,python36-idna,python36-pyOpenSSL,python36-cryptography
- node_exporter,consul,consul-template,etcd,haproxy,keepalived,vip-manager
通过yum安装的额外软件包列表。
与node_packages类似，但node_packages通常是全局统一配置，而node_extra_packages则是针对具体节点进行例外处理。例如，您可以为运行PG的节点安装额外的工具包。该变量通常在集群和实例级别进行覆盖定义。
Pigsty默认安装的额外软件包列表如下：
- patroni,patroni-consul,patroni-etcd,pgbouncer,pgbadger,pg_activity
通过yum安装的元节点软件包列表。
与node_packages和node_extra_packages类似，但node_meta_packages中列出的软件包只会在元节点上安装。因此通常都是监控软件，管理工具，构建工具等。
Pigsty默认安装的元节点软件包列表如下：
node_meta_packages: # packages for meta nodes only
- grafana,prometheus2,alertmanager,nginx_exporter,blackbox_exporter,pushgateway
- dnsmasq,nginx,ansible,pgbadger,polysh
是否关闭Numa，注意，该选项需要重启后生效！默认不关闭，但生产环境强烈建议关闭NUMA。
是否禁用SWAP，如果您有足够的内存，且数据库采用独占式部署，建议直接关闭SWAP提高性能，默认关闭。
是否关闭防火墙，这个东西非常讨厌，建议关闭，默认关闭。
是否关闭SELinux，这个东西非常讨厌，建议关闭，默认关闭。
是否采用静态网络配置，默认启用
启用静态网络，意味着您的DNS Resolv配置不会因为机器重启与网卡变动被覆盖。建议启用。
是否启用磁盘预读？
针对HDD部署的实例可以优化吞吐量，默认关闭。
需要安装的内核模块
Pigsty默认会启用以下内核模块
node_kernel_modules: [softdog, ip_vs, ip_vs_rr, ip_vs_rr, ip_vs_wrr, ip_vs_sh]
针对机器进行调优的预制方案
修改sysctl系统参数
字典KV结构
是否在每个节点上创建管理员用户（免密sudo与ssh），默认会创建。
Pigsty默认会创建名为admin (uid=88)的管理用户，可以从元节点上通过SSH免密访问环境中的其他节点并执行免密sudo。
管理员用户的uid，默认为88
管理员用户的名称，默认为admin
是否在当前执行命令的机器之间相互交换管理员用户的SSH密钥？
默认会执行交换，这样管理员可以在机器间快速跳转。
写入到管理员~/.ssh/authorized_keys中的密钥
持有对应私钥的用户可以以管理员身份登陆。
指明系统使用的NTP服务类型：
ntp：传统NTP服务chrony：CentOS 7/8默认使用的时间服务是否覆盖现有NTP配置？
布尔选项，默认覆盖。
默认使用的时区
Pigsty默认使用Asia/Shanghai，请根据您的实际情况调整。
NTP服务器地址
Pigsty默认会使用以下NTP服务器
- pool cn.pool.ntp.org iburst
- pool pool.ntp.org iburst
- pool time.pool.aliyun.com iburst
- server 10.10.10.10 iburst
元节点参数定义了部署于元节点上的基础设施，包括：
#------------------------------------------------------------------------------
# META PROVISION
#------------------------------------------------------------------------------
ca_method
ca_subject
ca_homedir
ca_cert
ca_key
nginx_upstream
dns_records
prometheus_data_dir
prometheus_options
prometheus_reload
prometheus_sd_method
prometheus_sd_target
prometheus_scrape_interval
prometheus_scrape_timeout
prometheus_sd_interval
grafana_url
grafana_admin_password
grafana_plugin
grafana_cache
grafana_customize
grafana_plugins
grafana_git_plugins
#------------------------------------------------------------------------------
# META PROVISION
#------------------------------------------------------------------------------
# - ca - #
ca_method: create # create|copy|recreate
ca_subject: "/CN=root-ca" # self-signed CA subject
ca_homedir: /ca # ca cert directory
ca_cert: ca.crt # ca public key/cert
ca_key: ca.key # ca private key
# - nginx - #
nginx_upstream:
- { name: home, host: pigsty, url: "127.0.0.1:3000"}
- { name: consul, host: c.pigsty, url: "127.0.0.1:8500" }
- { name: grafana, host: g.pigsty, url: "127.0.0.1:3000" }
- { name: prometheus, host: p.pigsty, url: "127.0.0.1:9090" }
- { name: alertmanager, host: a.pigsty, url: "127.0.0.1:9093" }
- { name: haproxy, host: h.pigsty, url: "127.0.0.1:9091" }
# - nameserver - #
dns_records: # dynamic dns record resolved by dnsmasq
- 10.10.10.2 pg-meta # sandbox vip for pg-meta
- 10.10.10.3 pg-test # sandbox vip for pg-test
- 10.10.10.10 meta-1 # sandbox node meta-1 (node-0)
- 10.10.10.11 node-1 # sandbox node node-1
- 10.10.10.12 node-2 # sandbox node node-2
- 10.10.10.13 node-3 # sandbox node node-3
- 10.10.10.10 pigsty
- 10.10.10.10 y.pigsty yum.pigsty
- 10.10.10.10 c.pigsty consul.pigsty
- 10.10.10.10 g.pigsty grafana.pigsty
- 10.10.10.10 p.pigsty prometheus.pigsty
- 10.10.10.10 a.pigsty alertmanager.pigsty
- 10.10.10.10 n.pigsty ntp.pigsty
- 10.10.10.10 h.pigsty haproxy.pigsty
# - prometheus - #
prometheus_data_dir: /export/prometheus/data # prometheus data dir
prometheus_options: '--storage.tsdb.retention=30d'
prometheus_reload: false # reload prometheus instead of recreate it
prometheus_sd_method: consul # service discovery method: static|consul|etcd
prometheus_sd_target: batch # batch or single (monolith or per instance)
prometheus_scrape_interval: 2s # global scrape & evaluation interval
prometheus_scrape_timeout: 1s # scrape timeout
prometheus_sd_interval: 2s # service discovery refresh interval
# - grafana - #
grafana_url: http://admin:admin@10.10.10.10:3000 # grafana url
grafana_admin_password: admin # default grafana admin user password
grafana_plugin: install # none|install|reinstall
grafana_cache: /www/pigsty/grafana/plugins.tar.gz # path to grafana plugins tarball
grafana_customize: true # customize grafana resources
grafana_plugins: # default grafana plugins list
- redis-datasource
- simpod-json-datasource
- fifemon-graphql-datasource
- sbueringer-consul-datasource
- camptocamp-prometheus-alertmanager-datasource
- ryantxu-ajax-panel
- marcusolsson-hourly-heatmap-panel
- michaeldmoore-multistat-panel
- marcusolsson-treemap-panel
- pr0ps-trackmap-panel
- dalvany-image-panel
- magnesium-wordcloud-panel
- cloudspout-button-panel
- speakyourcode-button-panel
- jdbranham-diagram-panel
- grafana-piechart-panel
- snuids-radar-panel
- digrich-bubblechart-panel
grafana_git_plugins:
- https://github.com/Vonng/grafana-echarts
CA自签名的主题
默认主题为：
"/CN=root-ca"
CA文件的根目录
默认为/ca
CA公钥证书名称
默认为：ca.crt
CA私钥文件名称
默认为ca.key
Nginx上游服务的URL与域名
Nginx会通过Host进行流量转发，因此确保访问Pigsty基础设施服务时，配置有正确的域名。
不要修改name 部分的定义。
nginx_upstream:
- { name: home, host: pigsty, url: "127.0.0.1:3000"}
- { name: consul, host: c.pigsty, url: "127.0.0.1:8500" }
- { name: grafana, host: g.pigsty, url: "127.0.0.1:3000" }
- { name: prometheus, host: p.pigsty, url: "127.0.0.1:9090" }
- { name: alertmanager, host: a.pigsty, url: "127.0.0.1:9093" }
- { name: haproxy, host: h.pigsty, url: "127.0.0.1:9091" }
动态DNS解析记录
每一条记录都会写入元节点的/etc/hosts中，并由元节点上的域名服务器提供解析。
Prometheus数据目录
默认位于/export/prometheus/data
Prometheus命令行参数
默认参数为：--storage.tsdb.retention=30d，即保留30天的监控数据
参数prometheus_retention的功能被此参数覆盖，于v0.6后弃用。
如果为true，执行Prometheus任务时不会清除已有数据目录。
默认为：false，即执行prometheus剧本时会清除已有监控数据。
Prometheus使用的服务发现机制，默认为consul，可选项：
consul：基于Consul进行服务发现static：基于本地配置文件进行服务发现Pigsty建议使用consul服务发现，当服务器发生Failover时，监控系统会自动更正目标实例所注册的身份。
static服务发现依赖/etc/prometheus/targets/*.yml中的配置进行服务发现。采用这种方式的优势是不依赖Consul。当Pigsty监控系统与外部管控方案集成时，这种模式对原系统的侵入性较小。同时，当集群内发生主从切换时，您需要自行维护实例角色信息。
手动维护时，可以根据以下命令从配置文件生成Prometheus所需的监控对象配置文件。
./infra.yml --tags=prometheus_targtes,prometheus_reload
详细信息请参考：服务发现
当 prometheus_sd_method == 'static' 时，监控目标定义文件管理的方式：
batch：使用批量管理的单一配置文件：/etc/prometheus/targets/all.ymlsingle：使用每个实例一个的配置文件：/etc/prometheus/targets/{{ pg_instance }}.yml使用批量管理的单一配置文件管理简单，但用户必须使用默认的单一配置文件方式（即所有数据库集群的定义都在同一个配置文件中），才可以使用这种管理方式。
当使用分立式的配置文件（每个集群一个配置文件）时，用户需要使用 single 管理模式。每一个新数据库实例都会在元节点的 /etc/prometheus/targets/ 目录下创建一个新的定义文件。
Prometheus抓取周期
默认为2s，建议在生产环境中使用15s。
Prometheus抓取超时
默认为1s，建议在生产环境中使用10s，或根据实际需求进行配置。
Prometheus刷新服务发现列表的周期
默认为5s，建议在生产环境中使用更长的间隔，或根据实际需求进行配置。
Prometheus 抓取指标暴露器的URL路径，默认为/metrics
已经被外部变量引用exporter_metrics_path所替代，不再生效。
Prometheus数据保留期限，默认配置30天
参数prometheus_retention的功能被参数prometheus_options覆盖，于v0.6后弃用。
Grafana对外提供服务的端点，需要带上用户名与密码。
Grafana Provision的过程中会使用该URL调用Grafana API
Grafana管理用户的密码
默认为admin
Grafana插件的供给方式
none：不安装插件install: 安装Grafana插件（默认）reinstall: 强制重新安装Grafana插件Grafana需要访问互联网以下载若干扩展插件，如果您的元节点没有互联网访问，离线安装包中已经包含了所有下载好的Grafana插件。Pigsty会在插件下载完成后重新制作新的插件缓存安装包。
Grafana插件缓存文件地址
离线安装包中已经包含了所有下载并打包好的Grafana插件，如果插件包目录已经存在，Pigsty就不会尝试从互联网重新下载Grafana插件。
默认的离线插件缓存地址为：/www/pigsty/grafana/plugins.tar.gz （假设本地Yum源名为pigsty）
标记，是否要定制Grafana
如果选择是，Grafana的Logo会被替换为Pigsty，你懂的。
Grafana插件列表
数组，每个元素是一个插件名称。
插件会通过grafana-cli plugins install的方式进行安装。
默认安装的插件有：
grafana_plugins: # default grafana plugins list
- redis-datasource
- simpod-json-datasource
- fifemon-graphql-datasource
- sbueringer-consul-datasource
- camptocamp-prometheus-alertmanager-datasource
- ryantxu-ajax-panel
- marcusolsson-hourly-heatmap-panel
- michaeldmoore-multistat-panel
- marcusolsson-treemap-panel
- pr0ps-trackmap-panel
- dalvany-image-panel
- magnesium-wordcloud-panel
- cloudspout-button-panel
- speakyourcode-button-panel
- jdbranham-diagram-panel
- grafana-piechart-panel
- snuids-radar-panel
- digrich-bubblechart-panel
Grafana的Git插件
一些插件无法通过官方命令行下载，但可以通过Git Clone的方式下载，则可以考虑使用本参数。
数组，每个元素是一个插件名称。
插件会通过cd /var/lib/grafana/plugins && git clone 的方式进行安装。
默认会下载一个可视化插件：
grafana_git_plugins:
- https://github.com/Vonng/grafana-echarts
Pigsty使用DCS（Distributive Configuration Storage）作为元数据库。
DCS有三个重要作用：
DCS对于数据库的稳定至关重要，Pigsty出于演示目的提供了基本的Consul与Etcd支持，在元节点部署了DCS服务。建议在生产环境中使用专用机器部署专用DCS集群。
#------------------------------------------------------------------------------
# DCS PROVISION
#------------------------------------------------------------------------------
service_registry
dcs_type
dcs_name
dcs_servers
dcs_exists_action
dcs_disable_purge
consul_data_dir
etcd_data_dir
#------------------------------------------------------------------------------
# DCS PROVISION
#------------------------------------------------------------------------------
service_registry: consul # where to register services: none | consul | etcd | both
dcs_type: consul # consul | etcd | both
dcs_name: pigsty # consul dc name | etcd initial cluster token
dcs_servers: # dcs server dict in name:ip format
meta-1: 10.10.10.10 # you could use existing dcs cluster
# meta-2: 10.10.10.11 # host which have their IP listed here will be init as server
# meta-3: 10.10.10.12 # 3 or 5 dcs nodes are recommend for production environment
dcs_exists_action: skip # abort|skip|clean if dcs server already exists
dcs_disable_purge: false # set to true to disable purge functionality for good (force dcs_exists_action = abort)
consul_data_dir: /var/lib/consul # consul data dir (/var/lib/consul by default)
etcd_data_dir: /var/lib/etcd # etcd data dir (/var/lib/consul by default)
DCS类型，有两种选项：
Consul
Etcd （支持尚不完善）
DCS集群名称
默认为pigsty
在Consul中代表 DataCenter名称
DCS服务器名称与地址，采用字典格式，Key为DCS服务器实例名称，Value为对应的IP地址。
可以使用外部的已有DCS服务器，也可以在目标机器上初始化新的DCS服务器。
如果采用初始化新DCS实例的方式，建议先在所有DCS Server（通常也是元节点）上完成DCS初始化。
尽管您也可以一次性初始化所有的DCS Server与DCS Agent，但必须在完整初始化时将所有Server囊括在内。此时所有IP地址匹配dcs_servers项的目标机器将会在DCS初始化过程中，初始化为DCS Server。
强烈建议使用奇数个DCS Server，演示环境可使用单个DCS Server，生产环境建议使用3～5个确保DCS可用性。
您必须根据实际情况显式配置DCS Server，例如在沙箱环境中，您可以选择启用1个或3个DCS节点。
dcs_servers:
meta-1: 10.10.10.10
meta-2: 10.10.10.11
meta-3: 10.10.10.12
安全保险，当Consul实例已经存在时，系统应当执行的动作
如果您真的需要强制清除已经存在的DCS实例，建议先使用pgsql-rm.yml完成集群与实例的下线与销毁，在重新执行初始化。否则，则需要通过命令行参数-e dcs_exists_action=clean完成覆写，强制在初始化过程中抹除已有实例。
双重安全保险，默认为false。如果为true，强制设置dcs_exists_action变量为abort。
等效于关闭dcs_exists_action的清理功能，确保任何情况下DCS实例都不会被抹除。
Consul数据目录地址
默认为/var/lib/consul
Etcd数据目录地址
默认为/var/lib/etcd
PG Install 部分负责在一台装有基本软件的机器上完成所有PostgreSQL依赖项的安装。
用户可以配置数据库超级用户的名称、ID、权限、访问，配置安装所用的源，配置安装地址，安装的版本，所需的软件包与扩展插件。
用户可以通过pg_version指定需要安装的软件版本，并在集群层面进行覆盖，为不同的集群安装不同的数据库版本。
#------------------------------------------------------------------------------
# POSTGRES INSTALLATION
#------------------------------------------------------------------------------
pg_dbsu
pg_dbsu_uid
pg_dbsu_sudo
pg_dbsu_home
pg_dbsu_ssh_exchange
pg_version
pgdg_repo
pg_add_repo
pg_bin_dir
pg_packages
pg_extensions
#------------------------------------------------------------------------------
# POSTGRES INSTALLATION
#------------------------------------------------------------------------------
# - dbsu - #
pg_dbsu: postgres # os user for database, postgres by default (change it is not recommended!)
pg_dbsu_uid: 26 # os dbsu uid and gid, 26 for default postgres users and groups
pg_dbsu_sudo: limit # none|limit|all|nopass (Privilege for dbsu, limit is recommended)
pg_dbsu_home: /var/lib/pgsql # postgresql binary
pg_dbsu_ssh_exchange: false # exchange ssh key among same cluster
# - postgres packages - #
pg_version: 13 # default postgresql version
pgdg_repo: false # use official pgdg yum repo (disable if you have local mirror)
pg_add_repo: false # add postgres related repo before install (useful if you want a simple install)
pg_bin_dir: /usr/pgsql/bin # postgres binary dir
pg_packages:
- postgresql${pg_version}*
- postgis31_${pg_version}*
- pgbouncer patroni pg_exporter pgbadger
- patroni patroni-consul patroni-etcd pgbouncer pgbadger pg_activity
- python3 python3-psycopg2 python36-requests python3-etcd python3-consul
- python36-urllib3 python36-idna python36-pyOpenSSL python36-cryptography
pg_extensions:
- pg_repack${pg_version} pg_qualstats${pg_version} pg_stat_kcache${pg_version} wal2json${pg_version}
# - ogr_fdw${pg_version} mysql_fdw_${pg_version} redis_fdw_${pg_version} mongo_fdw${pg_version} hdfs_fdw_${pg_version}
# - count_distinct${version} ddlx_${version} geoip${version} orafce${version} # popular features
# - hypopg_${version} ip4r${version} jsquery_${version} logerrors_${version} periods_${version} pg_auto_failover_${version} pg_catcheck${version}
# - pg_fkpart${version} pg_jobmon${version} pg_partman${version} pg_prioritize_${version} pg_track_settings${version} pgaudit15_${version}
# - pgcryptokey${version} pgexportdoc${version} pgimportdoc${version} pgmemcache-${version} pgmp${version} pgq-${version} pgquarrel pgrouting_${version}
# - pguint${version} pguri${version} prefix${version} safeupdate_${version} semver${version} table_version${version} tdigest${version}
数据库默认使用的操作系统用户（超级用户）的用户名称，默认为postgres，不建议修改。
数据库默认使用的操作系统用户（超级用户）的UID，默认为26。
与CentOS下PostgreSQL官方RPM包的配置一致，不建议修改。
数据库超级用户的默认权限：
none：没有sudo权限limit：有限的sudo权限，可以执行数据库相关组件的systemctl命令，默认all：带有完整sudo权限，但需要密码。nopass：不需要密码的完整sudo权限（不建议）数据库超级用户的家目录，默认为/var/lib/pgsql
是否在执行的机器之间交换超级用户的SSH公私钥
希望安装的PostgreSQL版本，默认为13
建议在集群级别按需覆盖此变量。
标记，是否使用PostgreSQL官方源？默认不使用
使用该选项，可以在没有本地源的情况下，直接从互联网官方源下载安装PostgreSQL相关软件包。
如果使用，则会在安装PostgreSQL前添加PGDG的官方源
启用此选项，则可以在未执行基础设施初始化的前提下直接执行数据库初始化，尽管可能会很慢，但对于缺少基础设施的场景尤为实用。
PostgreSQL二进制目录
默认为/usr/pgsql/bin/，这是一个安装过程中手动创建的软连接，指向安装的具体Postgres版本目录。
例如/usr/pgsql -> /usr/pgsql-13。
默认安装的PostgreSQL软件包
软件包中的${pg_version}会被替换为实际安装的PostgreSQL版本。
需要安装的PostgreSQL扩展插件软件包
软件包中的${pg_version}会被替换为实际安装的PostgreSQL版本。
默认安装的插件包括：
pg_repack${pg_version}
pg_qualstats${pg_version}
pg_stat_kcache${pg_version}
wal2json${pg_version}
按需启用，但强烈建议安装pg_repack扩展。
PG供给，是在一台安装完Postgres的机器上，创建并拉起一套数据库的过程。
PG供给主要包括以下几方面的内容：
Pigsty使用Patroni完成供给的主体工作，即使用户选择了无Patroni模式（patroni_mode == 'remove'），拉起数据库集群也会由Patroni负责，并在创建完成后移除Patroni组件。
Pigsty供给提供了几种Patroni定制模板，通过pg_conf参数指定：
oltp.yml OLTP模板，默认配置，针对生产机型优化延迟与性能。olap.yml OLAP模板，提高并行度，针对吞吐量，长查询进行优化。crit.yml) 核心业务模板，基于OLTP模板针对RPO、安全性、数据完整性进行优化，启用同步复制与数据校验和。tiny.yml 微型数据库模板，针对低资源场景进行优化，例如运行于虚拟机中的演示数据库集群。#------------------------------------------------------------------------------
# POSTGRES PROVISION
#------------------------------------------------------------------------------
pg_cluster
pg_seq
pg_role
pg_hostname
pg_nodename
pg_exists
pg_exists_action
pg_disable_purge
pg_data
pg_fs_main
pg_fs_bkup
pg_listen
pg_port
patroni_mode
pg_namespace
patroni_port
patroni_watchdog_mode
pg_conf
pgbouncer_port
pgbouncer_poolmode
pgbouncer_max_db_conn
#------------------------------------------------------------------------------
# POSTGRES PROVISION
#------------------------------------------------------------------------------
# - identity - #
# pg_cluster: # [REQUIRED] cluster name (validated during pg_preflight)
# pg_seq: 0 # [REQUIRED] instance seq (validated during pg_preflight)
# pg_role: replica # [REQUIRED] service role (validated during pg_preflight)
pg_hostname: false # overwrite node hostname with pg instance name
pg_nodename: true # overwrite consul nodename with pg instance name
# - retention - #
# pg_exists_action, available options: abort|clean|skip
# - abort: abort entire play's execution (default)
# - clean: remove existing cluster (dangerous)
# - skip: end current play for this host
# pg_exists: false # auxiliary flag variable (DO NOT SET THIS)
pg_exists_action: clean
pg_disable_purge: false # set to true to disable pg purge functionality for good (force pg_exists_action = abort)
# - storage - #
pg_data: /pg/data # postgres data directory
pg_fs_main: /export # data disk mount point /pg -> {{ pg_fs_main }}/postgres/{{ pg_instance }}
pg_fs_bkup: /var/backups # backup disk mount point /pg/* -> {{ pg_fs_bkup }}/postgres/{{ pg_instance }}/*
# - connection - #
pg_listen: '0.0.0.0' # postgres listen address, '0.0.0.0' by default (all ipv4 addr)
pg_port: 5432 # postgres port (5432 by default)
pg_localhost: /var/run/postgresql # localhost unix socket dir for connection
# - patroni - #
# patroni_mode, available options: default|pause|remove
# - default: default ha mode
# - pause: into maintenance mode
# - remove: remove patroni after bootstrap
patroni_mode: default # pause|default|remove
pg_namespace: /pg # top level key namespace in dcs
patroni_port: 8008 # default patroni port
patroni_watchdog_mode: automatic # watchdog mode: off|automatic|required
pg_conf: tiny.yml # user provided patroni config template path
# - pgbouncer - #
pgbouncer_port: 6432 # pgbouncer port (6432 by default)
pgbouncer_poolmode: transaction # pooling mode: (transaction pooling by default)
pgbouncer_max_db_conn: 100 # important! do not set this larger than postgres max conn or conn limit
pg_cluster，pg_role，pg_seq 属于 身份参数
除了IP地址外，这三个参数是定义一套新的数据库集群的最小必须参数集，如下面的配置所示。
其他参数都可以继承自全局配置或默认配置，但身份参数必须显式指定，手工分配。
pg_cluster 标识了集群的名称，在集群层面进行配置。pg_role 在实例层面进行配置，标识了实例的角色，只有primary角色会进行特殊处理，如果不填，默认为replica角色，此外，还有特殊的delayed与offline角色。pg_seq 用于在集群内标识实例，通常采用从0或1开始递增的整数，一旦分配不再更改。{{ pg_cluster }}-{{ pg_seq }} 被用于唯一标识实例，即pg_instance{{ pg_cluster }}-{{ pg_role }} 用于标识集群内的服务，即pg_servicepg-test:
hosts:
10.10.10.11: {pg_seq: 1, pg_role: replica}
10.10.10.12: {pg_seq: 2, pg_role: primary}
10.10.10.13: {pg_seq: 3, pg_role: replica}
vars:
pg_cluster: pg-test
PG数据库集群的名称
身份参数，必填参数，集群级参数
数据库实例的序号，在集群内部唯一，用于区别与标识集群内的不同实例，从0或1开始分配。
身份参数，必填参数，实例级参数
数据库实例的角色，默认角色包括：primary, replica。
后续可选角色包括：offline与delayed。
身份参数，必填参数，实例级参数
是否将PG实例的名称pg_instance 注册为主机名，默认禁用。
是否将PG实例的名称注册为Consul中的节点名称，默认启用。
PG实例是否存在的标记位，不可配置。
安全保险，当PostgreSQL实例已经存在时，系统应当执行的动作
如果您真的需要强制清除已经存在的数据库实例，建议先使用pgsql-rm.yml完成集群与实例的下线与销毁，在重新执行初始化。否则，则需要通过命令行参数-e pg_exists_action=clean完成覆写，强制在初始化过程中抹除已有实例。
双重安全保险，默认为false。如果为true，强制设置pg_exists_action变量为abort。
等效于关闭pg_exists_action的清理功能，确保任何情况下Postgres实例都不会被抹除。
这意味着您需要通过专用下线脚本pgsql-rm.yml来完成已有实例的清理，然后才可以在清理干净的节点上重新完成数据库的初始化。
默认数据目录，默认为/pg/data
主数据盘目录，默认为/export
Pigsty的默认目录结构假设系统中存在一个主数据盘挂载点，用于盛放数据库目录。
归档与备份盘目录，默认为/var/backups
Pigsty的默认目录结构假设系统中存在一个备份数据盘挂载点，用于盛放备份与归档数据。备份盘并不是必选项，如果系统中不存在备份盘，用户也可以指定一个主数据盘上的子目录作为备份盘根目录挂载点。
数据库监听的IP地址，默认为所有IPv4地址0.0.0.0，如果要包括所有IPv6地址，可以使用*。
数据库监听的端口，默认端口为5432，不建议修改。
Unix Socket目录，用于盛放PostgreSQL与Pgbouncer的Unix socket文件。
默认为/var/run/postgresql
Patroni的工作模式：
default: 启用Patronipause: 启用Patroni，但在完成初始化后自动进入维护模式（不自动执行主从切换）remove: 依然使用Patroni初始化集群，但初始化完成后移除PatroniPatroni在DCS中使用的KV存储顶层命名空间
默认为pg
Patroni API服务器默认监听的端口
默认端口为8008
当发生主从切换时，Patroni会尝试在提升从库前关闭主库。如果指定超时时间内主库仍未成功关闭，Patroni会根据配置使用Linux内核功能softdog进行fencing关机。
off：不使用watchdogautomatic：如果内核启用了softdog，则启用watchdog，不强制，默认行为。required：强制使用watchdog，如果系统未启用softdog则拒绝启动。拉起Postgres集群所用的Patroni模板。Pigsty预制了4种模板
oltp.yml 常规OLTP模板，默认配置olap.yml OLAP模板，提高并行度，针对吞吐量优化，针对长时间运行的查询进行优化。crit.yml) 核心业务模板，基于OLTP模板针对安全性，数据完整性进行优化，采用同步复制，强制启用数据校验和。tiny.yml 微型数据库模板，针对低资源场景进行优化，例如运行于虚拟机中的演示数据库集群。Pgbouncer连接池默认监听的端口
默认为6432
Pgbouncer连接池默认使用的Pool模式
默认为transaction，即事务级连接池。其他可选项包括：session|statemente
允许连接池与单个数据库之间建立的最大连接数
默认值为100
使用事务Pooling模式时，活跃服务端连接数通常处于个位数。如果采用会话Pooling，可以适当增大此参数。
PG Provision负责拉起一套全新的Postgres集群，而PG Template负责在PG Provision的基础上，在这套全新的数据库集群中创建默认的对象，包括
关于定制数据库集群的更多信息，请参考 定制集群
#------------------------------------------------------------------------------
# POSTGRES TEMPLATE
#------------------------------------------------------------------------------
pg_init
pg_replication_username
pg_replication_password
pg_monitor_username
pg_monitor_password
pg_admin_username
pg_admin_password
pg_default_roles
pg_default_privileges
pg_default_schemas
pg_default_extensions
pg_offline_query
pg_hba_rules
pg_hba_rules_extra
pgbouncer_hba_rules
pgbouncer_hba_rules_extra
pg_users
pg_databases
#------------------------------------------------------------------------------
# POSTGRES TEMPLATE
#------------------------------------------------------------------------------
# - template - #
pg_init: pg-init # init script for cluster template
# - system roles - #
pg_replication_username: replicator # system replication user
pg_replication_password: DBUser.Replicator # system replication password
pg_monitor_username: dbuser_monitor # system monitor user
pg_monitor_password: DBUser.Monitor # system monitor password
pg_admin_username: dbuser_admin # system admin user
pg_admin_password: DBUser.Admin # system admin password
# - default roles - #
# chekc http://pigsty.cc/zh/docs/concepts/provision/acl/ for more detail
pg_default_roles:
# common production readonly user
- name: dbrole_readonly # production read-only roles
login: false
comment: role for global readonly access
# common production read-write user
- name: dbrole_readwrite # production read-write roles
login: false
roles: [dbrole_readonly] # read-write includes read-only access
comment: role for global read-write access
# offline have same privileges as readonly, but with limited hba access on offline instance only
# for the purpose of running slow queries, interactive queries and perform ETL tasks
- name: dbrole_offline
login: false
comment: role for restricted read-only access (offline instance)
# admin have the privileges to issue DDL changes
- name: dbrole_admin
login: false
bypassrls: true
comment: role for object creation
roles: [dbrole_readwrite,pg_monitor,pg_signal_backend]
# dbsu, name is designated by `pg_dbsu`. It's not recommend to set password for dbsu
- name: postgres
superuser: true
comment: system superuser
# default replication user, name is designated by `pg_replication_username`, and password is set by `pg_replication_password`
- name: replicator
replication: true
roles: [pg_monitor, dbrole_readonly]
comment: system replicator
# default replication user, name is designated by `pg_monitor_username`, and password is set by `pg_monitor_password`
- name: dbuser_monitor
connlimit: 16
comment: system monitor user
roles: [pg_monitor, dbrole_readonly]
# default admin user, name is designated by `pg_admin_username`, and password is set by `pg_admin_password`
- name: dbuser_admin
bypassrls: true
comment: system admin user
roles: [dbrole_admin]
# default stats user, for ETL and slow queries
- name: dbuser_stats
password: DBUser.Stats
comment: business offline user for offline queries and ETL
roles: [dbrole_offline]
# - privileges - #
# object created by dbsu and admin will have their privileges properly set
pg_default_privileges:
- GRANT USAGE ON SCHEMAS TO dbrole_readonly
- GRANT SELECT ON TABLES TO dbrole_readonly
- GRANT SELECT ON SEQUENCES TO dbrole_readonly
- GRANT EXECUTE ON FUNCTIONS TO dbrole_readonly
- GRANT USAGE ON SCHEMAS TO dbrole_offline
- GRANT SELECT ON TABLES TO dbrole_offline
- GRANT SELECT ON SEQUENCES TO dbrole_offline
- GRANT EXECUTE ON FUNCTIONS TO dbrole_offline
- GRANT INSERT, UPDATE, DELETE ON TABLES TO dbrole_readwrite
- GRANT USAGE, UPDATE ON SEQUENCES TO dbrole_readwrite
- GRANT TRUNCATE, REFERENCES, TRIGGER ON TABLES TO dbrole_admin
- GRANT CREATE ON SCHEMAS TO dbrole_admin
# - schemas - #
pg_default_schemas: [monitor] # default schemas to be created
# - extension - #
pg_default_extensions: # default extensions to be created
- { name: 'pg_stat_statements', schema: 'monitor' }
- { name: 'pgstattuple', schema: 'monitor' }
- { name: 'pg_qualstats', schema: 'monitor' }
- { name: 'pg_buffercache', schema: 'monitor' }
- { name: 'pageinspect', schema: 'monitor' }
- { name: 'pg_prewarm', schema: 'monitor' }
- { name: 'pg_visibility', schema: 'monitor' }
- { name: 'pg_freespacemap', schema: 'monitor' }
- { name: 'pg_repack', schema: 'monitor' }
- name: postgres_fdw
- name: file_fdw
- name: btree_gist
- name: btree_gin
- name: pg_trgm
- name: intagg
- name: intarray
# - hba - #
pg_offline_query: false # set to true to enable offline query on instance
pg_hba_rules: # postgres host-based authentication rules
- title: allow meta node password access
role: common
rules:
- host all all 10.10.10.10/32 md5
- title: allow intranet admin password access
role: common
rules:
- host all +dbrole_admin 10.0.0.0/8 md5
- host all +dbrole_admin 172.16.0.0/12 md5
- host all +dbrole_admin 192.168.0.0/16 md5
- title: allow intranet password access
role: common
rules:
- host all all 10.0.0.0/8 md5
- host all all 172.16.0.0/12 md5
- host all all 192.168.0.0/16 md5
- title: allow local read/write (local production user via pgbouncer)
role: common
rules:
- local all +dbrole_readonly md5
- host all +dbrole_readonly 127.0.0.1/32 md5
- title: allow offline query (ETL,SAGA,Interactive) on offline instance
role: offline
rules:
- host all +dbrole_offline 10.0.0.0/8 md5
- host all +dbrole_offline 172.16.0.0/12 md5
- host all +dbrole_offline 192.168.0.0/16 md5
pg_hba_rules_extra: [] # extra hba rules (for cluster/instance overwrite)
pgbouncer_hba_rules: # pgbouncer host-based authentication rules
- title: local password access
role: common
rules:
- local all all md5
- host all all 127.0.0.1/32 md5
- title: intranet password access
role: common
rules:
- host all all 10.0.0.0/8 md5
- host all all 172.16.0.0/12 md5
- host all all 192.168.0.0/16 md5
pgbouncer_hba_rules_extra: [] # extra pgbouncer hba rules (for cluster/instance overwrite)
用于初始化数据库模板的Shell脚本位置，默认为pg-init，该脚本会被拷贝至/pg/bin/pg-init后执行。
默认的pg-init 只是预渲染SQL命令的包装：
/pg/tmp/pg-init-roles.sql ： 根据pg_default_roles生成的默认角色创建脚本/pg/tmp/pg-init-template.sql，根据pg_default_privileges, pg_default_schemas, pg_default_extensions 生产的SQL命令。会同时应用于默认模版数据库template1与默认管理数据库postgres。# system default roles
psql postgres -qAXwtf /pg/tmp/pg-init-roles.sql
# system default template
psql template1 -qAXwtf /pg/tmp/pg-init-template.sql
# make postgres same as templated database (optional)
psql postgres -qAXwtf /pg/tmp/pg-init-template.sql
用户可以在自定义的pg-init脚本中添加自己的集群初始化逻辑。
用于执行PostgreSQL流复制的数据库用户名
默认为replicator
用于执行PostgreSQL流复制的数据库用户密码，必须使用明文
默认为DBUser.Replicator，强烈建议修改！
用于执行PostgreSQL与Pgbouncer监控任务的数据库用户名
默认为dbuser_monitor
用于执行PostgreSQL与Pgbouncer监控任务的数据库用户密码，必须使用明文
默认为DBUser.Monitor，强烈建议修改！
用于执行PostgreSQL数据库管理任务（DDL变更）的数据库用户名
默认为dbuser_admin
用于执行PostgreSQL数据库管理任务（DDL变更）的数据库用户密码，必须使用明文
默认为DBUser.Admin，强烈建议修改！
定义了PostgreSQL中默认的角色与用户，形式为对象数组，每一个对象定义一个用户或角色。
每一个用户或角色必须指定 name ，其余字段均为可选项。
password是可选项，如果留空则不设置密码，可以使用MD5密文密码。
login, superuser, createdb, createrole, inherit, replication, bypassrls 都是布尔类型，用于设置用户属性。如果不设置，则采用系统默认值。
用户通过CREATE USER创建，所以默认具有login属性，如果创建的是角色，需要指定login: false。
expire_at与expire_in用于控制用户过期时间，expire_at使用形如YYYY-mm-DD的日期时间戳。expire_in使用从现在开始的过期天数，如果expire_in存在则会覆盖expire_at选项。
新用户默认不会添加至Pgbouncer用户列表中，必须显式定义pgbouncer: true，该用户才会被加入到Pgbouncer用户列表。
用户/角色会按顺序创建，后面定义的用户可以属于前面定义的角色。
pg_users:
# complete example of user/role definition for production user
- name: dbuser_meta # example production user have read-write access
password: DBUser.Meta # example user's password, can be encrypted
login: true # can login, true by default (should be false for role)
superuser: false # is superuser? false by default
createdb: false # can create database? false by default
createrole: false # can create role? false by default
inherit: true # can this role use inherited privileges?
replication: false # can this role do replication? false by default
bypassrls: false # can this role bypass row level security? false by default
connlimit: -1 # connection limit, -1 disable limit
expire_at: '2030-12-31' # 'timestamp' when this role is expired
expire_in: 365 # now + n days when this role is expired (OVERWRITE expire_at)
roles: [dbrole_readwrite] # dborole_admin|dbrole_readwrite|dbrole_readonly|dbrole_offline
pgbouncer: true # add this user to pgbouncer? false by default (true for production user)
parameters: # user's default search path
search_path: public
comment: test user
Pigsty定义了由四个默认角色与四个默认用户组成的基本访问控制系统，详细信息请参考 访问控制。
定义数据库模板中的默认权限。
任何由{{ dbsu」}}与{{ pg_admin_username }}创建的对象都会具有以下默认权限：
pg_default_privileges:
- GRANT USAGE ON SCHEMAS TO dbrole_readonly
- GRANT SELECT ON TABLES TO dbrole_readonly
- GRANT SELECT ON SEQUENCES TO dbrole_readonly
- GRANT EXECUTE ON FUNCTIONS TO dbrole_readonly
- GRANT USAGE ON SCHEMAS TO dbrole_offline
- GRANT SELECT ON TABLES TO dbrole_offline
- GRANT SELECT ON SEQUENCES TO dbrole_offline
- GRANT EXECUTE ON FUNCTIONS TO dbrole_offline
- GRANT INSERT, UPDATE, DELETE ON TABLES TO dbrole_readwrite
- GRANT USAGE, UPDATE ON SEQUENCES TO dbrole_readwrite
- GRANT TRUNCATE, REFERENCES, TRIGGER ON TABLES TO dbrole_admin
- GRANT CREATE ON SCHEMAS TO dbrole_admin
详细信息请参考 访问控制。
创建于模版数据库的默认模式
Pigsty默认会创建名为monitor的模式用于安装监控扩展。
pg_default_schemas: [monitor] # default schemas to be created
默认安装于模板数据库的扩展，对象数组。
如果没有指定schema字段，扩展会根据当前的search_path安装至对应模式中。
pg_default_extensions:
- { name: 'pg_stat_statements', schema: 'monitor' }
- { name: 'pgstattuple', schema: 'monitor' }
- { name: 'pg_qualstats', schema: 'monitor' }
- { name: 'pg_buffercache', schema: 'monitor' }
- { name: 'pageinspect', schema: 'monitor' }
- { name: 'pg_prewarm', schema: 'monitor' }
- { name: 'pg_visibility', schema: 'monitor' }
- { name: 'pg_freespacemap', schema: 'monitor' }
- { name: 'pg_repack', schema: 'monitor' }
- name: postgres_fdw
- name: file_fdw
- name: btree_gist
- name: btree_gin
- name: pg_trgm
- name: intagg
- name: intarray
实例级变量，布尔类型，默认为false。
设置为true时，无论当前实例的角色为何，用户组dbrole_offline都可以连接至该实例并执行离线查询。
对于实例数量较少（例如一主一从）的情况较为实用，用户可以将唯一的从库标记为pg_offline_query = true，从而接受ETL，慢查询与交互式访问。详细信息请参考 访问控制-离线用户。
设置数据库的客户端IP黑白名单规则。对象数组，每一个对象都代表一条规则。
每一条规则由三部分组成：
title，规则标题，会转换为HBA文件中的注释role，应用角色，common代表应用至所有实例，其他取值（如replica, offline）则仅会安装至匹配的角色上。例如role='replica'代表这条规则只会应用到pg_role == 'replica' 的实例上。rules，字符串数组，每一条记录代表一条最终写入pg_hba.conf的规则。作为一个特例，role == 'offline' 的HBA规则，还会额外安装至 pg_offline_query == true 的实例上。
pg_hba_rules:
- title: allow meta node password access
role: common
rules:
- host all all 10.10.10.10/32 md5
- title: allow intranet admin password access
role: common
rules:
- host all +dbrole_admin 10.0.0.0/8 md5
- host all +dbrole_admin 172.16.0.0/12 md5
- host all +dbrole_admin 192.168.0.0/16 md5
- title: allow intranet password access
role: common
rules:
- host all all 10.0.0.0/8 md5
- host all all 172.16.0.0/12 md5
- host all all 192.168.0.0/16 md5
- title: allow local read-write access (local production user via pgbouncer)
role: common
rules:
- local all +dbrole_readwrite md5
- host all +dbrole_readwrite 127.0.0.1/32 md5
- title: allow read-only user (stats, personal) password directly access
role: replica
rules:
- local all +dbrole_readonly md5
- host all +dbrole_readonly 127.0.0.1/32 md5
建议在全局配置统一的pg_hba_rules，针对特定集群使用pg_hba_rules_extra进行额外定制。
与pg_hba_rules类似，但通常用于集群层面的HBA规则设置。
pg_hba_rules_extra 会以同样的方式 追加 至pg_hba.conf中。
如果用户需要彻底覆写集群的HBA规则，即不想继承全局HBA配置，则应当在集群层面配置pg_hba_rules并覆盖全局配置。
与pg_hba_rules类似，用于Pgbouncer的HBA规则设置。
默认的Pgbouncer HBA规则很简单，用户可以按照自己的需求进行定制。
默认的Pgbouncer HBA规则较为宽松：
pgbouncer_hba_rules:
- title: local password access
role: common
rules:
- local all all md5
- host all all 127.0.0.1/32 md5
- title: intranet password access
role: common
rules:
- host all all 10.0.0.0/8 md5
- host all all 172.16.0.0/12 md5
- host all all 192.168.0.0/16 md5
与pg_hba_rules_extras类似，用于在集群层次对Pgbouncer的HBA规则进行额外配置。
以下两个参数属于业务模板，用户应当在这里定义所需的业务用户与业务数据库。
在这里定义的用户与数据库，会在以下两个步骤中完成应用，不仅仅包括数据库中的用户与DB，还有Pgbouncer连接池中的对应配置。
./pgsql.yml --tags=pg_biz_init,pg_biz_pgbouncer
通常用于在数据库集群层面定义业务用户，与 pg_default_roles 采用相同的形式。
对象数组，每个对象定义一个业务用户。用户名name字段为必选项，密码可以使用MD5密文密码
用户可以通过roles字段为业务用户添加默认权限组：
dbrole_readonly：默认生产只读用户，具有全局只读权限。（只读生产访问）dbrole_offline：默认离线只读用户，在特定实例上具有只读权限。（离线查询，个人账号，ETL）dbrole_readwrite：默认生产读写用户，具有全局CRUD权限。（常规生产使用）dbrole_admin：默认生产管理用户，具有执行DDL变更的权限。（管理员）应当为生产账号配置 pgbouncer: true，允许其通过连接池访问，普通用户不应当通过连接池访问数据库。
下面是一个创建业务账号的例子：
pg_users:
# complete example of user/role definition for production user
- name: dbuser_meta # example production user have read-write access
password: DBUser.Meta # example user's password, can be encrypted
login: true # can login, true by default (should be false for role)
superuser: false # is superuser? false by default
createdb: false # can create database? false by default
createrole: false # can create role? false by default
inherit: true # can this role use inherited privileges?
replication: false # can this role do replication? false by default
bypassrls: false # can this role bypass row level security? false by default
connlimit: -1 # connection limit, -1 disable limit
expire_at: '2030-12-31' # 'timestamp' when this role is expired
expire_in: 365 # now + n days when this role is expired (OVERWRITE expire_at)
roles: [dbrole_readwrite] # dborole_admin|dbrole_readwrite|dbrole_readonly
pgbouncer: true # add this user to pgbouncer? false by default (true for production user)
parameters: # user's default search path
search_path: public
comment: test user
# simple example for personal user definition
- name: dbuser_vonng2 # personal user example which only have limited access to offline instance
password: DBUser.Vonng # or instance with explict mark `pg_offline_query = true`
roles: [dbrole_offline] # personal/stats/ETL user should be grant with dbrole_offline
expire_in: 365 # expire in 365 days since creation
pgbouncer: false # personal user should NOT be allowed to login with pgbouncer
comment: example personal user for interactive queries
对象数组，每个对象定义一个业务数据库。每个数据库定义中，数据库名称 name 为必选项，其余均为可选项。
name：数据库名称，必选项。
owner：数据库属主，默认为postgres
template：数据库创建时使用的模板，默认为template1
encoding：数据库默认编码，默认为UTF8
locale：数据库默认的LOCALE，默认为C
allowconn：是否允许连接至数据库，默认为true，不建议修改。
revokeconn：是否回收连接至数据库的权限？默认为false。如果为true，则数据库上的PUBLIC CONNECT权限会被回收。只有默认用户（dbsu|monitor|admin|replicator|owner）可以连接。此外，admin|owner 会拥有GRANT OPTION，可以赋予其他用户连接权限。
tablespace：数据库关联的表空间，默认为pg_default。
connlimit：数据库连接数限制，默认为-1，即没有限制。
extensions：对象数组 ，每一个对象定义了一个数据库中的扩展，以及其安装的模式。
parameters：KV对象，每一个KV定义了一个需要针对数据库通过ALTER DATABASE修改的参数。
pgbouncer：布尔选项，是否将该数据库加入到Pgbouncer中。所有数据库都会加入至Pgbouncer，除非显式指定pgbouncer: false。
comment：数据库备注信息。
pg_databases:
- name: meta # name is the only required field for a database
owner: postgres # optional, database owner
template: template1 # optional, template1 by default
encoding: UTF8 # optional, UTF8 by default
locale: C # optional, C by default
allowconn: true # optional, true by default, false disable connect at all
revokeconn: false # optional, false by default, true revoke connect from public # (only default user and owner have connect privilege on database)
tablespace: pg_default # optional, 'pg_default' is the default tablespace
connlimit: -1 # optional, connection limit, -1 or none disable limit (default)
extensions: # optional, extension name and where to create
- {name: postgis, schema: public}
parameters: # optional, extra parameters with ALTER DATABASE
enable_partitionwise_join: true
pgbouncer: true # optional, add this database to pgbouncer list? true by default
comment: pigsty meta database # optional, comment string for database
Pigsty的监控系统包含三个组件：
此外，Haproxy将直接通过管理端口对外暴露监控指标。
所有监控Exporter都会被注册至Consul，Prometheus会通过服务发现的方式管理这些任务。
#------------------------------------------------------------------------------
# MONITOR PROVISION
#------------------------------------------------------------------------------
exporter_install
exporter_repo_url
exporter_metrics_path
node_exporter_enabled
node_exporter_port
node_exporter_options
pg_exporter_config
pg_exporter_enabled
pg_exporter_port
pg_exporter_url
pgbouncer_exporter_enabled
pgbouncer_exporter_port
pgbouncer_exporter_url
#------------------------------------------------------------------------------
# MONITOR PROVISION
#------------------------------------------------------------------------------
# - install - #
exporter_install: none # none|yum|binary, none by default
exporter_repo_url: '' # if set, repo will be added to /etc/yum.repos.d/ before yum installation
# - collect - #
exporter_metrics_path: /metrics # default metric path for pg related exporter
# - node exporter - #
node_exporter_enabled: true # setup node_exporter on instance
node_exporter_port: 9100 # default port for node exporter
node_exporter_options: '--no-collector.softnet --collector.systemd --collector.ntp --collector.tcpstat --collector.processes'
# - pg exporter - #
pg_exporter_config: pg_exporter-demo.yaml # default config files for pg_exporter
pg_exporter_enabled: true # setup pg_exporter on instance
pg_exporter_port: 9630 # default port for pg exporter
pg_exporter_url: '' # optional, if not set, generate from reference parameters
# - pgbouncer exporter - #
pgbouncer_exporter_enabled: true # setup pgbouncer_exporter on instance (if you don't have pgbouncer, disable it)
pgbouncer_exporter_port: 9631 # default port for pgbouncer exporter
pgbouncer_exporter_url: '' # optional, if not set, generate from reference parameters
指明安装Exporter的方式：
none：不安装，（默认行为，Exporter已经在先前由 node.pkgs 任务完成安装）yum：使用yum安装（如果启用yum安装，在部署Exporter前执行yum安装 node_exporter 与 pg_exporter ）binary：使用拷贝二进制的方式安装（从files中直接拷贝node_exporter与 pg_exporter 二进制）使用yum安装时，如果指定了exporter_repo_url（不为空），在执行安装时会首先将该URL下的REPO文件安装至/etc/yum.repos.d中。这一功能可以在不执行节点基础设施初始化的环境下直接进行Exporter的安装。
使用binary安装时，用户需要确保已经将 node_exporter 与 pg_exporter 的Linux二进制程序放置在files目录中。
<meta>:<pigsty>/files/node_exporter -> <target>:/usr/bin/node_exporter
<meta>:<pigsty>/files/pg_exporter -> <target>:/usr/bin/pg_exporter
该参数已被expoter_install 参数覆盖
是否采用复制二进制文件的方式安装Node Exporter与PG Exporter，默认为false
该选项主要用于集成外部供给方案时，减少对原有系统的工作假设。启用该选项将直接将Linux二进制文件复制至目标机器。
<meta>:<pigsty>/files/node_exporter -> <target>:/usr/bin/node_exporter
<meta>:<pigsty>/files/pg_exporter -> <target>:/usr/bin/pg_exporter
用户需要通过files/download-exporter.sh从Github下载Linux二进制程序至files目录，方可启用该选项。
所有Exporter对外暴露指标的URL PATH，默认为/metrics
该变量被外部角色prometheus引用，Prometheus会根据这里的配置，针对job = pg的监控对象应用此配置。
是否安装并配置node_exporter，默认为true
node_exporter监听的端口
默认端口9100
node_exporter 使用的额外命令行选项。
该选项主要用于定制 node_exporter 启用的指标收集器，Node Exporter支持的收集器列表可以参考：Node Exporter Collectors
该选项的默认值为：
node_exporter_options: '--no-collector.softnet --collector.systemd --collector.ntp --collector.tcpstat --collector.processes'
pg_exporter使用的默认配置文件，定义了Pigsty中的指标。
Pigsty默认提供了两个配置文件：
pg_exporter-demo.yaml 用于沙箱演示环境，缓存TTL更低（1s），监控实时性更好，但性能冲击更大。
pg_exporter.yaml，用于生产环境，有着正常的缓存TTL（10s），显著降低多个Prometheus同时抓取的负载。
如果用户采用了不同的Prometheus架构，建议对pg_exporter的配置文件进行检查与调整。
Pigsty使用的PG Exporter配置文件默认从PostgreSQL 10.0 开始提供支持，目前支持至最新的PG 13版本
是否安装并配置pg_exporter，默认为true
PG Exporter用于连接至数据库的PGURL
可选参数，默认为空字符串。
Pigsty默认使用以下规则生成监控的目标URL，如果配置了pg_exporter_url选项，则会直接使用该URL作为连接串。
PG_EXPORTER_URL='postgres://{{ pg_monitor_username }}:{{ pg_monitor_password }}@:{{ pg_port }}/{{ pg_default_database }}?host={{ pg_localhost }}&sslmode=disable'
该选项以环境变量的方式配置于 /etc/default/pg_exporter 中。
是否安装并配置pgbouncer_exporter，默认为true
pg_exporter监听的端口
默认端口9630
pgbouncer_exporter监听的端口
默认端口9631
PGBouncer Exporter用于连接至数据库的URL
可选参数，默认为空字符串。
Pigsty默认使用以下规则生成监控的目标URL，如果配置了pgbouncer_exporter_url选项，则会直接使用该URL作为连接串。
PG_EXPORTER_URL='postgres://{{ pg_monitor_username }}:{{ pg_monitor_password }}@:{{ pgbouncer_port }}/pgbouncer?host={{ pg_localhost }}&sslmode=disable'
该选项以环境变量的方式配置于 /etc/default/pgbouncer_exporter 中。
负载均衡的最佳方式是，通过服务发现（例如查询Consul元数据）确定当前系统状态，采用智能客户端进行连接。但负载均衡与流量接入方案通常因公司、基础设施、研发人员水平而异。出于演示完整性考虑，Pigsty中集成了基于Haproxy与VIP的负载均衡方案。
#------------------------------------------------------------------------------
# PROXY PROVISION
#------------------------------------------------------------------------------
haproxy_enabled
haproxy_policy
haproxy_admin_auth_enabled
haproxy_admin_username
haproxy_admin_password
haproxy_client_timeout
haproxy_server_timeout
haproxy_exporter_port
haproxy_check_port
haproxy_primary_port
haproxy_replica_port
haproxy_backend_port
haproxy_weight
haproxy_weight_fallback
vip_enabled
vip_address
vip_cidrmask
vip_interface
#------------------------------------------------------------------------------
# PROXY PROVISION
#------------------------------------------------------------------------------
# - haproxy - #
haproxy_enabled: true # enable haproxy among every cluster members
haproxy_policy: roundrobin # roundrobin, leastconn
haproxy_admin_auth_enabled: false # enable authentication for haproxy admin?
haproxy_admin_username: admin # default haproxy admin username
haproxy_admin_password: admin # default haproxy admin password
haproxy_client_timeout: 3h # client side connection timeout
haproxy_server_timeout: 3h # server side connection timeout
haproxy_exporter_port: 9101 # default admin/exporter port
haproxy_check_port: 8008 # default health check port (patroni 8008 by default)
haproxy_primary_port: 5433 # default primary port 5433
haproxy_replica_port: 5434 # default replica port 5434
haproxy_backend_port: 6432 # default target port: pgbouncer:6432 postgres:5432
haproxy_weight: 100 # default weight for load balancer
haproxy_weight_fallback: 1 # assign a small weight for primary in replica service
# (in case of singleton replica failure, primary can still take read-only )
# - vip - #
# vip_enabled: true # level2 vip requires primary/standby under same switch
# vip_address: 127.0.0.1 # virtual ip address ip/cidr
# vip_cidrmask: 32 # virtual ip address cidr mask
# vip_interface: eth0 # virtual ip network interface
是否启用Haproxy组件
Pigsty默认会在所有数据库节点上部署Haproxy，您可以通过覆盖实例级变量，仅在特定实例/节点上启用Haproxy负载均衡器。
haproxy负载均衡所使用的算法，可选策略为roundrobin与leastconn
默认为roundrobin
是否启用为Haproxy管理界面启用基本认证
默认不启用，建议在生产环境启用，或在Nginx或其他接入层添加访问控制。
启用Haproxy管理界面认证默认用户名，默认为admin
启用Haproxy管理界面认证默认密码，默认为admin
Haproxy客户端连接超时，默认为3小时
Haproxy服务端连接超时，默认为3小时
Haproxy管理界面与监控指标暴露端点所监听的端口。
默认端口为9101
Haproxy对后端PostgreSQL进程执行健康检查的端口。
默认端口为8008，即Patroni的端口。
其他的选项包括9630，即使用pg_exporter作为健康检查的端口。
Haproxy中集群读写服务默认端口，所有链接至该端口的客户端链接都会被转发至主实例的对应端口。
默认读写服务的端口为5433
Haproxy中集群只读服务默认端口，所有链接至该端口的客户端链接都会被转发至主从例的对应端口。
默认读写服务的端口为5434
Haproxy将客户端连接转发至后端的对应端口，可选：5432/6432
默认为6432，即Haproxy会将流量转发至6432连接池端口，修改为5432表示直接将流量转发至数据库。
Haproxy进行负载均衡时的标准权重，默认为100，建议在实例层次进行覆盖。
用于控制主库承载只读流量的权重。
如果haproxy_weight_fallback为0，主库不会承担任何只读流量（发送至haproxy_replica_port）。
如果haproxy_weight_fallback为1（或更高的值时），在集群正常工作时，主库会在从库服务集中承担 1/总权重 的微小流量，而当从库集中所有的只读实例故障时，只读流量可以漂移至主库承载。
该配置对于一主一从的情况非常实用，如果您有多台从库，建议将其配置为0。
是否启用VIP，默认不启用。
VIP用于确保读写服务与负载均衡器的高可用，Pigsty的VIP由vip-manager托管，会绑定在集群主库上。
这意味着您始终可以通过VIP访问集群主库，或者通过VIP访问主库上的负载均衡器（如果主库的压力很大，这样做可能会有性能压力）。
注意，您必须保证VIP候选实例处于同一个二层网络（VLAN、交换机）下。
VIP地址
vip_address没有默认值，您必须为每一个集群显式指定并分配VIP地址
VIP的CIDR网络长度
vip_cidrmask没有默认值，您必须为每一个集群显式指定VIP的网络CIDR。
VIP网卡名称
默认为eth0
Pigsty采用声明式接口，配置完成之后只需运行固定的 剧本（Playbook），即可完成部署
针对本地沙箱环境，Pigsty提供了特殊的快速一键部署剧本 sandbox.yml 。
该剧本采用交织式部署，可以同时完成基础设施与PG集群的部署任务，让沙箱的拉起速度加倍。
Pigsty提供仅监控部署剧本：pgsql-monitor.yml，用于集成已有供给方案，监控现有数据库集群。
Pigsty还提供了一些供日常运维管理使用的预置剧本：
pgsql-rm.yml 可以移除现有的数据库集群或实例，回收节点。pgsql-createdb.yml 可以在现有集群中创建新的数据库或修改现有数据库。pgsql-createuser.yml 可以在现有集群中创建新用户或修改现有用户。Pigsty需要首先完成元节点的基础设施部署，基础设施的部署通过infra.yml完成。
infra.yml 将元节点（默认分组名为meta）作为部署目标，用户需要先行在配置文件的meta分组中指定元节点。
./infra.yml
您必须完成元节点的初始化后，才能正常执行普通节点的初始化工作。
infra.yml 固定会作用于配置文件中 名为 meta 的分组
您可以将元节点当成普通节点复用，即在元节点上定义并创建PostgreSQL数据库。
我们建议按照默认配置在元节点上创建一个pg-meta元数据库，但不要施加过多负载。
完整执行一遍初始化流程可能花费2～8分钟，视您的机器配置而定。
您可以通过ansible的标签机制，可以选择执行剧本的一个子集。
例如，如果您只想执行本地源初始化的部分，则可以通过以下命令进行
./infra.yml --tags=repo
具体的标签请参考任务详情
一些常用的任务子集包括：
./infra.yml --tags=repo -e repo_rebuild=true # 强制重新创建本地源
./infra.yml --tags=prometheus_reload # 重新加载Prometheus配置
./infra.yml --tags=nginx_haproxy # 重新生成Nginx Haproxy索引页
./infra.yml --tags=prometheus_targets,prometheus_reload # 重新生成Prometheus静态监控对象文件并应用
infra.yml 主要完成以下工作
#!/usr/bin/env ansible-playbook
---
#==============================================================#
# File : infra.yml
# Ctime : 2020-04-13
# Mtime : 2020-07-23
# Desc : init infrastructure on meta nodes
# Path : infra.yml
# Copyright (C) 2018-2021 Ruohang Feng
#==============================================================#
#------------------------------------------------------------------------------
# init local yum repo (only run on meta nodes)
#------------------------------------------------------------------------------
- name: Init local repo
become: yes
hosts: meta
gather_facts: no
tags: repo
roles:
- repo
#------------------------------------------------------------------------------
# provision nodes
#------------------------------------------------------------------------------
- name: Provision Node
become: yes
hosts: meta
gather_facts: no
tags: node
roles:
- node
#------------------------------------------------------------------------------
# init meta service (only run on meta nodes)
#------------------------------------------------------------------------------
- name: Init meta service
become: yes
hosts: meta
gather_facts: no
tags: meta
roles:
- role: ca
tags: ca
- role: nameserver
tags: nameserver
- role: nginx
tags: nginx
- role: prometheus
tags: prometheus
- role: grafana
tags: grafana
#------------------------------------------------------------------------------
# init dcs on nodes
#------------------------------------------------------------------------------
- name: Init dcs
become: yes
hosts: meta
gather_facts: no
roles:
- role: consul
tags: dcs
#------------------------------------------------------------------------------
# copy scripts to meta node
#------------------------------------------------------------------------------
- name: Copy ansible scripts
become: yes
hosts: meta
gather_facts: no
ignore_errors: yes
tags: ansible
tasks:
- name: Copy ansible scritps
when: node_admin_setup is defined and node_admin_setup|bool and node_admin_username != ''
block:
# create copy of this repo
- name: Create ansible tarball
become: no
connection: local
run_once: true
command:
cmd: tar -cf files/meta.tgz roles templates ansible.cfg infra.yml pgsql.yml pgsql-rm.yml pigsty.yml Makefile
chdir: "{{ playbook_dir }}"
- name: Create ansible directory
file: path="/home/{{ node_admin_username }}/meta" state=directory owner={{ node_admin_username }}
- name: Copy ansible tarball
copy: src="meta.tgz" dest="/home/{{ node_admin_username }}/meta/meta.tgz" owner={{ node_admin_username }}
- name: Extract tarball
shell: |
cd /home/{{ node_admin_username }}/meta/
tar -xf meta.tgz
chown -R {{ node_admin_username }} /home/{{ node_admin_username }}
rm -rf meta.tgz
chmod a+x *.yml
#------------------------------------------------------------------------------
# meta node database (optional)
#------------------------------------------------------------------------------
# this play will create database clusters on meta nodes.
# it's good to reuse meta node as normal database nodes too
# but it's always better to leave it be.
#------------------------------------------------------------------------------
#- name: Pgsql Initialization
# become: yes
# hosts: meta
# gather_facts: no
# roles:
# - role: postgres # init postgres
# tags: [pgsql, postgres]
#
# - role: monitor # init monitor system
# tags: [pgsql, monitor]
#
# - role: haproxy # init haproxy
# tags: [proxy, haproxy]
#
# - role: vip # init haproxy
# tags: [proxy, vip]
#
...
使用以下命令可以列出所有基础设施初始化会执行的任务，以及可以使用的标签：
./infra.yml --list-tasks
默认任务如下：
playbook: ./infra.yml
play #1 (meta): Init local repo TAGS: [repo]
tasks:
repo : Create local repo directory TAGS: [repo, repo_dir]
repo : Backup & remove existing repos TAGS: [repo, repo_upstream]
repo : Add required upstream repos TAGS: [repo, repo_upstream]
repo : Check repo pkgs cache exists TAGS: [repo, repo_prepare]
repo : Set fact whether repo_exists TAGS: [repo, repo_prepare]
repo : Move upstream repo to backup TAGS: [repo, repo_prepare]
repo : Add local file system repos TAGS: [repo, repo_prepare]
repo : Remake yum cache if not exists TAGS: [repo, repo_prepare]
repo : Install repo bootstrap packages TAGS: [repo, repo_boot]
repo : Render repo nginx server files TAGS: [repo, repo_nginx]
repo : Disable selinux for repo server TAGS: [repo, repo_nginx]
repo : Launch repo nginx server TAGS: [repo, repo_nginx]
repo : Waits repo server online TAGS: [repo, repo_nginx]
repo : Download web url packages TAGS: [repo, repo_download]
repo : Download repo packages TAGS: [repo, repo_download]
repo : Download repo pkg deps TAGS: [repo, repo_download]
repo : Create local repo index TAGS: [repo, repo_download]
repo : Copy bootstrap scripts TAGS: [repo, repo_download, repo_script]
repo : Mark repo cache as valid TAGS: [repo, repo_download]
play #2 (meta): Provision Node TAGS: [node]
tasks:
node : Update node hostname TAGS: [node, node_name]
node : Add new hostname to /etc/hosts TAGS: [node, node_name]
node : Write static dns records TAGS: [node, node_dns]
node : Get old nameservers TAGS: [node, node_resolv]
node : Truncate resolv file TAGS: [node, node_resolv]
node : Write resolv options TAGS: [node, node_resolv]
node : Add new nameservers TAGS: [node, node_resolv]
node : Append old nameservers TAGS: [node, node_resolv]
node : Node configure disable firewall TAGS: [node, node_firewall]
node : Node disable selinux by default TAGS: [node, node_firewall]
node : Backup existing repos TAGS: [node, node_repo]
node : Install upstream repo TAGS: [node, node_repo]
node : Install local repo TAGS: [node, node_repo]
node : Install node basic packages TAGS: [node, node_pkgs]
node : Install node extra packages TAGS: [node, node_pkgs]
node : Install meta specific packages TAGS: [node, node_pkgs]
node : Install node basic packages TAGS: [node, node_pkgs]
node : Install node extra packages TAGS: [node, node_pkgs]
node : Install meta specific packages TAGS: [node, node_pkgs]
node : Node configure disable numa TAGS: [node, node_feature]
node : Node configure disable swap TAGS: [node, node_feature]
node : Node configure unmount swap TAGS: [node, node_feature]
node : Node setup static network TAGS: [node, node_feature]
node : Node configure disable firewall TAGS: [node, node_feature]
node : Node configure disk prefetch TAGS: [node, node_feature]
node : Enable linux kernel modules TAGS: [node, node_kernel]
node : Enable kernel module on reboot TAGS: [node, node_kernel]
node : Get config parameter page count TAGS: [node, node_tuned]
node : Get config parameter page size TAGS: [node, node_tuned]
node : Tune shmmax and shmall via mem TAGS: [node, node_tuned]
node : Create tuned profiles TAGS: [node, node_tuned]
node : Render tuned profiles TAGS: [node, node_tuned]
node : Active tuned profile TAGS: [node, node_tuned]
node : Change additional sysctl params TAGS: [node, node_tuned]
node : Copy default user bash profile TAGS: [node, node_profile]
node : Setup node default pam ulimits TAGS: [node, node_ulimit]
node : Create os user group admin TAGS: [node, node_admin]
node : Create os user admin TAGS: [node, node_admin]
node : Grant admin group nopass sudo TAGS: [node, node_admin]
node : Add no host checking to ssh config TAGS: [node, node_admin]
node : Add admin ssh no host checking TAGS: [node, node_admin]
node : Fetch all admin public keys TAGS: [node, node_admin]
node : Exchange all admin ssh keys TAGS: [node, node_admin]
node : Install public keys TAGS: [node, node_admin]
node : Install ntp package TAGS: [node, ntp_install]
node : Install chrony package TAGS: [node, ntp_install]
node : Setup default node timezone TAGS: [node, ntp_config]
node : Copy the ntp.conf file TAGS: [node, ntp_config]
node : Copy the chrony.conf template TAGS: [node, ntp_config]
node : Launch ntpd service TAGS: [node, ntp_launch]
node : Launch chronyd service TAGS: [node, ntp_launch]
play #3 (meta): Init meta service TAGS: [meta]
tasks:
ca : Create local ca directory TAGS: [ca, ca_dir, meta]
ca : Copy ca cert from local files TAGS: [ca, ca_copy, meta]
ca : Check ca key cert exists TAGS: [ca, ca_create, meta]
ca : Create self-signed CA key-cert TAGS: [ca, ca_create, meta]
nameserver : Make sure dnsmasq package installed TAGS: [meta, nameserver]
nameserver : Copy dnsmasq /etc/dnsmasq.d/config TAGS: [meta, nameserver]
nameserver : Add dynamic dns records to meta TAGS: [meta, nameserver]
nameserver : Launch meta dnsmasq service TAGS: [meta, nameserver]
nameserver : Wait for meta dnsmasq online TAGS: [meta, nameserver]
nameserver : Register consul dnsmasq service TAGS: [meta, nameserver]
nameserver : Reload consul TAGS: [meta, nameserver]
nginx : Make sure nginx package installed TAGS: [meta, nginx, nginx_install]
nginx : Create local html directory TAGS: [meta, nginx, nginx_dir]
nginx : Update default nginx index page TAGS: [meta, nginx, nginx_dir]
nginx : Copy nginx default config TAGS: [meta, nginx, nginx_config]
nginx : Copy nginx upstream conf TAGS: [meta, nginx, nginx_config]
nginx : Fetch haproxy facts TAGS: [meta, nginx, nginx_config, nginx_haproxy]
nginx : Templating /etc/nginx/haproxy.conf TAGS: [meta, nginx, nginx_config, nginx_haproxy]
nginx : Templating haproxy.html TAGS: [meta, nginx, nginx_config, nginx_haproxy]
nginx : Launch nginx server TAGS: [meta, nginx, nginx_reload]
nginx : Restart meta nginx service TAGS: [meta, nginx, nginx_launch]
nginx : Wait for nginx service online TAGS: [meta, nginx, nginx_launch]
nginx : Make sure nginx exporter installed TAGS: [meta, nginx, nginx_exporter]
nginx : Config nginx_exporter options TAGS: [meta, nginx, nginx_exporter]
nginx : Restart nginx_exporter service TAGS: [meta, nginx, nginx_exporter]
nginx : Wait for nginx exporter online TAGS: [meta, nginx, nginx_exporter]
nginx : Register cosnul nginx service TAGS: [meta, nginx, nginx_register]
nginx : Register consul nginx-exporter service TAGS: [meta, nginx, nginx_register]
nginx : Reload consul TAGS: [meta, nginx, nginx_register]
prometheus : Install prometheus and alertmanager TAGS: [meta, prometheus, prometheus_install]
prometheus : Wipe out prometheus config dir TAGS: [meta, prometheus, prometheus_clean]
prometheus : Wipe out existing prometheus data TAGS: [meta, prometheus, prometheus_clean]
prometheus : Create postgres directory structure TAGS: [meta, prometheus, prometheus_config]
prometheus : Copy prometheus bin scripts TAGS: [meta, prometheus, prometheus_config]
prometheus : Copy prometheus rules scripts TAGS: [meta, prometheus, prometheus_config]
prometheus : Copy altermanager config TAGS: [meta, prometheus, prometheus_config]
prometheus : Render prometheus config TAGS: [meta, prometheus, prometheus_config]
prometheus : Config /etc/prometheus opts TAGS: [meta, prometheus, prometheus_config]
prometheus : Fetch prometheus static monitoring targets TAGS: [meta, prometheus, prometheus_config, prometheus_targets]
prometheus : Render prometheus static targets TAGS: [meta, prometheus, prometheus_config, prometheus_targets]
prometheus : Launch prometheus service TAGS: [meta, prometheus, prometheus_launch]
prometheus : Launch alertmanager service TAGS: [meta, prometheus, prometheus_launch]
prometheus : Wait for prometheus online TAGS: [meta, prometheus, prometheus_launch]
prometheus : Wait for alertmanager online TAGS: [meta, prometheus, prometheus_launch]
prometheus : Reload prometheus service TAGS: [meta, prometheus, prometheus_reload]
prometheus : Copy prometheus service definition TAGS: [meta, prometheus, prometheus_register]
prometheus : Copy alertmanager service definition TAGS: [meta, prometheus, prometheus_register]
prometheus : Reload consul to register prometheus TAGS: [meta, prometheus, prometheus_register]
grafana : Make sure grafana is installed TAGS: [grafana, grafana_install, meta]
grafana : Check grafana plugin cache exists TAGS: [grafana, grafana_plugin, meta]
grafana : Provision grafana plugins via cache TAGS: [grafana, grafana_plugin, meta]
grafana : Download grafana plugins from web TAGS: [grafana, grafana_plugin, meta]
grafana : Download grafana plugins from web TAGS: [grafana, grafana_plugin, meta]
grafana : Create grafana plugins cache TAGS: [grafana, grafana_plugin, meta]
grafana : Copy /etc/grafana/grafana.ini TAGS: [grafana, grafana_config, meta]
grafana : Remove grafana provision dir TAGS: [grafana, grafana_config, meta]
grafana : Copy provisioning content TAGS: [grafana, grafana_config, meta]
grafana : Copy pigsty dashboards TAGS: [grafana, grafana_config, meta]
grafana : Copy pigsty icon image TAGS: [grafana, grafana_config, meta]
grafana : Replace grafana icon with pigsty TAGS: [grafana, grafana_config, grafana_customize, meta]
grafana : Launch grafana service TAGS: [grafana, grafana_launch, meta]
grafana : Wait for grafana online TAGS: [grafana, grafana_launch, meta]
grafana : Update grafana default preferences TAGS: [grafana, grafana_provision, meta]
grafana : Register consul grafana service TAGS: [grafana, grafana_register, meta]
grafana : Reload consul TAGS: [grafana, grafana_register, meta]
play #4 (meta): Init dcs TAGS: []
tasks:
consul : Check for existing consul TAGS: [consul_check, dcs]
consul : Consul exists flag fact set TAGS: [consul_check, dcs]
consul : Abort due to consul exists TAGS: [consul_check, dcs]
consul : Clean existing consul instance TAGS: [consul_clean, dcs]
consul : Stop any running consul instance TAGS: [consul_clean, dcs]
consul : Remove existing consul dir TAGS: [consul_clean, dcs]
consul : Recreate consul dir TAGS: [consul_clean, dcs]
consul : Make sure consul is installed TAGS: [consul_install, dcs]
consul : Make sure consul dir exists TAGS: [consul_config, dcs]
consul : Get dcs server node names TAGS: [consul_config, dcs]
consul : Get dcs node name from var TAGS: [consul_config, dcs]
consul : Get dcs node name from var TAGS: [consul_config, dcs]
consul : Fetch hostname as dcs node name TAGS: [consul_config, dcs]
consul : Get dcs name from hostname TAGS: [consul_config, dcs]
consul : Copy /etc/consul.d/consul.json TAGS: [consul_config, dcs]
consul : Copy consul agent service TAGS: [consul_config, dcs]
consul : Get dcs bootstrap expect quroum TAGS: [consul_server, dcs]
consul : Copy consul server service unit TAGS: [consul_server, dcs]
consul : Launch consul server service TAGS: [consul_server, dcs]
consul : Wait for consul server online TAGS: [consul_server, dcs]
consul : Launch consul agent service TAGS: [consul_agent, dcs]
consul : Wait for consul agent online TAGS: [consul_agent, dcs]
play #5 (meta): Copy ansible scripts TAGS: [ansible]
tasks:
Create ansible tarball TAGS: [ansible]
Create ansible directory TAGS: [ansible]
Copy ansible tarball TAGS: [ansible]
Extract tarball TAGS: [ansible]
完成了基础设施部署后，用户可以通过pgsql.yml完成数据库集群的部署。
首先在 Pigsty配置文件 中完成数据库集群的定义，然后通过执行pgsql.yml将变更应用至实际环境中。
./pgsql.yml # 在所有清单中的机器上执行数据库集群初始化操作（危险！）
./pgsql.yml -l pg-test # 在 pg-test 分组下的机器执行数据库集群初始化（推荐！）
./pgsql.yml -l pg-meta,pg-test # 同时初始化pg-meta与pg-test两个集群
./pgsql.yml -l 10.10.10.11 # 初始化10.10.10.11这台机器上的数据库实例
使用不带参数的pgsql.yml虽然很方便，但在生产环境中是一个高危操作
强烈建议您在执行时添加-l参数，限制命令执行的对象范围。
用户可以将元节点当成普通节点复用，即在元节点上定义并创建PostgreSQL数据库。
默认沙箱环境中，执行./pgsql.yml会同时完成pg-meta与pg-test的初始化工作。
单独针对集群从库执行初始化时，用户必须自行确保主库必须已经完成初始化，主库与其从库同时进行初始化则无此要求。
pgsql.yml提供保护机制，由配置参数pg_exists_action决定。当执行剧本前会目标机器上有正在运行的PostgreSQL实例时，Pigsty会根据pg_exists_action的配置abort|clean|skip行动。
abort：建议设置为默认配置，如遇现存实例，中止剧本执行，避免误删库。clean：建议在本地沙箱环境使用，如遇现存实例，清除已有数据库。skip： 直接在已有数据库集群上执行后续逻辑。./pgsql.yml -e pg_exists_action=clean的方式来覆盖配置文件选项，强制抹掉现有实例pg_disable_purge选项提供了双重保护，如果启用该选项，则``pg_exists_action会被强制设置为abort`，在任何情况下都不会抹掉运行中的数据库实例。
``dcs_exists_action与dcs_disable_purge`与上述两个选项效果一致，但针对DCS（Consul Agent）实例。
用户可以通过ansible的标签机制，可以选择执行剧本的一个子集。
举个例子，如果只想执行负载均衡初始化的部分，则可以通过以下命令进行
./pgsql.yml --tags=haproxy
常用的命令子集如下：
./pgsql.yml --tags=infra # 完成基础设施的初始化，包括机器节点初始化与DCS部署
./pgsql.yml --tags=node # 完成机器节点的初始化
./pgsql.yml --tags=dcs # 完成DCS：consul/etcd的初始化
./pgsql.yml --tags=dcs -e dcs_exists_action # 完成consul/etcd的初始化，抹除已有的consul agent
./pgsql.yml --tags=pgsql # 完成数据库与监控的部署
./pgsql.yml --tags=postgres # 完成数据库部署
./pgsql.yml --tags=monitor # 完成监控的部署
./pgsql.yml --tags=pg_biz_init,pg_biz_pgbouncer # 修改数据库与用户定义并应用。
./pgsql.yml --tags=proxy # 完成负载均衡器的部署，包括Haproxy与VIP
./pgsql.yml --tags=haproxy # 完成Haproxy的部署
./pgsql.yml --tags=vip # 完成VIP的部署
./pgsql.yml --tags=haproxy_config,haproxy_reload # 修改Haproxy配置并应用。
pgsql.yml 主要完成以下工作：
node）consul）。postgres）monitor）haproxy）vip）精确到任务的标签请参考任务详情
#!/usr/bin/env ansible-playbook
---
#==============================================================#
# File : pgsql.yml
# Mtime : 2020-05-12
# Mtime : 2020-12-22
# Desc : initialize pigsty cluster
# Path : pgsql.yml
# Copyright (C) 2018-2021 Ruohang Feng
#==============================================================#
#------------------------------------------------------------------------------
# init node and database
#------------------------------------------------------------------------------
- name: Pgsql Initialization
become: yes
hosts: all
gather_facts: no
roles:
- role: node # init node
tags: [infra, node]
- role: consul # init consul
tags: [infra, dcs]
- role: postgres # init postgres
tags: [pgsql, postgres]
- role: monitor # init monitor system
tags: [pgsql, monitor]
- role: haproxy # init haproxy
tags: [proxy, haproxy]
- role: vip # init haproxy
tags: [proxy, vip]
...
使用以下命令可以列出数据库集群初始化的所有任务，以及可以使用的标签：
./pgsql.yml --list-tasks
默认任务如下：
playbook: ./pgsql.yml
play #1 (all): Pgsql Initialization TAGS: []
tasks:
node : Update node hostname TAGS: [infra, node, node_name]
node : Add new hostname to /etc/hosts TAGS: [infra, node, node_name]
node : Write static dns records TAGS: [infra, node, node_dns]
node : Get old nameservers TAGS: [infra, node, node_resolv]
node : Truncate resolv file TAGS: [infra, node, node_resolv]
node : Write resolv options TAGS: [infra, node, node_resolv]
node : Add new nameservers TAGS: [infra, node, node_resolv]
node : Append old nameservers TAGS: [infra, node, node_resolv]
node : Node configure disable firewall TAGS: [infra, node, node_firewall]
node : Node disable selinux by default TAGS: [infra, node, node_firewall]
node : Backup existing repos TAGS: [infra, node, node_repo]
node : Install upstream repo TAGS: [infra, node, node_repo]
node : Install local repo TAGS: [infra, node, node_repo]
node : Install node basic packages TAGS: [infra, node, node_pkgs]
node : Install node extra packages TAGS: [infra, node, node_pkgs]
node : Install meta specific packages TAGS: [infra, node, node_pkgs]
node : Install node basic packages TAGS: [infra, node, node_pkgs]
node : Install node extra packages TAGS: [infra, node, node_pkgs]
node : Install meta specific packages TAGS: [infra, node, node_pkgs]
node : Node configure disable numa TAGS: [infra, node, node_feature]
node : Node configure disable swap TAGS: [infra, node, node_feature]
node : Node configure unmount swap TAGS: [infra, node, node_feature]
node : Node setup static network TAGS: [infra, node, node_feature]
node : Node configure disable firewall TAGS: [infra, node, node_feature]
node : Node configure disk prefetch TAGS: [infra, node, node_feature]
node : Enable linux kernel modules TAGS: [infra, node, node_kernel]
node : Enable kernel module on reboot TAGS: [infra, node, node_kernel]
node : Get config parameter page count TAGS: [infra, node, node_tuned]
node : Get config parameter page size TAGS: [infra, node, node_tuned]
node : Tune shmmax and shmall via mem TAGS: [infra, node, node_tuned]
node : Create tuned profiles TAGS: [infra, node, node_tuned]
node : Render tuned profiles TAGS: [infra, node, node_tuned]
node : Active tuned profile TAGS: [infra, node, node_tuned]
node : Change additional sysctl params TAGS: [infra, node, node_tuned]
node : Copy default user bash profile TAGS: [infra, node, node_profile]
node : Setup node default pam ulimits TAGS: [infra, node, node_ulimit]
node : Create os user group admin TAGS: [infra, node, node_admin]
node : Create os user admin TAGS: [infra, node, node_admin]
node : Grant admin group nopass sudo TAGS: [infra, node, node_admin]
node : Add no host checking to ssh config TAGS: [infra, node, node_admin]
node : Add admin ssh no host checking TAGS: [infra, node, node_admin]
node : Fetch all admin public keys TAGS: [infra, node, node_admin]
node : Exchange all admin ssh keys TAGS: [infra, node, node_admin]
node : Install public keys TAGS: [infra, node, node_admin]
node : Install ntp package TAGS: [infra, node, ntp_install]
node : Install chrony package TAGS: [infra, node, ntp_install]
node : Setup default node timezone TAGS: [infra, node, ntp_config]
node : Copy the ntp.conf file TAGS: [infra, node, ntp_config]
node : Copy the chrony.conf template TAGS: [infra, node, ntp_config]
node : Launch ntpd service TAGS: [infra, node, ntp_launch]
node : Launch chronyd service TAGS: [infra, node, ntp_launch]
consul : Check for existing consul TAGS: [consul_check, dcs, infra]
consul : Consul exists flag fact set TAGS: [consul_check, dcs, infra]
consul : Abort due to consul exists TAGS: [consul_check, dcs, infra]
consul : Clean existing consul instance TAGS: [consul_clean, dcs, infra]
consul : Stop any running consul instance TAGS: [consul_clean, dcs, infra]
consul : Remove existing consul dir TAGS: [consul_clean, dcs, infra]
consul : Recreate consul dir TAGS: [consul_clean, dcs, infra]
consul : Make sure consul is installed TAGS: [consul_install, dcs, infra]
consul : Make sure consul dir exists TAGS: [consul_config, dcs, infra]
consul : Get dcs server node names TAGS: [consul_config, dcs, infra]
consul : Get dcs node name from var TAGS: [consul_config, dcs, infra]
consul : Get dcs node name from var TAGS: [consul_config, dcs, infra]
consul : Fetch hostname as dcs node name TAGS: [consul_config, dcs, infra]
consul : Get dcs name from hostname TAGS: [consul_config, dcs, infra]
consul : Copy /etc/consul.d/consul.json TAGS: [consul_config, dcs, infra]
consul : Copy consul agent service TAGS: [consul_config, dcs, infra]
consul : Get dcs bootstrap expect quroum TAGS: [consul_server, dcs, infra]
consul : Copy consul server service unit TAGS: [consul_server, dcs, infra]
consul : Launch consul server service TAGS: [consul_server, dcs, infra]
consul : Wait for consul server online TAGS: [consul_server, dcs, infra]
consul : Launch consul agent service TAGS: [consul_agent, dcs, infra]
consul : Wait for consul agent online TAGS: [consul_agent, dcs, infra]
postgres : Create os group postgres TAGS: [instal, pg_dbsu, pgsql, postgres]
postgres : Make sure dcs group exists TAGS: [instal, pg_dbsu, pgsql, postgres]
postgres : Create dbsu {{ pg_dbsu }} TAGS: [instal, pg_dbsu, pgsql, postgres]
postgres : Grant dbsu nopass sudo TAGS: [instal, pg_dbsu, pgsql, postgres]
postgres : Grant dbsu all sudo TAGS: [instal, pg_dbsu, pgsql, postgres]
postgres : Grant dbsu limited sudo TAGS: [instal, pg_dbsu, pgsql, postgres]
postgres : Config patroni watchdog support TAGS: [instal, pg_dbsu, pgsql, postgres]
postgres : Add dbsu ssh no host checking TAGS: [instal, pg_dbsu, pgsql, postgres]
postgres : Fetch dbsu public keys TAGS: [instal, pg_dbsu, pgsql, postgres]
postgres : Exchange dbsu ssh keys TAGS: [instal, pg_dbsu, pgsql, postgres]
postgres : Install offical pgdg yum repo TAGS: [instal, pg_install, pgsql, postgres]
postgres : Install pg packages TAGS: [instal, pg_install, pgsql, postgres]
postgres : Install pg extensions TAGS: [instal, pg_install, pgsql, postgres]
postgres : Link /usr/pgsql to current version TAGS: [instal, pg_install, pgsql, postgres]
postgres : Add pg bin dir to profile path TAGS: [instal, pg_install, pgsql, postgres]
postgres : Fix directory ownership TAGS: [instal, pg_install, pgsql, postgres]
postgres : Remove default postgres service TAGS: [instal, pg_install, pgsql, postgres]
postgres : Check necessary variables exists TAGS: [always, pg_preflight, pgsql, postgres, preflight]
postgres : Fetch variables via pg_cluster TAGS: [always, pg_preflight, pgsql, postgres, preflight]
postgres : Set cluster basic facts for hosts TAGS: [always, pg_preflight, pgsql, postgres, preflight]
postgres : Assert cluster primary singleton TAGS: [always, pg_preflight, pgsql, postgres, preflight]
postgres : Setup cluster primary ip address TAGS: [always, pg_preflight, pgsql, postgres, preflight]
postgres : Setup repl upstream for primary TAGS: [always, pg_preflight, pgsql, postgres, preflight]
postgres : Setup repl upstream for replicas TAGS: [always, pg_preflight, pgsql, postgres, preflight]
postgres : Debug print instance summary TAGS: [always, pg_preflight, pgsql, postgres, preflight]
postgres : Check for existing postgres instance TAGS: [pg_check, pgsql, postgres, prepare]
postgres : Set fact whether pg port is open TAGS: [pg_check, pgsql, postgres, prepare]
postgres : Abort due to existing postgres instance TAGS: [pg_check, pgsql, postgres, prepare]
postgres : Clean existing postgres instance TAGS: [pg_check, pgsql, postgres, prepare]
postgres : Shutdown existing postgres service TAGS: [pg_clean, pgsql, postgres, prepare]
postgres : Remove registerd consul service TAGS: [pg_clean, pgsql, postgres, prepare]
postgres : Remove postgres metadata in consul TAGS: [pg_clean, pgsql, postgres, prepare]
postgres : Remove existing postgres data TAGS: [pg_clean, pgsql, postgres, prepare]
postgres : Make sure main and backup dir exists TAGS: [pg_dir, pgsql, postgres, prepare]
postgres : Create postgres directory structure TAGS: [pg_dir, pgsql, postgres, prepare]
postgres : Create pgbouncer directory structure TAGS: [pg_dir, pgsql, postgres, prepare]
postgres : Create links from pgbkup to pgroot TAGS: [pg_dir, pgsql, postgres, prepare]
postgres : Create links from current cluster TAGS: [pg_dir, pgsql, postgres, prepare]
postgres : Copy pg_cluster to /pg/meta/cluster TAGS: [pg_meta, pgsql, postgres, prepare]
postgres : Copy pg_version to /pg/meta/version TAGS: [pg_meta, pgsql, postgres, prepare]
postgres : Copy pg_instance to /pg/meta/instance TAGS: [pg_meta, pgsql, postgres, prepare]
postgres : Copy pg_seq to /pg/meta/sequence TAGS: [pg_meta, pgsql, postgres, prepare]
postgres : Copy pg_role to /pg/meta/role TAGS: [pg_meta, pgsql, postgres, prepare]
postgres : Copy postgres scripts to /pg/bin/ TAGS: [pg_scripts, pgsql, postgres, prepare]
postgres : Copy alias profile to /etc/profile.d TAGS: [pg_scripts, pgsql, postgres, prepare]
postgres : Copy psqlrc to postgres home TAGS: [pg_scripts, pgsql, postgres, prepare]
postgres : Setup hostname to pg instance name TAGS: [pg_hostname, pgsql, postgres, prepare]
postgres : Copy consul node-meta definition TAGS: [pg_nodemeta, pgsql, postgres, prepare]
postgres : Restart consul to load new node-meta TAGS: [pg_nodemeta, pgsql, postgres, prepare]
postgres : Config patroni watchdog support TAGS: [pg_watchdog, pgsql, postgres, prepare]
postgres : Get config parameter page count TAGS: [pg_config, pgsql, postgres]
postgres : Get config parameter page size TAGS: [pg_config, pgsql, postgres]
postgres : Tune shared buffer and work mem TAGS: [pg_config, pgsql, postgres]
postgres : Hanlde small size mem occasion TAGS: [pg_config, pgsql, postgres]
postgres : Calculate postgres mem params TAGS: [pg_config, pgsql, postgres]
postgres : create patroni config dir TAGS: [pg_config, pgsql, postgres]
postgres : use predefined patroni template TAGS: [pg_config, pgsql, postgres]
postgres : Render default /pg/conf/patroni.yml TAGS: [pg_config, pgsql, postgres]
postgres : Link /pg/conf/patroni to /pg/bin/ TAGS: [pg_config, pgsql, postgres]
postgres : Link /pg/bin/patroni.yml to /etc/patroni/ TAGS: [pg_config, pgsql, postgres]
postgres : Config patroni watchdog support TAGS: [pg_config, pgsql, postgres]
postgres : create patroni systemd drop-in dir TAGS: [pg_config, pgsql, postgres]
postgres : Copy postgres systemd service file TAGS: [pg_config, pgsql, postgres]
postgres : create patroni systemd drop-in file TAGS: [pg_config, pgsql, postgres]
postgres : Render default initdb scripts TAGS: [pg_config, pgsql, postgres]
postgres : Launch patroni on primary instance TAGS: [pg_primary, pgsql, postgres]
postgres : Wait for patroni primary online TAGS: [pg_primary, pgsql, postgres]
postgres : Wait for postgres primary online TAGS: [pg_primary, pgsql, postgres]
postgres : Check primary postgres service ready TAGS: [pg_primary, pgsql, postgres]
postgres : Check replication connectivity to primary TAGS: [pg_primary, pgsql, postgres]
postgres : Render default pg-init scripts TAGS: [pg_init, pg_init_config, pgsql, postgres]
postgres : Render template init script TAGS: [pg_init, pg_init_config, pgsql, postgres]
postgres : Execute initialization scripts TAGS: [pg_init, pgsql, postgres]
postgres : Check primary instance ready TAGS: [pg_init, pgsql, postgres]
postgres : Add dbsu password to pgpass if exists TAGS: [pg_pass, pgsql, postgres]
postgres : Add system user to pgpass TAGS: [pg_pass, pgsql, postgres]
postgres : Check replication connectivity to primary TAGS: [pg_replica, pgsql, postgres]
postgres : Launch patroni on replica instances TAGS: [pg_replica, pgsql, postgres]
postgres : Wait for patroni replica online TAGS: [pg_replica, pgsql, postgres]
postgres : Wait for postgres replica online TAGS: [pg_replica, pgsql, postgres]
postgres : Check replica postgres service ready TAGS: [pg_replica, pgsql, postgres]
postgres : Render hba rules TAGS: [pg_hba, pgsql, postgres]
postgres : Reload hba rules TAGS: [pg_hba, pgsql, postgres]
postgres : Pause patroni TAGS: [pg_patroni, pgsql, postgres]
postgres : Stop patroni on replica instance TAGS: [pg_patroni, pgsql, postgres]
postgres : Stop patroni on primary instance TAGS: [pg_patroni, pgsql, postgres]
postgres : Launch raw postgres on primary TAGS: [pg_patroni, pgsql, postgres]
postgres : Launch raw postgres on primary TAGS: [pg_patroni, pgsql, postgres]
postgres : Wait for postgres online TAGS: [pg_patroni, pgsql, postgres]
postgres : Check pgbouncer is installed TAGS: [pgbouncer, pgbouncer_check, pgsql, postgres]
postgres : Stop existing pgbouncer service TAGS: [pgbouncer, pgbouncer_clean, pgsql, postgres]
postgres : Remove existing pgbouncer dirs TAGS: [pgbouncer, pgbouncer_clean, pgsql, postgres]
postgres : Recreate dirs with owner postgres TAGS: [pgbouncer, pgbouncer_clean, pgsql, postgres]
postgres : Copy /etc/pgbouncer/pgbouncer.ini TAGS: [pgbouncer, pgbouncer_config, pgbouncer_ini, pgsql, postgres]
postgres : Copy /etc/pgbouncer/pgb_hba.conf TAGS: [pgbouncer, pgbouncer_config, pgbouncer_hba, pgsql, postgres]
postgres : Touch userlist and database list TAGS: [pgbouncer, pgbouncer_config, pgsql, postgres]
postgres : Add default users to pgbouncer TAGS: [pgbouncer, pgbouncer_config, pgsql, postgres]
postgres : Copy pgbouncer systemd service TAGS: [pgbouncer, pgbouncer_launch, pgsql, postgres]
postgres : Launch pgbouncer pool service TAGS: [pgbouncer, pgbouncer_launch, pgsql, postgres]
postgres : Wait for pgbouncer service online TAGS: [pgbouncer, pgbouncer_launch, pgsql, postgres]
postgres : Check pgbouncer service is ready TAGS: [pgbouncer, pgbouncer_launch, pgsql, postgres]
postgres : Render business init script TAGS: [business, pg_biz_config, pg_biz_init, pgsql, postgres]
postgres : Render database baseline sql TAGS: [business, pg_biz_config, pg_biz_init, pgsql, postgres]
postgres : Execute business init script TAGS: [business, pg_biz_init, pgsql, postgres]
postgres : Execute database baseline sql TAGS: [business, pg_biz_init, pgsql, postgres]
postgres : Add pgbouncer busniess users TAGS: [business, pg_biz_pgbouncer, pgsql, postgres]
postgres : Add pgbouncer busniess database TAGS: [business, pg_biz_pgbouncer, pgsql, postgres]
postgres : Restart pgbouncer TAGS: [business, pg_biz_pgbouncer, pgsql, postgres]
postgres : Copy pg service definition to consul TAGS: [pg_register, pgsql, postgres, register]
postgres : Reload postgres consul service TAGS: [pg_register, pgsql, postgres, register]
postgres : Render grafana datasource definition TAGS: [pg_grafana, pgsql, postgres, register]
postgres : Register datasource to grafana TAGS: [pg_grafana, pgsql, postgres, register]
monitor : Create /etc/pg_exporter conf dir TAGS: [monitor, pg_exporter, pgsql]
monitor : Copy default pg_exporter.yaml TAGS: [monitor, pg_exporter, pgsql]
monitor : Config /etc/default/pg_exporter TAGS: [monitor, pg_exporter, pgsql]
monitor : Copy pg_exporter binary TAGS: [monitor, pg_exporter, pg_exporter_binary, pgsql]
monitor : Config pg_exporter service unit TAGS: [monitor, pg_exporter, pgsql]
monitor : Launch pg_exporter systemd service TAGS: [monitor, pg_exporter, pgsql]
monitor : Wait for pg_exporter service online TAGS: [monitor, pg_exporter, pgsql]
monitor : Register pg-exporter consul service TAGS: [monitor, pg_exporter_register, pgsql]
monitor : Reload pg-exporter consul service TAGS: [monitor, pg_exporter_register, pgsql]
monitor : Config pgbouncer_exporter opts TAGS: [monitor, pgbouncer_exporter, pgsql]
monitor : Config pgbouncer_exporter service TAGS