多页打印视图 点击此处打印.

返回常规视图.

欢迎来到Pigsty中文文档 v1.5

最新版本: v1.5.1

Github Repo | Live Demo

中文文档 | English Docs

Pigsty是开箱即用的开源数据库发行版,以 PostgreSQL 为核心,打包TimescaleDBPostGISCitus与上百余+生态扩展插件, 整合了大规模生产环境所需的PaaS基础设施数据分析组件:将顶级DBA的经验沉淀为软件,一次性解决使用数据库时会遇到的各类问题。

Pigsty还是自动驾驶的运维解决方案,带有全面专业的监控系统,与简单易用的高可用数据库部署管控方案。用户只需声明自己想要什么样的数据库,即可将其一键创建:PostgreSQL / Redis / Greenplum

Pigsty是简单易用的开发者工具箱,无论是下载、安装、还是部署迁移备份恢复扩缩容,都能一键完成。基于Vagrant本地沙箱Terraform的多云部署能力,让Pigsty在所有环境中都能一键拉起,带来统一的使用体验。

Pigsty用途广泛,可支持各类上层SaaS应用或制作大屏/Demo。相比使用云数据库,数据安全自主可控,简运维、低成本、全功能、优体验,可以显著节省数据库运维人力,并节约 50% ~ 80% 的数据库综合成本。对各类企业用户、ISV、个人用户都具有显著的价值与吸引力。

点击上图查看更多关于Pigsty亮点特性的详细介绍

快速上手

点击图片查看快速上手指南:如何用三条命令,在您的服务器上安装Pigsty。

关于

Pigsty最开始的名字源于 “PostgreSQL In Graphic STYle” 的缩写,即 “图形化Postgres”。

pigsty 一词的的本意是猪圈,读作 Pig Style (/ˈpɪɡˌstaɪ/) 。

Pigsty基于Apache 2.0协议开源,可免费用于商业目的。但须遵守显著声明义务,禁止改装为所谓"自研产品"。

1 - 入门

快速了解Pigsty所解决的问题,采用的技术,适用的场景。

1.1 - Pigsty入门指南

从哪里开始?

不同的用户有不同的关注点,如果遇到问题,欢迎查阅FAQ,提交Issue,或向社区求助。

新用户

新接触PostgreSQL与Pigsty的用户,可以参阅 亮点特性了解Pigsty的功能,或访问Pigsty演示站点:http://demo.pigsty.cc 进行直观地交互式体验概览其功能。 如果您想自己动手试一试,可以按照 快速上手 中的介绍,一键在本地拉起一样的沙箱环境

Pigsty演示中内置了几个典型基于Pigsty开发的数据应用,用于演示此发型版的能力, 例如:pglogcovidisddbengworktime等, 此外,您还可以参考 Docker应用教程,使用Pigsty部署生产级的软件服务。

开发者(Dev)

开发者更关注的问题是:如何最快地下载安装接入数据库,请参考 快速上手

Pigsty针对易用性进行了大量优化,在全新CentOS 7.8节点上,无需互联网访问即可完成一键安装。

Pigsty提供了预置的 Vagrant & Terraform 模板,用于在本地x86笔记本/PC或云上一键拉起4台虚拟机,部署沙箱环境

用户也可以自行准备虚拟机,云虚拟机,或生产物理机器来进行标准部署流程。

Pigsty中的数据库,对外以服务的方式交付,用户通过PG连接串进行接入

部署完成后,开发者可以参考教程中的内容,熟悉基本管理操作,并了解访问数据库的方法,如果有问题

如果您想要深入了解Pigsty本身的设计与架构,可以参考概念一章中的主题:

运维人员 (OPS)

运维人员更关注实施部署的细节,以下教程将介绍Pigsty安装部署的细节:

其中,教程升级Grafana后端数据库展示了一个完整的,具有代表性的案例: 搭建并使用一套专供Grafana使用的Postgres数据库集群,将上述主题的内容付诸于实践。

管理员(DBA)

DBA通常更关注监控系统的用法与日常维护的具体方式。

监控系统教程

日常维护管理

专业用户

对于专业用户(深度定制,二次开发),Pigsty提供了丰富的配置项与定制接口。

几乎所有配置项都配置有合理的默认值,无需修改即可使用。专业用户可以参考配置项文档按需自行调整或按需定制

1.2 - Pigsty快速上手

三行命令拉起Pigsty

Pigsty有两种典型使用模式:单机安装集群管理,集群管理只是在单机安装上多做了几步工作。

  • 单机:在单个节点上安装Pigsty,将其作为开箱即用的Postgres数据库使用(开发测试)
  • 集群:在单机安装的基础上,部署、监控、管理其他节点与多种不同种类的数据库(运维管理)


单机安装

在一台节点上安装Pigsty时,Pigsty会在该节点上部署完整的基础设施运行时 与 一个单节点PostgreSQL数据库集群。对于个人用户、简单场景、小微企业来说,您可以直接开箱使用此数据库。

准备好新装机器(Linux x86_64 CentOS 7.8.2003)一台,配置管理用户ssh本机sudo访问,然后下载Pigsty

bash -c "$(curl -fsSL http://download.pigsty.cc/get)"  # 下载最新pigsty源代码
./download pkg                                         # 可选,下载离线软件包加速
cd ~/pigsty; ./configure                               # 根据当前环境生成配置
./infra.yml                                            # 在当前节点上完成安装

如果您有可用的Macbook/PC/笔记本或云厂商账号,可使用沙箱部署本机云端自动创建虚拟机。

执行完毕后,您已经在当前节点完成了Pigsty的安装,上面带有完整的基础设施与一个开箱即用的PostgreSQL数据库实例,当前节点的5432对外提供数据库服务,80端口对外提供所有WebUI类服务。

80端口为所有Web图形界面服务的访问端点。尽管可以绕过Nginx直接使用端口访问各项服务,例如3000端口的Grafana,但强烈建议用户通过在本机配置DNS的方式,使用域名访问各项Web子服务。

访问 http://g.pigstyhttp://<primary_ip>:3000 即可浏览 Pigsty监控系统主页

(用户名: admin, 密码: pigsty)


集群管理

Pigsty还可以用作大规模生产环境的集群/数据库管理。您可以从单机安装Pigsty的节点(将作为集群的元节点,或称作元节点/Meta)上发起控制,将更多的 机器节点 纳入Pigsty的管理与监控中。

更重要的是,Pigsty还可以在这些节点上部署并管理各式各样的数据库集群与应用:创建高可用的PostgreSQL数据库集群;创建不同类型的Redis集簇;部署 Greenplum/MatrixDB 数据仓库,并获取关于节点、数据库与应用的实时洞察。

# 在四节点本地沙箱/云端演示环境中,可以使用以下命令在其他三台节点上部署数据库集群
./nodes.yml  -l pg-test      # 初始化集群pg-test包含的三台机器节点(配置节点+纳入监控)
./pgsql.yml  -l pg-test      # 初始化高可用PGSQL数据库集群pg-test
./redis.yml  -l redis-test   # 初始化Redis集群 redis-test
./pigsty-matrixdb.yml -l mx-*  # 初始化MatrixDB集群mx-mdw,mx-sdw

1.3 - Pigsty用户界面

Pigsty提供的图形界面

完成安装后,可以通过浏览器访问Pigsty提供的图形用户界面。

http://g.pigsty -> http://10.10.10.10:80 (nginx) -> http://10.10.10.10:3000 (grafana)

访问 http://<node_ip>:3000 即可浏览 Pigsty 主页 (用户名: admin, 密码: pigsty)

您可以访问 http://demo.pigsty.cc 来查看公开Pigsty Demo,并浏览Pigsty监控系统提供的功能。

Web服务

Pigsty会通过Nginx 80端口统一代理Web类服务的访问,默认的域名与上游端口为:

组件 端口 默认域名 说明
Grafana 3000 g.pigsty Pigsty监控系统图形界面
Prometheus 9090 p.pigsty 监控时序数据库
Loki 3100 l.pigsty 日志收集服务端(无界面)
AlertManager 9093 a.pigsty 报警聚合管理组件
Consul 8500 c.pigsty 分布式配置管理,服务发现
Nginx 80 pigsty 所有服务的入口代理
Yum Repo 80 yum.pigsty 本地Yum源

更多详情,请参考 INFRA -> 配置 -> nginx_upstream

关于域名

用户可以为这些服务配置自己已有的域名,或使用make dns快捷方式将默认的域名写入/etc/hosts

用户仍然可以使用 IP:Port 的方式直接访问大部分服务,例如,Pigsty监控系统的入口即为元节点IP+3000端口。

更多关于准备域名的详情,请参考:部署 -> 准备 -> DNS域名配置

1.4 - Pigsty FAQ

这里列出了Pigsty用户常遇到的问题,如果您遇到了难以解决的问题,可以联系我们,或提交Issue

准备

您需要确保机器节点硬件规格与操作系统符合安装要求,详情参见:准备工作

机器节点要求

最小规格 1C/2GB,节点处理器为x86_64架构,目前不支持 ARM 架构。

安装Pigsty需要至少一个机器节点:规格至少为1核2GB,1核1G也可安装但容易OOM。

如果您希望部署自我管理的高可用PostgreSQL数据库集群,建议最少使用3个规格相同的节点。

操作系统要求

Pigsty强烈建议使用CentOS 7.8操作系统,可以节省大量无意义的DEBUG时间。

这是一个经过充分验证的操作系统版本,Pigsty开发、测试、打包都默认基于CentOS 7.8。CentOS 7.6也经过充分的验证。其他CentOS 7.x及其等效版本RHEL7 , Oracle Linux 7理论上没有问题,但并未进行测试与验证。

软件版本策略

请使用特定版本的Release,不要直接使用Github Master分支,该开发分支有可能处于不一致的状态。

Pigsty遵循语义版本号规则: <major>.<minor>.<release>。大版本更新意味着重大的根本性架构调整,次版本号增长意味着一次显著更新,通常意味着软件包版本更新,API的微小变动,以及其它增量功能变更,通常会包含一份升级注意事项说明。Release版本号通常用于Bug修复与文档更新,Release版本号增长不会变更软件包版本(即 v1.0.1 与 v1.0.0对应的 pkg.tgz是相同的)。

Pigsty计划会每1-3个月发布一个Minor Release,每1-2年发布一个Major Release。

沙箱虚拟机置备

使用Vagrant一键拉起基于本地虚拟机的本地沙箱,或使用Terraform在公有云厂商创建云端沙箱

部署Pigsty需要用到物理机/虚拟机节点,您可以直接自备物理机/虚拟机用于部署。但IaaS资源置备仍然是一件麻烦事,所以Pigsty提供了基于Vagrant与HashiCorp的IaaS层资源模板,您可以一键获取部署Pigsty4节点沙箱环境所需的虚拟机资源。

沙箱环境是一个配置规格、对象标识符、IP地址与默认数据库全部预先确定的环境,由一个元节点与三个普通节点组成,无论是本地版还是云端版都保持一致,用于开发/测试/演示/说明。使用以下命令拉起Vagrant本地沙箱:

make deps    # 安装homebrew,并通过homebrew安装vagrant与virtualbox(需重启)
make dns     # 向本机/etc/hosts写入静态域名 (需sudo输入密码)
make start   # 使用Vagrant拉起单个meta节点  (start4则为4个节点)

下载

Pigsty源码包是安装Pigsty时的必选项。离线软件包是可选的推荐项,情请参考 软件下载

如何下载Pigsty源码包

bash -c "$(curl -fsSL http://download.pigsty.cc/get)"

执行以上命令,可自动下载最新稳定版本 pigsty.tgz ,并解压至 ~/pigsty目录。您也可以从下列位置手工下载特定版本的Pigsty源码包,如果您需要在无互联网的环境中安装,可以提前下载并通过 scp/sftp 等方式上传至生产服务器。

https://github.com/Vonng/pigsty/releases/download/v1.5.1/pigsty.tgz   # Github Release 
http://download.pigsty.cc/v1.5.1/pigsty.tgz                           # 中国大陆用加速CDN
https://pan.baidu.com/s/1DZIa9X2jAxx69Zj-aRHoaw?pwd=8su9              # 百度云网盘下载

下载其他Pigsty软件包

./download pigsty pkg app matrix

Pigsty源码包内提供了一个download脚本,用于下载Pigsty相关资源:Pigsty源代码包本身:pigsty.tgz / 离线软件安装包:pkg.tgz / MatrixDB/Greenplum软件包:matrix.tgz / 一些SaaS应用镜像与可视化应用案例:app.tgz。其中源码包为必选项,离线软件包 pkg.tgz为建议项,使用 ./download pkg 会自动下载并提取离线软件包。

# download to /tmp/*.tgz
./download pigsty.tgz   # download pigsty source tarball
./download pkg.tgz      # download pigsty offline pkgs
./download app.tgz      # download extra pigsty apps
./download matrix.tgz   # download matrixdb packages
# download and extract
./download pigsty       # download and extract pigsty to ~/pigsty
./download pkg          # download and extract pkg    to /www/pigsty
./download app          # download and extract app    to ~/app
./download matrix       # download and extract matrix to /www/matrix

如何下载Pigsty离线软件包

./download pkg 或在配置过程中根据提示自动下载。

Pigsty的离线软件包 pkg.tgz 打包了所有所需的软件依赖。在执行Pigsty安装时如果使用离线软件包,可以跳过从互联网下载软件的步骤。

./configure 过程中,如果离线安装包/tmp/pkg.tgz不存在,向导会提示用户下载,回答“Y”即可自动从Github或CDN下载;回答“N”则会跳过下载。您也可以从下列位置手工下载离线软件包,并放置于 /tmp/pkg.tgz,则安装时会自动使用。

curl https://github.com/Vonng/pigsty/releases/download/v1.5.1/pkg.tgz -o /tmp/pkg.tgz
curl http://download.pigsty.cc/v1.5.1/pkg.tgz -o /tmp/pkg.tgz         # China CDN
https://pan.baidu.com/s/1DZIa9X2jAxx69Zj-aRHoaw?pwd=8su9              # Baidu Yun

离线软件包出现RPM冲突

不用离线包直接从上游下载,或仅删除问题包并从可用源补缺

Pigsty离线软件包基于CentOS 7.8操作系统制作,如果您使用的不是此精确OS Release,或者并未使用全新安装操作系统的节点进行安装,有小概率会出现RPM包依赖问题。

如果只是个别RPM依赖问题,您可以在 /www/pigsty 中删除相关RPM包,并删除标记文件 /www/pigsty/repo_complete。而后,执行常规的安装流程时,Pigsty会从 repo_upsteram 指定的上游或其他本地可用源下载缺失的依赖RPM包。如果您没有可用的互联网访问或本地源,请使用相同OS环境的有网节点制作离线软件包 后,拷贝至生产环境使用。


配置

Pigsty的安装、配置、部署都是一键傻瓜式,唯有配置是Pigsty的核心灵魂。

配置过程做了些什么

检测环境,生成配置,启用离线软件包(可选),安装基本工具Ansible。

当您下载完 Pigsty 源码包,解压并进入其中后,需要先执行 ./configure 完成环境配置过程

Pigsty会检测当前环境是否满足安装要求,并根据当前机器环境生成推荐配置文件 pigsty.yml。在files/conf/目录中,有一系列名为pigsty-*.yml的配置文件,可以作为不同场景下的配置参考模板,通过-m指定。

Configure过程会安装Ansible,一般节点的默认源都带有此软件包,如果离线安装包存在,则会从离线安装包内安装Ansible。

Pigsty的配置文件在哪

源码根目录下 pigsty.yml 是默认的、唯一的配置源。

Pigsty有且仅有一个配置文件pigsty.yml ,位于源代码根目录下,它描述了整个环境的状态。

在同一目录的ansible.cfg中:inventory = pigsty.yml 指定了此文件为默认配置文件,您也可以在执行剧本时,使用-i参数,指定使用其他位置的配置文件。此外,如果您使用CMDB作为配置源,那么请在CMDB中修改配置。

配置文件中的占位IP地址

Pigsty使用10.10.10.10作为当前节点IP地址占位符,将在配置过程中被替换为当前节点的首要IP地址。

当配置过程检测到当前机器上有多块网卡与多个IP地址时,配置向导会提示您输入主要使用的IP地址, 即用户从内部网络访问该节点时使用的IP地址,注意请不要使用公网IP地址。

该IP地址,将用于替换配置文件模板中的 10.10.10.10

用户需要修改什么配置吗?

单机部署通常啥配置也不用改,会自动调整,绝大多数参数都有合适的默认值。

Pigsty提供了220+配置参数,您可以定制整个基础设施/平台/数据库的方方面面。通常在单机安装的情况下,不需要对配置文件进行任何调整即可直接使用。但仍然有个别参数,如果有需要,可以提前调整:

  • 访问Web服务组件时使用的域名:nginx_upstream (一些服务只能使用域名通过Nginx代理访问)
  • Pigsty假设存在一个/data目录用于盛放所有数据,如果您的数据盘挂载点与此不同,可以调整这些路径。

安装

安装时执行了什么?

执行make install安装时,会调用ansible-playbook执行预置剧本 infra.yml,在元节点上完成安装。

configure过程默认会生成配置文件,并在其中将当前节点标记为 元节点。而make install则会针对元节点执行Pigsty元节点初始化剧本 infra.yml ,部署基础设施组件,并将元节点作为一个普通的节点进行初始化,并在其上部署一个单例PostgreSQL数据库作为CMDB。

下载RPM包速度太慢

如果直接从上游下不动,最好还是使用离线软件包,或者配置代理服务器,和可用本地镜像源。

Pigsty已经尽可能使用国内yum镜像进行下载,然而少量软件包仍然受到GFW的影响,导致下载缓慢,例如直接从Github下载的相关软件。有以下解决方案:

  1. Pigsty提供离线软件包,预先打包了所有软件及其依赖,可以跳过从互联网下载软件的步骤。

  2. 通过 proxy_env 指定代理服务器,通过代理服务器下载。

  3. 通过 repo_upsteram 使用其他国内可用的镜像源。

远端节点无法通过标准SSH命令访问

通过主机实例级 ansible连接参数,指定不一样的端口。

如果您的目标机器藏在SSH跳板机之后,或者进行了某些定制化修改无法通过ssh ip的方式直接访问,则可以考虑使用 Ansible连接参数。您可以通过 ansible_port指定其他SSH端口,或 ansible_host 指定SSH Alias。

pg-test:
  vars: { pg_cluster: pg-test }
  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_port: 22223, ansible_user: admin }
    10.10.10.13: {pg_seq: 3, pg_role: offline, ansible_port: 22224 }

远端节点SSH与SUDO需要密码

使用 -k-K参数,在提示符时输入密码,参考管理用户置备

执行部署与变更时,您所使用的管理用户必须拥有所有节点的sshsudo权限。免密码并非必需,您总是可以在执行剧本时通过-k|-K参数传入ssh与sudo的密码,甚至通过 -eansible_host=<another_user> 使用其他用户来执行剧本。但Pigsty强烈建议为管理用户配置SSH免密码登陆与免密码sudo


沙箱

Pigsty沙箱提供了标准的开发/测试/演示环境,可以在本地用Vagrant或云端用Terraform快速拉起。

Vagrant沙箱首次启动太慢

第一次使用Vagrant拉起某个操作系统镜像,会下载对应BOX。

Pigsty沙箱默认使用CentOS 7虚拟机,Vagrant首次启动虚拟机时,会下载CentOS/7的ISO镜像Box,尺寸不小。

使用代理可能会提高下载速度,下载CentOS7 Box只需要在首次启动沙箱时进行,后续重建沙箱时会直接复用。

用户也可以选择自行下载CentOS 7 安装ISO镜像手工创建所需虚拟机。

阿里云CentOS 7.8 RPM报错

阿里云CentOS 7.8 服务器默认安装了DNS缓存服务 nscd,移除即可。

阿里云的CentOS 7.8 服务器镜像默认安装了 nscd ,锁死了 glibc 版本,会导致安装时出现RPM依赖错误。

"Error: Package: nscd-2.17-307.el7.1.x86_64 (@base)"

在所有机器上执行 yum remove -y nscd 即可解决此问题,使用Ansible可以批量执行:

ansible all -b -a 'yum remove -y nscd'

虚拟机时间失去同步

sudo ntpdate -u pool.ntp.org 或使用 make sync4

Virtualbox虚拟机关机后虚拟机内时间可能与宿主机不一致。可以尝试使用以下命令:make sync,强制执行NTP时间同步。

sudo ntpdate -u pool.ntp.org
make sync4 # 使用NTP POOL时间同步快捷方式
make ss    # 使用阿里云NTP服务器同步

即可解决长时间休眠或关机重启后监控系统没有数据的问题。此外,重启虚拟机也可以强行重置时间,且无需互联网访问:make dw4; make up4

为什么不使用容器盛放数据库

使用Docker/Kubernetes盛放数据库仍然不成熟

虽然Docker对于提高环境兼容性有非常好的效果,然而数据库并不属于容器使用的最佳场景。此外Docker与Kubernetes本身也有使用门槛。为了满足“降低门槛”的主旨,Pigsty采用裸机部署。

Pigsty在设计之初就考虑到容器化云化的需求,这体现在其配置定义的声明式实现中。并不需要太多修改就可以迁移改造为云原生解决方案。当时机成熟时,会使用Kubernetes Operator的方式进行重构。


监控

监控系统的性能存储开销有多大

监控查询开销微不足道,百毫秒量级,10秒一次,普通实例约产生2k ~ 5k时间序列。

一个典型的生产实例,产出5千个时间序列,一次抓取大约耗时 200ms 左右;相比抓取周期15s几乎微不足道。

存储取决于用户数据库的复杂程度(workload)。作为参考:200个生产数据库实例1天产生的监控数据量约为16GB。Pigsty默认保留两周的监控数据,可以通过参数调整。

是否可以监控已有的PG实例?

Pigsty不承诺对外部实例的监控质量:Pigsty创建的PostgreSQL在绝大多数情况下表现显著优于土法手造实例

对于非Pigsty供给方案创建的外部数据库,可以使用仅监控模式部署,详情请参考文档。

如果该实例可以被Pigsty管理,您可以考虑采用与标准部署相同的方式,在目标节点上部署 node_exporter,pg_exporter, promtail 等组件。

如果您只有访问该数据库的URL(例如RDS云数据库实例),则可以使用 精简监控部署 模式,在该模式下,Pigsty会通过部署于元节点本地的 pg_exporter 实例监控远程PG实例。

监控已有PG实例需要怎么做?

监控对象被移除后为什么还能看到

使用 pgsql-remove.yml 剧本移除监控目标


INFRA

基础设施包括哪些组件?

Pigsty提供了一套完整的PaaS环境,详情请参考系统架构:基础设施

Ansible/Pigsty CLI用于发起管理与部署;元节点上的PostgreSQL作为CMDB;Consul Server作为元数据库用于高可用;NTPD与DNS提供时间与域名解析基础服务;Docker作为无状态应用部署底座;Prometheus用于监控指标时序数据收集,Loki用于日志收集;Grafana用于监控/可视化展示,AlertManager用于汇总告警;YumRepo用于提供本地软件源;Nginx对外收拢所有WebUI类服务访问入口。

是否可以使用已有的DCS集群

Pigsty默认会在元节点上提供DCS服务,但更推荐使用外部的多个节点组成的高可用DCS服务集群。

dcs_servers中填入对应的集群,即可使用外部的DCS集群。

DCS Server与元节点并没有对应关系:在默认情况下,Pigsty会在元节点上安装一个单节点的Consul Server。如果在执行节点初始化时当前节点的IP地址在 dcs_servers 中被定义,则该节点会配置DCS Server服务。DCS用于其他数据库实例的高可用选主。在生产环境中,建议使用3~5个节点的专用外部DCS集群。


NODES

Abort because consul instance already exists

Pigsty提供了DCS误删保护机制,配置dcs_clean = true 可以硬干。

当目标节点的Consul服务已经存在时,nodes.yml 会根据 dcs_clean 参数采取行动,如果为真,那么在初始化过程中现有的Consul会被抹除。

Pigsty也提供了相应的保护机制 参数: dcs_safeguard

您可以在配置文件 pigsty.yml 中修改这些参数,也可以直接在执行剧本时,通过额外参数机制指定:

./nodes.yml -e dcs_clean=true

PGSQL

Abort because postgres instance already exists

Pigsty提供了数据库误删保护机制,配置pg_clean = true 可以硬干。

当目标节点的PostgreSQL服务已经存在时,pgsql.yml 会根据 pg_clean 参数采取行动,如果为真,那么在初始化过程中现有的PostgreSQL实例会被抹除。

Pigsty也提供了相应的保护机制 参数: pg_safeguard

您可以在配置文件 pigsty.yml 中修改这些参数,也可以直接在执行剧本时,通过额外参数机制指定:

./pgsql.yml -e pg_clean=true

PostgreSQL数据库如何保证高可用

Patroni 作为HA Agent,Consul作为DCS,Haproxy作为默认流量分发器,详见高可用集群

Pigsty使用Patroni代管Postgres,Patroni使用Consul达成领导者共识,当主库故障超过阈值后(30秒),会触发新一轮领导者选举,获胜者成为新的集群主库,所有其他从库追随新的集群主库,原有故障主库上线后会自动降级为从库并追随新主库。

客户端使用HAProxy服务接入数据库,HAproxy使用HTTP健康检查从Patroni处获取主从角色信息,并依此分发流量。Pigsty的数据库集群成员在使用上幂等,只要集群还有任意一个实例存活,读写与只读流量都可以继续工作,访问任意一个实例的5433端口,都可以确保访问集群主库读写服务。

DCS自身的可用性通过多节点共识保证,故生产环境中建议部署3个或更多元节点,或使用外部的DCS集群。

如何确保PostgreSQL集群故障不丢数据

使用pg_conf: crit.yml 模板,或手工启用同步复制。

Crit模板针对数据一致性和持久性而优化,默认启用同步提交与数据校验和。可以确保在故障切换时没有任何数据损失,并能及时检测上报因存储故障、断电等其他异常情况导致的静默数据腐坏。

数据损坏导致拖从库失败

找到问题机器,修改 patroni 配置文件clonefrom: false并重载生效

Pigsty默认为PGSQL集群中的所有成员都启用 cloneform: true 功能,即,制作从库时可以从该实例上拖取基础备份。如果某个实例因为数据文件损坏无法完成从库制作,那么您可以修改该实例上的Patroni配置文件,将clonefrom设置为false,以避免从损坏的实例上拉取数据。

2 - 特性

快速了解Pigsty所解决的问题,采用的技术,适用的场景。

开箱即用的数据库发行版:用得上,用的好,用着简单还省钱!

自动驾驶高可用 / 极致入微可观测 / 简单易用门槛低 / 自由部署体验齐 / 应用广泛生态全 / 自主可控更省钱

PostgreSQL数据库发行版

RedHat for Linux! 开箱即用! 从无到有,让用户用得上

Pigsty将高可用集群部署,扩容缩容,主从复制,故障切换,流量代理,连接池,服务发现,访问控制,监控系统,告警系统,日志采集等生产级成熟解决方案封装为发行版。一次性解决在生产环境与各类场景下使用 世界上最先进的开源关系型数据库 —— PostgreSQL 时会遇到的各种问题,真正做到开箱即用。

智能监控管控运维解决方案

Auto-Pilot for Postgres! 自动驾驶! 从有到优,让用户用的爽

数据库即代码开发者工具箱

HashiCorp for Database! 简单易用!从优到易,让用户省心

  • Pigsty秉持 Infra as Data 的设计理念,用户只需用几行声明式的配置文件描述自己想要的数据库,即可使用幂等剧本,一键将其创建。Just like Kubernetes!

  • Pigsty向开发者交付简单易用的数据库工具箱:一键下载安装,自动配置;一键部署各类开源数据库,一键迁移备份、扩容缩容,极大拉低数据库管理使用门槛,量产DBA!

  • Pigsty能够简化数据库部署与交付、解决环境配置统一的难题:无论是上千套数据库几万核的生产环境,还是本地1C1G的笔记本均可完整运行;基于Vagrant的本地沙箱与基于Terraform的多云部署,云上云下,一键拉起!

开源云数据库PaaS替代方案

Alternative for RDS! 安全可控降本增效!从易到廉,给用户省钱

  • Pigsty相比云厂商RDS,在拥有更低使用⻔槛与更丰富功能的前提下,可节约 50% - 80% 的数据库软硬件成本,初级研发人员即可自主管理成百上千套数据库。

  • Pigsty采用模块化设计,可自由组合,按需定制扩展。可在生产环境部署管理各种数据库,或仅仅将其当成主机监控;可用于开发数据库可视化Demo、或支撑各类SaaS应用

  • 开源免费的生产级数据库解决方案,用于补全云原生生态缺失的最后一块拼图。稳定可靠,经过长时间大规模生产部署验证,提供可选的专业技术支持服务。

自动驾驶高可用

故障自愈,高枕无忧

以PostgreSQL为例,Pigsty创建的数据库集群是分布式高可用数据库集群。只要集群中有任意实例存活,集群就可以对外提供完整的读写服务只读服务

Pigsty的高可用架构久经生产环境考验,Pigsty使用 Patroni + Consul 进行故障检测、Fencing与自动故障切换,通过HAProxy、VIP或DNS实现流量的自动切换,以极低的复杂度代价实现了完整的高可用方案,让主从架构的数据库能用出了布式数据库般的体验。

数据库集群可以自动进行故障检测与主从切换,普通故障能在几秒到几十秒内自愈:主库故障RTO < 1min,只读流量几乎无影响,同步集群 RPO = 0 不丢数据。

数据库集群中的每个数据库实例在使用上都是幂等的,任意实例都可以通过内建负载均衡组件HAProxy提供完整的读写服务。任何一个或多个Haproxy实例都可以作为集群的负载均衡器,并通过健康检查进行流量分发,对外屏蔽集群成员的区别。用户可以通过配置灵活定义服务,并通过多种可选方式接入

极致入微可观测

You can’t manage you don’t measure.

监控系统提供了对系统状态的度量,是运维管理工作的基石。【DEMO

Pigsty带有一个针对大规模数据库集群管理而设计的专业级监控系统,基于业内最佳实践,采用Prometheus、Alertmanager、Grafana、Loki作为监控基础设施。开源开放,定制便利,可复用,可移植,没有厂商锁定。

Pigsty在PostgreSQL监控上做到无可比拟,通过30+监控面板与上千仪表盘综合呈现约1200+类指标,覆盖从全局大盘到单个对象的详细信息,从数据库目录到节点日志全部一览无遗。与同类产品相比在指标的覆盖率与监控面板丰富程度上一骑绝尘,为专业用户提供无可替代的价值。详略得当的层次设计,为业余用户带来直观便捷的管理体验。

Pigsty的监控系统可用于监控原生部署的各类数据库实例:PGSQL,REDIS,GPSQL等,也可以独立使用,监控已有的数据库实例或远端云厂商RDS,或仅仅作为主机监控使用,它还可以用作数据可视化作品的展示平台。

简单易用门槛低

HashiCorp for Database! Database as Code, Infra as Data!

Pigsty采纳 Database as Data 的设计哲学,使用类似 Kubernetes 的声明式配置,通过大量可选的配置选项对数据库与运行环境进行描述,并通过幂等的预置剧本自动创建所需的数据库集群,提供私有云般的使用体验。

用户只需要通过配置文件或图形界面描述“自己想要什么样的数据库”,而无需关心Pigsty如何去创建或修改它。Pigsty会根据用户的配置文件清单,在几分钟内从裸机节点上创造出所需的数据库集群。

例如,在三台机器上创建一主两从的数据库集群pg-test,只需要几行配置与一行命令pgsql.yml -l pg-test,即可创建出如下一节所介绍的高可用数据库集群。

使用更多参数对数据库集群进行定制
#----------------------------------#
# cluster: pg-meta (on meta node)  #
#----------------------------------#
# pg-meta is the default SINGLE-NODE pgsql cluster deployed on meta node (10.10.10.10)
# if you have multiple n meta nodes, consider deploying pg-meta as n-node cluster too

pg-meta:                                # required, ansible group name , pgsql cluster name. should be unique among environment
  hosts:                                # `<cluster>.hosts` holds instances definition of this cluster
    10.10.10.10:                        # INSTANCE-LEVEL CONFIG: ip address is the key. values are instance level config entries (dict)
      pg_seq: 1                         # required, unique identity parameter (+integer) among pg_cluster
      pg_role: primary                  # required, pg_role is mandatory identity parameter, primary|replica|offline|delayed
      pg_offline_query: true            # instance with `pg_offline_query: true` will take offline traffic (saga, etl,...)
      # some variables can be overwritten on instance level. e.g: pg_upstream, pg_weight, etc...
    #---------------
    # mandatory                         # all configuration above (`ip`, `pg_seq`, `pg_role`) and `pg_cluster` are mandatory
    #---------------
  vars:                                 # `<cluster>.vars` holds CLUSTER LEVEL CONFIG of this pgsql cluster
    pg_cluster: pg-meta                 # required, pgsql cluster name, unique among cluster, used as namespace of cluster resources

    #---------------
    # optional                          # all configuration below are OPTIONAL for a pgsql cluster (Overwrite global default)
    #---------------
    pg_version: 14                      # pgsql version to be installed (use global version if missing)
    node_tune: tiny                     # node optimization profile: {oltp|olap|crit|tiny}, use tiny for vm sandbox
    pg_conf: tiny.yml                   # pgsql template:  {oltp|olap|crit|tiny}, use tiny for sandbox
    patroni_mode: default               # entering patroni pause mode after bootstrap  {default|pause|remove}
    patroni_watchdog_mode: off          # disable patroni watchdog on meta node        {off|require|automatic}
    pg_lc_ctype: en_US.UTF8             # use en_US.UTF8 locale for i18n char support  (required by `pg_trgm`)

    #---------------
    # biz databases                     # Defining Business Databases (Optional)
    #---------------
    pg_databases:                       # define business databases on this cluster, array of database definition
      # define the default `meta` database
      - name: meta                      # required, `name` is the only mandatory field of a database definition
        baseline: cmdb.sql              # optional, database sql baseline path, (relative path among ansible search path, e.g files/)
        # owner: postgres               # optional, database owner, postgres by default
        # template: template1           # optional, which template to use, template1 by default
        # encoding: UTF8                # optional, database encoding, UTF8 by default. (MUST same as template database)
        # locale: C                     # optional, database locale, C by default.  (MUST same as template database)
        # lc_collate: C                 # optional, database collate, C by default. (MUST same as template database)
        # lc_ctype: C                   # optional, database ctype, C by default.   (MUST same as template database)
        # tablespace: pg_default        # optional, default tablespace, 'pg_default' by default.
        # allowconn: true               # optional, allow connection, true by default. false will disable connect at all
        # revokeconn: false             # optional, revoke public connection privilege. false by default. (leave connect with grant option to owner)
        # pgbouncer: true               # optional, add this database to pgbouncer database list? true by default
        comment: pigsty meta database   # optional, comment string for this database
        connlimit: -1                   # optional, database connection limit, default -1 disable limit
        schemas: [pigsty]               # optional, additional schemas to be created, array of schema names
        extensions:                     # optional, additional extensions to be installed: array of schema definition `{name,schema}`
          - { name: adminpack, schema: pg_catalog }    # install adminpack to pg_catalog
          - { name: postgis, schema: public }          # if schema is omitted, extension will be installed according to search_path.
          - { name: timescaledb }                      # some extensions are not relocatable, you can just omit the schema part

      # define an additional database named grafana & prometheus (optional)
      # - { name: grafana,    owner: dbuser_grafana    , revokeconn: true , comment: grafana    primary database }
      # - { name: prometheus, owner: dbuser_prometheus , revokeconn: true , comment: prometheus primary database , extensions: [{ name: timescaledb }]}

    #---------------
    # biz users                         # Defining Business Users (Optional)
    #---------------
    pg_users:                           # define business users/roles on this cluster, array of user definition
      # define admin user for meta database (This user are used for pigsty app deployment by default)
      - name: dbuser_meta               # required, `name` is the only mandatory field of a user definition
        password: md5d3d10d8cad606308bdb180148bf663e1  # md5 salted password of 'DBUser.Meta'
        # optional, plain text and md5 password are both acceptable (prefixed with `md5`)
        login: true                     # optional, can login, true by default  (new biz ROLE should be false)
        superuser: false                # optional, is superuser? false by default
        createdb: false                 # optional, can create database? false by default
        createrole: false               # optional, can create role? false by default
        inherit: true                   # optional, can this role use inherited privileges? true by default
        replication: false              # optional, can this role do replication? false by default
        bypassrls: false                # optional, can this role bypass row level security? false by default
        pgbouncer: true                 # optional, add this user to pgbouncer user-list? false by default (production user should be true explicitly)
        connlimit: -1                   # optional, user connection limit, default -1 disable limit
        expire_in: 3650                 # optional, now + n days when this role is expired (OVERWRITE expire_at)
        expire_at: '2030-12-31'         # optional, YYYY-MM-DD 'timestamp' when this role is expired  (OVERWRITTEN by expire_in)
        comment: pigsty admin user      # optional, comment string for this user/role
        roles: [dbrole_admin]           # optional, belonged roles. default roles are: dbrole_{admin,readonly,readwrite,offline}
        parameters: {}                  # optional, role level parameters with `ALTER ROLE SET`
        # search_path: public         # key value config parameters according to postgresql documentation (e.g: use pigsty as default search_path)
      - {name: dbuser_view , password: DBUser.Viewer  ,pgbouncer: true ,roles: [dbrole_readonly], comment: read-only viewer for meta database}

      # define additional business users for prometheus & grafana (optional)
      - {name: dbuser_grafana    , password: DBUser.Grafana    ,pgbouncer: true ,roles: [dbrole_admin], comment: admin user for grafana database }
      - {name: dbuser_prometheus , password: DBUser.Prometheus ,pgbouncer: true ,roles: [dbrole_admin], comment: admin user for prometheus database , createrole: true }

    #---------------
    # hba rules                                         # Defining extra HBA rules on this cluster (Optional)
    #---------------
    pg_hba_rules_extra:                                 # Extra HBA rules to be installed on this cluster
      - title: reject grafana non-local access          # required, rule title (used as hba description & comment string)
        role: common                                    # required, which roles will be applied? ('common' applies to all roles)
        rules:                                          # required, rule content: array of hba string
          - local   grafana         dbuser_grafana                          md5
          - host    grafana         dbuser_grafana      127.0.0.1/32        md5
          - host    grafana         dbuser_grafana      10.10.10.10/32      md5

    vip_mode: l2                        # setup a level-2 vip for cluster pg-meta
    vip_address: 10.10.10.2             # virtual ip address that binds to primary instance of cluster pg-meta
    vip_cidrmask: 8                     # cidr network mask length
    vip_interface: eth1                 # interface to add virtual ip
Pigsty 1.3+:定制不同类型的Redis集群
#----------------------------------#
# redis sentinel example           #
#----------------------------------#
redis-meta:
  hosts:
    10.10.10.10:
      redis_node: 1
      redis_instances:  { 6001 : {} ,6002 : {} , 6003 : {} }
  vars:
    redis_cluster: redis-meta
    redis_mode: sentinel
    
    
    redis_max_memory: 128MB

#----------------------------------#
# redis cluster example            #
#----------------------------------#
redis-test:
  hosts:
    10.10.10.11:
      redis_node: 1
      redis_instances: { 6501 : {} ,6502 : {} ,6503 : {} ,6504 : {} ,6505 : {} ,6506 : {} }
    10.10.10.12:
      redis_node: 2
      redis_instances: { 6501 : {} ,6502 : {} ,6503 : {} ,6504 : {} ,6505 : {} ,6506 : {} }
  vars:
    redis_cluster: redis-test           # name of this redis 'cluster'
    redis_mode: cluster                 # standalone,cluster,sentinel
    redis_max_memory: 64MB              # max memory used by each redis instance
    redis_mem_policy: allkeys-lru       # memory eviction policy

#----------------------------------#
# redis standalone example         #
#----------------------------------#
redis-common:
  hosts:
    10.10.10.13:
      redis_node: 1
      redis_instances:
        6501: {}
        6502: { replica_of: '10.10.10.13 6501' }
        6503: { replica_of: '10.10.10.13 6501' }
  vars:
    redis_cluster: redis-common         # name of this redis 'cluster'
    redis_mode: standalone              # standalone,cluster,sentinel
    redis_max_memory: 64MB              # max memory used by each redis instance
Pigsty 1.4+:安装并监控一套MatrixDB集群
#----------------------------------#
# cluster: mx-mdw (gp master)
#----------------------------------#
mx-mdw:
  hosts:
    10.10.10.10: { pg_seq: 1, pg_role: primary , nodename: mx-mdw-1 }
  vars:
    gp_role: master          # this cluster is used as greenplum master
    pg_shard: mx             # pgsql sharding name & gpsql deployment name
    pg_cluster: mx-mdw       # this master cluster name is mx-mdw
    pg_databases:
      - { name: matrixmgr , extensions: [ { name: matrixdbts } ] }
      - { name: meta }
    pg_users:
      - { name: meta , password: DBUser.Meta , pgbouncer: true }
      - { name: dbuser_monitor , password: DBUser.Monitor , roles: [ dbrole_readonly ], superuser: true }
    
    pgbouncer_enabled: true                # enable pgbouncer for greenplum master
    pgbouncer_exporter_enabled: false      # enable pgbouncer_exporter for greenplum master
    pg_exporter_params: 'host=127.0.0.1&sslmode=disable'  # use 127.0.0.1 as local monitor host

#----------------------------------#
# cluster: mx-sdw (gp master)
#----------------------------------#
mx-sdw:
  hosts:
    10.10.10.11:
      nodename: mx-sdw-1        # greenplum segment node
      pg_instances:             # greenplum segment instances
        6000: { pg_cluster: mx-seg1, pg_seq: 1, pg_role: primary , pg_exporter_port: 9633 }
        6001: { pg_cluster: mx-seg2, pg_seq: 2, pg_role: replica , pg_exporter_port: 9634 }
    10.10.10.12:
      nodename: mx-sdw-2
      pg_instances:
        6000: { pg_cluster: mx-seg2, pg_seq: 1, pg_role: primary , pg_exporter_port: 9633  }
        6001: { pg_cluster: mx-seg3, pg_seq: 2, pg_role: replica , pg_exporter_port: 9634  }
    10.10.10.13:
      nodename: mx-sdw-3
      pg_instances:
        6000: { pg_cluster: mx-seg3, pg_seq: 1, pg_role: primary , pg_exporter_port: 9633 }
        6001: { pg_cluster: mx-seg1, pg_seq: 2, pg_role: replica , pg_exporter_port: 9634 }
  vars:
    gp_role: segment               # these are nodes for gp segments
    pg_shard: mx                   # pgsql sharding name & gpsql deployment name
    pg_cluster: mx-sdw             # these segment clusters name is mx-sdw
    pg_preflight_skip: true        # skip preflight check (since pg_seq & pg_role & pg_cluster not exists)
    pg_exporter_config: pg_exporter_basic.yml                             # use basic config to avoid segment server crash
    pg_exporter_params: 'options=-c%20gp_role%3Dutility&sslmode=disable'  # use gp_role = utility to connect to segments

自由部署体验齐

无论是几万核的生产环境,还是1核2G的本地虚拟机,云上云下,用哪个云,体验如一!

无论是生产环境、预发环境、还是本地开发测试环境,对Pigsty来说,只有配置文件的内容差异。无论在哪里部署,都能带来统一的使用体验。

Pigsty可以利用Vagrant与Virtualbox,在您自己的笔记本电脑上拉起安装所需的虚拟机沙箱环境,或通过Terraform,自动向云服务商申请ECS/VPC资源,一键创建,一键销毁,自动获取多云部署的能力。

沙箱环境中的虚拟机具有固定的资源名称与IP地址,非常适于软件开发测试、实验演示。 沙箱配置默认为2核4GB的单节点,IP地址 10.10.10.10,部署有一个名为pg-meta-1的单机数据库实例。 此外还有四节点版本的完整版沙箱,带有额外三个数据库节点,可用于充分展现Pigsty高可用架构与监控系统的能力。

沙箱所需机器规格

系统要求

  • Linux内核,x86_64处理器架构
  • 使用 CentOS 7 / RedHat 7 / Oracle Linux 7 或其他等效操作系统发行版
  • 强烈推荐使用 CentOS 7.8.2003 x86_64 ,这是经过长时间生产环境的测试的操作系统环境

单节点基本规格

  • 最低规格:1核,1GB (容易OOM,建议内存至少2GB)
  • 推荐规格:2核,4GB (沙箱默认配置)
  • 将部署一个单机PostgreSQL实例pg-meta-1
  • 在沙箱中,该节点的IP固定为10.10.10.10

四节点基本规格

  • 元节点要求同单节点所述
  • 部署一个额外的三节点PostgreSQL数据库集群pg-test
  • 普通数据库节点,最低规格:1核,1GB,建议使用2GB内存。
  • 三节点的IP地址固定为:10.10.10.11, 10.10.10.12, 10.10.10.13

应用广泛生态全

一键拉起生产级SaaS应用,数据分析快速上手,低代码开发可视化大屏

SaaS软件应用

Pigsty在元节点上默认安装了Docker,您可以一键拉起各类SaaS应用:开源私有代码托管平台Gitlab,开源论坛Discourse,开源社交网络Mastodon,开源ERP软件Odoo,以及用友、金蝶等软件。 您可以使用Docker拉起无状态的部分,修改其数据库连接串使用外部数据库,获取丝滑的云原生管理体验与生产级的数据持久性。详情请参考 教程:Docker应用

数据分析与可视化应用

Pigsty既是开箱即用的PostgreSQL发行版,也可以用做数据分析环境,或制作低代码的可视化应用。您可以直接从SQL数据处理到Echarts绘图一步到位,也可以使用更精细的工作流:例如使用PG作为主数据库,存储数据并用SQL实现业务逻辑;使用内置的PostgREST自动生成后端API,使用内置的JupyterLab用Python进行复杂数据分析,并使用Echarts进行数据可视化,并通过Grafana获得交互能力。

Pigsty自带有几个应用样例作为参考:

  • 分析PG CSV日志样本pglog
  • 新冠疫情数据可视化 covid
  • 全球地表气象站数据查询 isd
  • 数据库流行度排行趋势 dbeng
  • 查询大厂工作上下班安排 worktime

自主可控更省钱

Pigsty可将数据库的综合持有成本降低 50% ~ 80% ,并让数据真正掌控在用户自己的手中!

公有云数据库/RDS,是一种所谓"开箱即用"的解决方案,但它交出的答卷离让用户满意还有很长路要走:相比自建数据库成本昂贵,许多需要超级用户权限的功能被阉割,愚笨的UI与大锅饭式的功能,但在所有问题中,最重要的问题莫过于云软件的安全成本问题:

自主可控

  • 运行在你自己的电脑上的软件,即使软件供应商倒闭也可以继续运行下去。但如果提供云软件的公司/部门倒闭或决定停止支持,这些软件就没法工作了,而你用这些软件创造的数据就被锁死了。因为数据只存储在云端,而不是你自己服务器的磁盘上,而您能指望的补偿通常只有鸡肋的代金券。
  • 无法定制或扩展的问题在云数据库中进一步加剧。云数据库通常不向用户提供数据库超级用户,这将锁死一大批高级功能,以及自行加装扩展功能的能力。与此相对应,‘流复制’,‘高可用’这些本该是数据库标配的东西往往作为增值项向用户出售。
  • 云服务可能在没有警告和追索手段的情况下突然暂停你的账户。您可能在完全无辜的情况下,被自动化系统判定为违反服务条款:未备案使用80与53端口,账户被爆破并用于发送恶意软件或钓鱼邮件,触发违背服务条款。或因为一些政治原因被云厂商锤翻,例如Parler。
  • 国内不用SaaS坚持自研或开源自建的习惯,是被恶劣的生态产业环境真金白银教育出来的。在信息时代把核心资产 — 数据放在别人的硬盘上,就像把金条放在超市存包柜中一样。您无法避免,无法监督、甚至无法意识到利益冲突的云厂商,或者仅仅是怀有恶意或好奇的运维与DBA人员偷窥盗窃您的珍贵数据。

Pigsty则不然,它可以部署在任意地方,包括您自己的服务器上。它开源免费,无需License,无需互联网访问,不收集任何用户数据。您可以在自己的服务器运行它直到海枯石烂。

降本增效

云数据库的成本则是另一个问题:省钱是用户的刚需。公有云厂商的RDS相比传统商业数据库也许有优势,但在自建开源数据库前仍然是暴利天价。据统计,RDS的综合持有成本比起基于云服务器自建要高达 2~3倍,比起IDC托管自建更是高出 5~10倍

Pigsty相比使用云数据库有显著成本优势。例如,您可以使用云数据库一半的开销购买同规格的云服务器,并使用Pigsty自行部署数据库。在这种情况下,您既可以享受公有云的绝大部份管理之快捷便利(IaaS),又可以立竿见影节省一半以上的开销。

更重要的是,Pigsty能显著提高用户效能:它允许一两个高级DBA将所有琐碎杂务交由软件处理,轻松管理几百套数据库集群;也可以让一个初级研发人员,经过简单的学习培训后,即可迅速达到一个高级DBA的廉价七成正确水平。

Pigsty开源免费,在提供类似甚至超过云厂商RDS使用体验的前提下,可将数据库的综合持有成本降低 50% ~ 80% ,并让数据真正掌控在用户自己的手中!

2.1 - PostgreSQL数据库发行版

RedHat for Linux! 开箱即用! 从无到有,让用户用得上

Pigsty将高可用集群部署,扩容缩容,主从复制,故障切换,流量代理,连接池,服务发现,访问控制,监控系统,告警系统,日志采集等生产级成熟解决方案封装为发行版。一次性解决在生产环境与各类场景下使用 世界上最先进的开源关系型数据库 —— PostgreSQL 时会遇到的各种问题,真正做到开箱即用。

2.2 - 无可比拟的可观测性

开源监控最佳实践!所有信息一览无余,让用户看得见

监控系统提供了对系统状态的度量,是运维管理工作的基石。【DEMO

Pigsty带有一个针对大规模数据库集群管理而设计的专业级监控系统,基于业内最佳实践,采用Prometheus、Alertmanager、Grafana、Loki作为监控基础设施。开源开放,定制便利,可复用,可移植,没有厂商锁定。

Pigsty在PostgreSQL监控上做到无可比拟,通过40+监控面板与上千仪表盘综合呈现约3000类指标,覆盖从全局大盘到单个对象的详细信息,从数据库目录到节点日志全部一览无遗。与同类产品相比在指标的覆盖率与监控面板丰富程度上一骑绝尘,为专业用户提供无可替代的价值。详略得当的层次设计,为业余用户带来直观便捷的管理体验。

Pigsty的监控系统可用于监控原生部署的各类数据库实例:PGSQL,REDIS,GPSQL等,也可以独立使用,监控已有的数据库实例或远端云厂商RDS,或仅仅作为主机监控使用,它还可以用作数据可视化作品的展示平台。

2.3 - 自动驾驶的高可用架构

故障自愈,高枕无忧,稳定可靠,坚若磐石!让用户省事

以PostgreSQL为例,Pigsty创建的数据库集群是分布式高可用数据库集群。只要集群中有任意实例存活,集群就可以对外提供完整的读写服务只读服务

Pigsty的高可用架构久经生产环境考验,Pigsty使用 Patroni + Consul 进行故障检测、Fencing与自动故障切换,通过HAProxy、VIP或DNS实现流量的自动切换,以极低的复杂度代价实现了完整的高可用方案,让主从架构的数据库能用出了布式数据库般的体验。

数据库集群可以自动进行故障检测与主从切换,普通故障能在几秒到几十秒内自愈:主库故障RTO < 1min,只读流量几乎无影响,同步集群 RPO = 0 不丢数据。

数据库集群中的每个数据库实例在使用上都是幂等的,任意实例都可以通过内建负载均衡组件HAProxy提供完整的读写服务。任何一个或多个Haproxy实例都可以作为集群的负载均衡器,并通过健康检查进行流量分发,对外屏蔽集群成员的区别。用户可以通过配置灵活定义服务,并通过多种可选方式接入

2.4 - Infra as Code工具箱

HashiCorp for Database! 简单易用!从优到易,让用户省心
  • Pigsty秉持 Infra as Data 的设计理念,用户只需用几行声明式的配置文件描述自己想要的数据库,即可使用幂等剧本,一键将其创建。Just like Kubernetes!

  • Pigsty向开发者交付简单易用的数据库工具箱:一键下载安装,自动配置;一键部署各类开源数据库,一键迁移备份、扩容缩容,极大拉低数据库管理使用门槛,量产DBA!

  • Pigsty能够简化数据库部署与交付、解决环境配置统一的难题:无论是上千套数据库几万核的生产环境,还是本地1C1G的笔记本均可完整运行;基于Vagrant的本地沙箱与基于Terraform的多云部署,云上云下,一键拉起!

声明式API,一键拉起

例如,在三台机器上创建一主两从的数据库集群pg-test,只需要几行配置与一行命令pgsql.yml -l pg-test,即可创建出如下一节所介绍的高可用数据库集群。

使用更多参数对PGSQL数据库集群进行定制

#----------------------------------#
# cluster: pg-meta (on meta node)  #
#----------------------------------#
# pg-meta is the default SINGLE-NODE pgsql cluster deployed on meta node (10.10.10.10)
# if you have multiple n meta nodes, consider deploying pg-meta as n-node cluster too

pg-meta:                                # required, ansible group name , pgsql cluster name. should be unique among environment
  hosts:                                # `<cluster>.hosts` holds instances definition of this cluster
    10.10.10.10:                        # INSTANCE-LEVEL CONFIG: ip address is the key. values are instance level config entries (dict)
      pg_seq: 1                         # required, unique identity parameter (+integer) among pg_cluster
      pg_role: primary                  # required, pg_role is mandatory identity parameter, primary|replica|offline|delayed
      pg_offline_query: true            # instance with `pg_offline_query: true` will take offline traffic (saga, etl,...)
      # some variables can be overwritten on instance level. e.g: pg_upstream, pg_weight, etc...
    #---------------
    # mandatory                         # all configuration above (`ip`, `pg_seq`, `pg_role`) and `pg_cluster` are mandatory
    #---------------
  vars:                                 # `<cluster>.vars` holds CLUSTER LEVEL CONFIG of this pgsql cluster
    pg_cluster: pg-meta                 # required, pgsql cluster name, unique among cluster, used as namespace of cluster resources

    #---------------
    # optional                          # all configuration below are OPTIONAL for a pgsql cluster (Overwrite global default)
    #---------------
    pg_version: 14                      # pgsql version to be installed (use global version if missing)
    node_tune: tiny                     # node optimization profile: {oltp|olap|crit|tiny}, use tiny for vm sandbox
    pg_conf: tiny.yml                   # pgsql template:  {oltp|olap|crit|tiny}, use tiny for sandbox
    patroni_mode: default               # entering patroni pause mode after bootstrap  {default|pause|remove}
    patroni_watchdog_mode: off          # disable patroni watchdog on meta node        {off|require|automatic}
    pg_lc_ctype: en_US.UTF8             # use en_US.UTF8 locale for i18n char support  (required by `pg_trgm`)

    #---------------
    # biz databases                     # Defining Business Databases (Optional)
    #---------------
    pg_databases:                       # define business databases on this cluster, array of database definition
      # define the default `meta` database
      - name: meta                      # required, `name` is the only mandatory field of a database definition
        baseline: cmdb.sql              # optional, database sql baseline path, (relative path among ansible search path, e.g files/)
        # owner: postgres               # optional, database owner, postgres by default
        # template: template1           # optional, which template to use, template1 by default
        # encoding: UTF8                # optional, database encoding, UTF8 by default. (MUST same as template database)
        # locale: C                     # optional, database locale, C by default.  (MUST same as template database)
        # lc_collate: C                 # optional, database collate, C by default. (MUST same as template database)
        # lc_ctype: C                   # optional, database ctype, C by default.   (MUST same as template database)
        # tablespace: pg_default        # optional, default tablespace, 'pg_default' by default.
        # allowconn: true               # optional, allow connection, true by default. false will disable connect at all
        # revokeconn: false             # optional, revoke public connection privilege. false by default. (leave connect with grant option to owner)
        # pgbouncer: true               # optional, add this database to pgbouncer database list? true by default
        comment: pigsty meta database   # optional, comment string for this database
        connlimit: -1                   # optional, database connection limit, default -1 disable limit
        schemas: [pigsty]               # optional, additional schemas to be created, array of schema names
        extensions:                     # optional, additional extensions to be installed: array of schema definition `{name,schema}`
          - { name: adminpack, schema: pg_catalog }    # install adminpack to pg_catalog
          - { name: postgis, schema: public }          # if schema is omitted, extension will be installed according to search_path.
          - { name: timescaledb }                      # some extensions are not relocatable, you can just omit the schema part

      # define an additional database named grafana & prometheus (optional)
      # - { name: grafana,    owner: dbuser_grafana    , revokeconn: true , comment: grafana    primary database }
      # - { name: prometheus, owner: dbuser_prometheus , revokeconn: true , comment: prometheus primary database , extensions: [{ name: timescaledb }]}

    #---------------
    # biz users                         # Defining Business Users (Optional)
    #---------------
    pg_users:                           # define business users/roles on this cluster, array of user definition
      # define admin user for meta database (This user are used for pigsty app deployment by default)
      - name: dbuser_meta               # required, `name` is the only mandatory field of a user definition
        password: md5d3d10d8cad606308bdb180148bf663e1  # md5 salted password of 'DBUser.Meta'
        # optional, plain text and md5 password are both acceptable (prefixed with `md5`)
        login: true                     # optional, can login, true by default  (new biz ROLE should be false)
        superuser: false                # optional, is superuser? false by default
        createdb: false                 # optional, can create database? false by default
        createrole: false               # optional, can create role? false by default
        inherit: true                   # optional, can this role use inherited privileges? true by default
        replication: false              # optional, can this role do replication? false by default
        bypassrls: false                # optional, can this role bypass row level security? false by default
        pgbouncer: true                 # optional, add this user to pgbouncer user-list? false by default (production user should be true explicitly)
        connlimit: -1                   # optional, user connection limit, default -1 disable limit
        expire_in: 3650                 # optional, now + n days when this role is expired (OVERWRITE expire_at)
        expire_at: '2030-12-31'         # optional, YYYY-MM-DD 'timestamp' when this role is expired  (OVERWRITTEN by expire_in)
        comment: pigsty admin user      # optional, comment string for this user/role
        roles: [dbrole_admin]           # optional, belonged roles. default roles are: dbrole_{admin,readonly,readwrite,offline}
        parameters: {}                  # optional, role level parameters with `ALTER ROLE SET`
        # search_path: public         # key value config parameters according to postgresql documentation (e.g: use pigsty as default search_path)
      - {name: dbuser_view , password: DBUser.Viewer  ,pgbouncer: true ,roles: [dbrole_readonly], comment: read-only viewer for meta database}

      # define additional business users for prometheus & grafana (optional)
      - {name: dbuser_grafana    , password: DBUser.Grafana    ,pgbouncer: true ,roles: [dbrole_admin], comment: admin user for grafana database }
      - {name: dbuser_prometheus , password: DBUser.Prometheus ,pgbouncer: true ,roles: [dbrole_admin], comment: admin user for prometheus database , createrole: true }

    #---------------
    # hba rules                                         # Defining extra HBA rules on this cluster (Optional)
    #---------------
    pg_hba_rules_extra:                                 # Extra HBA rules to be installed on this cluster
      - title: reject grafana non-local access          # required, rule title (used as hba description & comment string)
        role: common                                    # required, which roles will be applied? ('common' applies to all roles)
        rules:                                          # required, rule content: array of hba string
          - local   grafana         dbuser_grafana                          md5
          - host    grafana         dbuser_grafana      127.0.0.1/32        md5
          - host    grafana         dbuser_grafana      10.10.10.10/32      md5

    vip_mode: l2                        # setup a level-2 vip for cluster pg-meta
    vip_address: 10.10.10.2             # virtual ip address that binds to primary instance of cluster pg-meta
    vip_cidrmask: 8                     # cidr network mask length
    vip_interface: eth1                 # interface to add virtual ip

Pigsty 1.3+:定制不同类型的Redis集群

#----------------------------------#
# redis sentinel example           #
#----------------------------------#
redis-meta:
  hosts:
    10.10.10.10:
      redis_node: 1
      redis_instances:  { 6001 : {} ,6002 : {} , 6003 : {} }
  vars:
    redis_cluster: redis-meta
    redis_mode: sentinel
    
    
    redis_max_memory: 128MB

#----------------------------------#
# redis cluster example            #
#----------------------------------#
redis-test:
  hosts:
    10.10.10.11:
      redis_node: 1
      redis_instances: { 6501 : {} ,6502 : {} ,6503 : {} ,6504 : {} ,6505 : {} ,6506 : {} }
    10.10.10.12:
      redis_node: 2
      redis_instances: { 6501 : {} ,6502 : {} ,6503 : {} ,6504 : {} ,6505 : {} ,6506 : {} }
  vars:
    redis_cluster: redis-test           # name of this redis 'cluster'
    redis_mode: cluster                 # standalone,cluster,sentinel
    redis_max_memory: 64MB              # max memory used by each redis instance
    redis_mem_policy: allkeys-lru       # memory eviction policy

#----------------------------------#
# redis standalone example         #
#----------------------------------#
redis-common:
  hosts:
    10.10.10.13:
      redis_node: 1
      redis_instances:
        6501: {}
        6502: { replica_of: '10.10.10.13 6501' }
        6503: { replica_of: '10.10.10.13 6501' }
  vars:
    redis_cluster: redis-common         # name of this redis 'cluster'
    redis_mode: standalone              # standalone,cluster,sentinel
    redis_max_memory: 64MB              # max memory used by each redis instance

Pigsty 1.4+:安装并监控一套MatrixDB集群

#----------------------------------#
# cluster: mx-mdw (gp master)
#----------------------------------#
mx-mdw:
  hosts:
    10.10.10.10: { pg_seq: 1, pg_role: primary , nodename: mx-mdw-1 }
  vars:
    gp_role: master          # this cluster is used as greenplum master
    pg_shard: mx             # pgsql sharding name & gpsql deployment name
    pg_cluster: mx-mdw       # this master cluster name is mx-mdw
    pg_databases:
      - { name: matrixmgr , extensions: [ { name: matrixdbts } ] }
      - { name: meta }
    pg_users:
      - { name: meta , password: DBUser.Meta , pgbouncer: true }
      - { name: dbuser_monitor , password: DBUser.Monitor , roles: [ dbrole_readonly ], superuser: true }
    
    pgbouncer_enabled: true                # enable pgbouncer for greenplum master
    pgbouncer_exporter_enabled: false      # enable pgbouncer_exporter for greenplum master
    pg_exporter_params: 'host=127.0.0.1&sslmode=disable'  # use 127.0.0.1 as local monitor host

#----------------------------------#
# cluster: mx-sdw (gp master)
#----------------------------------#
mx-sdw:
  hosts:
    10.10.10.11:
      nodename: mx-sdw-1        # greenplum segment node
      pg_instances:             # greenplum segment instances
        6000: { pg_cluster: mx-seg1, pg_seq: 1, pg_role: primary , pg_exporter_port: 9633 }
        6001: { pg_cluster: mx-seg2, pg_seq: 2, pg_role: replica , pg_exporter_port: 9634 }
    10.10.10.12:
      nodename: mx-sdw-2
      pg_instances:
        6000: { pg_cluster: mx-seg2, pg_seq: 1, pg_role: primary , pg_exporter_port: 9633  }
        6001: { pg_cluster: mx-seg3, pg_seq: 2, pg_role: replica , pg_exporter_port: 9634  }
    10.10.10.13:
      nodename: mx-sdw-3
      pg_instances:
        6000: { pg_cluster: mx-seg3, pg_seq: 1, pg_role: primary , pg_exporter_port: 9633 }
        6001: { pg_cluster: mx-seg1, pg_seq: 2, pg_role: replica , pg_exporter_port: 9634 }
  vars:
    gp_role: segment               # these are nodes for gp segments
    pg_shard: mx                   # pgsql sharding name & gpsql deployment name
    pg_cluster: mx-sdw             # these segment clusters name is mx-sdw
    pg_preflight_skip: true        # skip preflight check (since pg_seq & pg_role & pg_cluster not exists)
    pg_exporter_config: pg_exporter_basic.yml                             # use basic config to avoid segment server crash
    pg_exporter_params: 'options=-c%20gp_role%3Dutility&sslmode=disable'  # use gp_role = utility to connect to segments

2.5 - 云上云下,一键拉起

无论是几万核的生产环境,还是1核2G的本地虚拟机,云上云下,用哪个云,体验如一!

无论是生产环境、预发环境、还是本地开发测试环境,对Pigsty来说,只有配置文件的内容差异。无论在哪里部署,都能带来统一的使用体验。

Pigsty可以利用Vagrant与Virtualbox,在您自己的笔记本电脑上拉起安装所需的虚拟机沙箱环境,或通过Terraform,自动向云服务商申请ECS/VPC资源,一键创建,一键销毁,自动获取多云部署的能力。

沙箱环境中的虚拟机具有固定的资源名称与IP地址,非常适于软件开发测试、实验演示。 沙箱配置默认为2核4GB的单节点,IP地址 10.10.10.10,部署有一个名为pg-meta-1的单机数据库实例。 此外还有四节点版本的完整版沙箱,带有额外三个数据库节点,可用于充分展现Pigsty高可用架构与监控系统的能力。

沙箱所需机器规格

系统要求

  • Linux内核,x86_64处理器架构
  • 使用 CentOS 7 / RedHat 7 / Oracle Linux 7 或其他等效操作系统发行版
  • 强烈推荐使用 CentOS 7.8.2003 x86_64 ,这是经过长时间生产环境的测试的操作系统环境

单节点基本规格

  • 最低规格:1核,1GB (容易OOM,建议内存至少2GB)
  • 推荐规格:2核,4GB (沙箱默认配置)
  • 将部署一个单机PostgreSQL实例pg-meta-1
  • 在沙箱中,该节点的IP固定为10.10.10.10

四节点基本规格

  • 元节点要求同单节点所述
  • 部署一个额外的三节点PostgreSQL数据库集群pg-test
  • 普通数据库节点,最低规格:1核,1GB,建议使用2GB内存。
  • 三节点的IP地址固定为:10.10.10.11, 10.10.10.12, 10.10.10.13

2.6 - 应用广泛,生态繁荣

一键拉起生产级SaaS应用,数据分析快速上手,低代码开发可视化大屏

SaaS软件应用

Pigsty在元节点上默认安装了Docker,您可以一键拉起各类SaaS应用:开源私有代码托管平台Gitlab,开源论坛Discourse,开源社交网络Mastodon,开源ERP软件Odoo,以及用友、金蝶等软件。 您可以使用Docker拉起无状态的部分,修改其数据库连接串使用外部数据库,获取丝滑的云原生管理体验与生产级的数据持久性。

Pigsty带有几个开箱即用的Docker软件应用,详情请参考 教程:Docker应用

  • Gitea : 一个类似Gitlab的轻量级开源代码托管平台
  • PgAdmin4 : 一个用于管理PostgreSQL数据库实例的GUI工具
  • PGWeb:一个自动根据PG数据库模式生成后端API服务的工具
  • PostgREST:一个自动根据PG数据库模式生成后端API服务的工具
  • ByteBase : 一个用于进行PostgreSQL模式变更的GUI工具
  • Jupyter Lab:一个开箱即用的数据分析与处理Python实验环境

您也可以使用Docker执行一些随用随抛的命令工具,例如:

  • SchemaSPY:生成数据库模式的详细可视化报表
  • Pgbadger:生成数据库日志报表

您也可以用Docker拉起一些开箱即用的开源SaaS服务:

  • Gitlab:开源代码托管平台。
  • Habour:开源镜像仓库
  • Jira:开源项目管理平台。
  • Confluence:开源知识托管平台。
  • Odoo:开源ERP
  • Mastodon:基于PG的社交网络
  • Discourse:基于PG与Redis的开源论坛

数据分析与可视化应用

Pigsty既是开箱即用的PostgreSQL发行版,也可以用做数据分析环境,或制作低代码的可视化应用。您可以直接从SQL数据处理到Echarts绘图一步到位,也可以使用更精细的工作流:例如使用PG作为主数据库,存储数据并用SQL实现业务逻辑;使用内置的PostgREST自动生成后端API,使用内置的JupyterLab用Python进行复杂数据分析,并使用Echarts进行数据可视化,并通过Grafana获得交互能力。

Pigsty自带有几个应用样例作为参考:

  • 分析PG CSV日志样本pglog
  • 新冠疫情数据可视化 covid
  • 全球地表气象站数据查询 isd
  • 数据库流行度排行趋势 dbeng
  • 查询大厂工作上下班安排 worktime

2.7 - 自主可控,降本增效

Alternative for RDS! 安全可控,降本增效!从易到廉,给用户省钱
  • Pigsty相比云厂商RDS,在拥有更低使用⻔槛与更丰富功能的前提下,可节约 50% - 80% 的数据库软硬件成本,初级研发人员即可自主管理成百上千套数据库。

  • Pigsty采用模块化设计,可自由组合,按需定制扩展。可在生产环境部署管理各种数据库,或仅仅将其当成主机监控;可用于开发数据库可视化Demo、或支撑各类SaaS应用

  • 开源免费的生产级数据库解决方案,用于补全云原生生态缺失的最后一块拼图。稳定可靠,经过长时间大规模生产部署验证,提供可选的专业技术支持服务。

Pigsty可将数据库的综合持有成本降低 50% ~ 80% ,并让数据真正掌控在用户自己的手中!

公有云数据库/RDS,是一种所谓"开箱即用"的解决方案,但它交出的答卷离让用户满意还有很长路要走:相比自建数据库成本昂贵,许多需要超级用户权限的功能被阉割,愚笨的UI与大锅饭式的功能,但在所有问题中,最重要的问题莫过于云软件的安全成本问题:

自主可控

  • 运行在你自己的电脑上的软件,即使软件供应商倒闭也可以继续运行下去。但如果提供云软件的公司/部门倒闭或决定停止支持,这些软件就没法工作了,而你用这些软件创造的数据就被锁死了。因为数据只存储在云端,而不是你自己服务器的磁盘上,而您能指望的补偿通常只有鸡肋的代金券。
  • 无法定制或扩展的问题在云数据库中进一步加剧。云数据库通常不向用户提供数据库超级用户,这将锁死一大批高级功能,以及自行加装扩展功能的能力。与此相对应,‘流复制’,‘高可用’这些本该是数据库标配的东西往往作为增值项向用户出售。
  • 云服务可能在没有警告和追索手段的情况下突然暂停你的账户。您可能在完全无辜的情况下,被自动化系统判定为违反服务条款:未备案使用80与53端口,账户被爆破并用于发送恶意软件或钓鱼邮件,触发违背服务条款。或因为一些政治原因被云厂商锤翻,例如Parler。
  • 国内不用SaaS坚持自研或开源自建的习惯,是被恶劣的生态产业环境真金白银教育出来的。在信息时代把核心资产 — 数据放在别人的硬盘上,就像把金条放在超市存包柜中一样。您无法避免,无法监督、甚至无法意识到利益冲突的云厂商,或者仅仅是怀有恶意或好奇的运维与DBA人员偷窥盗窃您的珍贵数据。

Pigsty则不然,它可以部署在任意地方,包括您自己的服务器上。它开源免费,无需License,无需互联网访问,不收集任何用户数据。您可以在自己的服务器运行它直到海枯石烂。

降本增效

云数据库的成本则是另一个问题:省钱是用户的刚需。公有云厂商的RDS相比传统商业数据库也许有优势,但在自建开源数据库前仍然是暴利天价。据统计,RDS的综合持有成本比起基于云服务器自建要高达 2~3倍,比起IDC托管自建更是高出 5~10倍

Pigsty相比使用云数据库有显著成本优势。例如,您可以使用云数据库一半的开销购买同规格的云服务器,并使用Pigsty自行部署数据库。在这种情况下,您既可以享受公有云的绝大部份管理之快捷便利(IaaS),又可以立竿见影节省一半以上的开销。

更重要的是,Pigsty能显著提高用户效能:它允许一两个高级DBA将所有琐碎杂务交由软件处理,轻松管理几百套数据库集群;也可以让一个初级研发人员,经过简单的学习培训后,即可迅速达到一个高级DBA的廉价七成正确水平。

Pigsty开源免费,在提供类似甚至超过云厂商RDS使用体验的前提下,可将数据库的综合持有成本降低 50% ~ 80% ,并让数据真正掌控在用户自己的手中!

3 - 概念

使用Pigsty时需要了解的一些概念与定义

3.1 - 系统架构

介绍Pigsty的系统架构

实体概念模型

一套完整的Pigsty系统,可称为一个部署(Deployment)/ 环境(Environment) ,例如:生产环境,测试环境,预发环境等。

一套Pigsty部署在架构上分为两个部分:一套基础设施,与多套集群,两者均通过一份配置清单(Inventory)进行描述。

基础设施

基础设施(Infra) 部署于元节点上,监控,DNS,NTP,DCS,Yum源等。

集群

集群 可以是主机节点集群,PostgreSQL数据库集群,Redis数据库集群等……,部署于节点上。

不同类型的集群有各自的细分实体概念模型,例如 PGSQLREDIS,…… 例如,PGSQL集群包含有节点实例服务三种核心资源:一个集群会包含多个实例,部署于多个 节点(Node)上,提供多种不同的 服务(Service),每个数据库实例之下又会有更细分的ER模型。

模块

无论是基础设施,还是主机节点,或者是PGSQL与REDIS数据库,都通过模块的方式进行组织,并通过剧本的方式进行安装。

目前Pigsty有四个核心模块:INFRANODESPGSQLREDIS

各种模块可以根据用户的需求自由排列组合: 如果您想将Pigsty当作开箱即用的单机PostgreSQL发行版来使用,那么在一台机器上依次安装 INFRA, NODES, PGSQL 三个模块,就会有一个立即可用的,自我监控管理的数据库实例。 如果您想要一个生产环境的大规模主机监控系统,那么在一台机器上安装 INFRA 模块,在所有被监控的机器节点上安装NODES模块即可 如果您想部署管理大量的PostgreSQL集群,在这些纳入Pigsty管理的节点上再加装 PGSQL 模块即可。

3.2 - 模块组件

介绍Pigsty内置的的四个核心模块:INFRANODESPGSQLREDIS

Pigsty目前提供四个功能模块:

  • INFRA 是Pigsty的基础设施部分,包括监控/告警/可视化/日志/DNS/NTP等公共组件。
  • NODES 是主机节点管理模块,用于配置节点,安装软件,收集监控指标与日志。
  • PGSQL 是PostgreSQL数据库部署管控模块,包括各种类型的PG集群部署与监控。
  • REDIS 是Redis数据库部署管控模块,包括Redis 主从/集群/哨兵部署与监控
模块 概念 部署 配置 剧本
INFRA 概念: INFRA 部署: INFRA 配置: INFRA 剧本: INFRA
NODES 概念: NODES 部署: NODES 配置: NODES 剧本: NODES
PGSQL 概念: PGSQL 部署: PGSQL 配置: PGSQL 剧本: PGSQL
REDIS 概念: REDIS 部署: REDIS 配置: REDIS 剧本: REDIS

用法

您可以自行选择在哪些节点上启用哪些模块,适配不同的需求场景。

默认情况下,Pigsty将执行单机安装,将当前节点初始化为一个加装了 INFRANODES,与PGSQL 模块的元节点

您可以进一步加入其他节点,并在其上加装不同的数据库模块。

单机部署

如果您想将Pigsty当作开箱即用的单机PostgreSQL发行版来使用,那么在一台机器上依次安装 INFRA, NODES, PGSQL 三个模块,就会有一个立即可用的,自我监控管理的数据库实例。

执行 infra.yml 剧本在单机上安装Pigsty,在该节点上部署基础设施 ,并拉起一个单节点PostgreSQL数据库集群。个人用户、简单场景、小微企业可以直接开箱使用此数据库。完整安装Pigsty的节点称为元节点(Meta)。

但Pigsty的能力不只于此,它还可以用于监控管理更多的节点与数据库。

主机监控

如果您想要一个生产环境的大规模主机监控系统,那么在一台机器上安装INFRA模块,在所有被监控的机器节点上安装NODES模块即可。所有的主机节点会配置有软件源,软件包,DNS,NTP,节点监控,日志收集,DCS Agent这些生产环境所需的组件。纳入Pigsty管理的主机节点会带有详细的监控信息,并可以用于进一步部署各式各样的数据库模块。

在元节点上通过 nodes.yml 剧本为更多节点加装NODES模块,纳入Pigsty管理中。

数据库集群

当您将节点纳入Pigsty后,这些节点可以用于进一步部署各种数据库集群

如果您想部署管理大量的PostgreSQL集群,在这些纳入Pigsty管理的节点上再加装 **PGSQL **模块即可。您可以一键部署各种各样的PGSQL集群:单实例,一主N从的高可用集群,同步集群,法定人数提交的同步集群,带有离线ETL角色的集群,异地容灾的备集群,延迟复制集群,Citus分布式集群,TimescaleDB集群,MatrixDB数据仓库集群。

如果你想部署并监控管理很多Redis集群,也只要在Pigsty托管的节点上加装REDIS模块即可。

使用 pgsql.yml 创建高可用的PostgreSQL数据库集群,使用 redis.yml创建主从、集群、哨兵模式的Redis集簇,使用 pigsty-matrixdb.yml 部署 Greenplum/MatrixDB 数据仓库。

Pigsty后续会按需逐步添加新类型的数据库功能模块:KAFKA, MINIO, MONGO等。

3.3 - 配置文件

Pigsty采用声明式配置:用户配置描述状态,而Pigsty负责将真实组件调整至所期待的状态。

配置Pigsty

Pigsty采用声明式配置:用户配置描述状态,而Pigsty负责将真实组件调整至所期待的状态。

Pigsty通过配置清单(Inventory)来定义基础设施与数据库集群,每一套Pigsty部署都有一份对应的配置:无论是几百集群的生产环境,还是1核1GB的本地沙箱,在Pigsty中除了配置内容外没有任何区别。Pigsty的配置采用"Infra as Data"的哲学:用户通过声明式的配置描述自己的需求,而Pigsty负责将真实组件调整至所期待的状态。

在形式上,配置清单的具体实现可以是默认的本地配置文件,也可以是来自CMDB中的动态配置数据,本文介绍时均以默认YAML配置文件pigsty.yml 为例。在 配置过程 中,Pigsty会检测当前节点环境,并自动生成推荐的配置文件。

配置清单的内容主要是配置项,Pigsty提供了220个配置参数,可以在多个层次进行配置,大多数参数可以直接使用默认值。配置项按照类目可以分为四大类:INFRA/基础设施NODES/主机节点PGSQL/PG数据库REDIS/Redis数据库,并可进一步细分为32个小类。


配置过程

进入 Pigsty 项目目录执行 configure,Pigsty会检测根据当前机器环境生成推荐配置文件,这一过程称作 配置 / Configure

./configure [-n|--non-interactive] [-d|--download] [-i|--ip <ipaddr>] [-m|--mode {auto|demo}]

configure会检查下列事项,小问题会自动尝试修复,否则提示报错退出。

check_kernel     # kernel        = Linux
check_machine    # machine       = x86_64
check_release    # release       = CentOS 7.x
check_sudo       # current_user  = NOPASSWD sudo
check_ssh        # current_user  = NOPASSWD ssh
check_ipaddr     # primary_ip (arg|probe|input)              (INTERACTIVE: ask for ip)
check_admin      # check current_user@primary_ip nopass ssh sudo
check_mode       # check machine spec to determine node mode (tiny|oltp|olap|crit)
check_config     # generate config according to primary_ip and mode
check_pkg        # check offline installation package exists (INTERACTIVE: ask for download)
check_repo       # create repo from pkg.tgz if exists
check_repo_file  # create local file repo file if repo exists
check_utils      # check ansible sshpass and other utils installed

直接运行 ./configure 将启动交互式命令行向导,提示用户回答以下三个问题:

IP地址

当检测到当前机器上有多块网卡与多个IP地址时,配置向导会提示您输入主要使用的IP地址, 即您用于从内部网络访问该节点时使用的IP地址。注意请不要使用公网IP地址。

下载软件包

当节点的/tmp/pkg.tgz路径下未找到离线软件包时,配置向导会询问是否从Github下载。 选择Y即会开始下载,选择N则会跳过。如果您的节点有良好的互联网访问与合适的代理配置,或者需要自行制作离线软件包,可以选择N

配置模板

使用什么样的配置文件模板。 配置向导会根据当前机器环境自动选择配置模板,因此不会询问用户这个问题,用户通常也无需关心。 但用户总是可以通过命令行参数-m <mode>手工指定想要使用的配置模板,例如:

  • demo 项目默认配置文件,4节点沙箱使用的配置文件,启用全部功能。
  • auto 在生产环境中部署时推荐的配置文件模板,配置更加稳定保守。
  • 此外Pigsty预置了几种配置模板,可以直接通过-m参数指定并使用,详见files/conf目录

configure过程中,配置向导会根据当前机器环境自动选择配置模板,但用户可以通过-m <mode>手工指定使用配置模板。配置模板最重要的部分是将模板中占位IP地址10.10.10.10替换为当前机器的真实IP地址(内网主IP),并根据当前机器的配置选择合适的数据库规格模板。您可以直接使用默认生成的配置文件,或基于自动生成的配置文件进行进一步的定制与修改。

配置过程的标准输出
$ ./configure
configure pigsty v1.5.1 begin
[ OK ] kernel = Linux
[ OK ] machine = x86_64
[ OK ] release = 7.8.2003 , perfect
[ OK ] sudo = root ok
[ OK ] ssh = root@127.0.0.1 ok
[ OK ] primary_ip = 10.10.10.10  (from probe)
[ OK ] admin = root@10.10.10.10 ok
[ OK ] spec = mini (cpu = 2)
[ OK ] config = auto @ 10.10.10.10
[ OK ] cache = /tmp/pkg.tgz exists
[ OK ] repo = /www/pigsty ok
[ OK ] repo file = /etc/yum.repos.d/pigsty-local.repo
[ OK ] utils = install from local file repo
[ OK ] ansible = ansible 2.9.27
configure pigsty done. Use 'make install' to proceed

配置文件

Pigsty项目根目录下有一个具体的配置文件样例:pigsty.yml

配置文件顶层是一个keyall的单个对象,包含两个子项目:varschildren

all:                      # 顶层对象 all
  vars: <123 keys>        # 全局配置 all.vars

  children:               # 分组定义:all.children 每一个项目定义了一个数据库集群 
    meta: <2 keys>...     # 特殊分组 meta ,定义了环境元节点
    
    pg-meta: <2 keys>...  # 数据库集群 pg-meta 的详细定义
    pg-test: <2 keys>...  # 数据库集群 pg-test 的详细定义
    ...

vars的内容为KV键值对,定义了全局配置参数,K为配置项名称,V为配置项内容。

children 的内容也是KV结构,K为集群名称,V为具体的集群定义,一个样例集群的定义如下所示:

  • 集群定义同样包括两个子项目:vars定义了集群层面的配置。hosts定义了集群的实例成员。
  • 集群配置中的参数会覆盖全局配置中的对应参数,而集群的配置参数又会被实例级别的同名配置参数所覆盖。集群配置参数中,唯pg_cluster为必选项,这是集群的名称,须与上层集群名保持一致。
  • hosts中采用KV的方式定义集群实例成员,K为IP地址(须ssh可达),V为具体的实例配置参数
  • 实例配置参数中有两个必须参数:pg_seq,与 pg_role,分别为实例的唯一序号和实例的角色。
pg-test:                 # 数据库集群名称默认作为群组名称
  vars:                  # 数据库集群级别变量
    pg_cluster: pg-test  # 一个定义在集群级别的必选配置项,在整个pg-test中保持一致。 
  hosts:                 # 数据库集群成员
    10.10.10.11: {pg_seq: 1, pg_role: primary} # 数据库实例成员
    10.10.10.12: {pg_seq: 2, pg_role: replica} # 必须定义身份参数 pg_role 与 pg_seq
    10.10.10.13: {pg_seq: 3, pg_role: offline} # 可以在此指定实例级别的变量

Pigsty配置文件遵循Ansible规则,采用YAML格式,默认使用单一配置文件。Pigsty的默认配置文件路径为Pigsty源代码根目录下的 pigsty.yml 。默认配置文件是在同目录下的ansible.cfg通过inventory = pigsty.yml指定的。您可以在执行任何剧本时,通过-i <config_path>参数指定其他的配置文件。

配置文件需要与Ansible 配合使用。Ansible是一个流行的DevOps工具,但普通用户无需了解Ansible的具体细节。如果您精通Ansible,则可以根据Ansible的清单组织规则自行调整配置文件的组织与结构:例如,使用分立式的配置文件,为每个集群设置单独的群组定义与变量定义文件。

您并不需要精通Ansible,用几分钟时间浏览Ansible快速上手,便足以开始使用Ansible执行剧本。

配置项

配置项的形式为键值对:键是配置项的名称,值是配置项的内容。值的形式各异,可能是简单的单个字符串,也可能是复杂的对象数组。

Pigsty的参数可以在不同的层次进行配置,并依据规则继承与覆盖,高优先级的配置项会覆盖低优先级的同名配置项。因此用户可以有的放矢,可以在不同层次,不同粒度上针对具体集群与具体实例进行精细配置。

配置项的层次

在Pigsty的配置文件中,配置项 可以出现在三种位置,全局集群实例集群vars中定义的配置项会以同名键覆盖的方式覆盖全局配置项实例中定义的配置项又会覆盖集群配置项与全局配置项。

粒度 范围 优先级 说明 位置
Global 全局 在同一套部署环境内一致 all.vars.xxx
Cluster 集群 在同一套集群内保持一致 all.children.<cls>.vars.xxx
Instance 实例 最细粒度的配置层次 all.children.<cls>.hosts.<ins>.xxx

并非所有配置项都适合在所有层次使用。例如,基础设施的参数通常只会在全局配置中定义,数据库实例的标号,角色,负载均衡权重等参数只能在实例层次配置,而一些操作选项则只能使用命令行参数提供(例如要创建的数据库名称),关于配置项的详情与适用范围,请参考配置项清单

兜底与覆盖

除了配置文件中的三种配置粒度,Pigsty配置项目中还有两种额外的优先级层次:默认值兜底与命令行参数强制覆盖:

  • 默认:当一个配置项在全局/集群/实例级别都没有出现时,将使用默认配置项。默认值的优先级最低,所有配置项都有默认值。默认参数定义于roles/<role>/default/main.yml中。
  • 参数:当用户通过命令行传入参数时,参数指定的配置项具有最高优先级,将覆盖一切层次的配置。一些配置项只能通过命令行参数的方式指定与使用。
层级 来源 优先级 说明 位置
Default 默认 最低 代码逻辑定义的默认值 roles/<role>/default/main.yml
Global 全局 在同一套部署环境内一致 all.vars.xxx
Cluster 集群 在同一套集群内保持一致 all.children.<cls>.vars.xxx
Instance 实例 最细粒度的配置层次 all.children.<cls>.hosts.<ins>.xxx
Argument 参数 最高 通过命令行参数传入 -e

配置类目

Pigsty包含了220个固定配置项,分为四个部分:INFRA, NODES, PGSQL, REDIS,共计32类。

通常只有节点/数据库身份参数是必选参数,其他配置参数可直接使用默认值,按需修改。

Category Section Description Count
INFRA CONNECT 连接参数 1
INFRA REPO 本地源基础设施 10
INFRA CA 公私钥基础设施 5
INFRA NGINX NginxWeb服务器 5
INFRA NAMESERVER DNS服务器 1
INFRA PROMETHEUS 监控时序数据库 7
INFRA EXPORTER 通用Exporter配置 3
INFRA GRAFANA Grafana可视化平台 9
INFRA LOKI Loki日志收集平台 5
INFRA DCS 分布式配置存储元数据库 8
NODES NODE_IDENTITY 节点身份参数 5
NODES NODE_DNS 节点域名解析 5
NODES NODE_REPO 节点软件源 3
NODES NODE_PACKAGES 节点软件包 4
NODES NODE_FEATURES 节点功能特性 6
NODES NODE_MODULES 节点内核模块 1
NODES NODE_TUNE 节点参数调优 2
NODES NODE_ADMIN 节点管理员 6
NODES NODE_TIME 节点时区与时间同步 4
NODES NODE_EXPORTER 节点指标暴露器 3
NODES PROMTAIL 日志收集组件 5
PGSQL PG_IDENTITY PGSQL数据库身份参数 13
PGSQL PG_BUSINESS PGSQL业务对象定义 11
PGSQL PG_INSTALL PGSQL安装 11
PGSQL PG_BOOTSTRAP PGSQL集群初始化 24
PGSQL PG_PROVISION PGSQL集群模板置备 9
PGSQL PG_EXPORTER PGSQL指标暴露器 13
PGSQL PG_SERVICE PGSQL服务接入 16
REDIS REDIS_IDENTITY REDIS身份参数 3
REDIS REDIS_PROVISION REDIS集群置备 14
REDIS REDIS_EXPORTER REDIS指标暴露器 3

3.4 - 预置剧本

Pigsty使用剧本在节点上安装功能模块

Pigsty在底层通过 Ansible Playbook 实现核心管控功能,Pigsty提供的预置剧本分为四大类:

  • infra : 使用 infra 系列剧本在元节点上单机安装Pigsty,并加装可选功能。
  • nodes : 使用 nodes 系列剧本将更多节点纳入Pigsty监控管理,并供后续使用。
  • pgsql : 使用 pgsql 系列剧本在已有节点上部署与管理PostgreSQL数据库集群。
  • redis : 使用 redis 系列剧本在已有节点上部署与管理各种模式的Redis集群。

剧本概览

剧本 功能 链接
infra 在元节点上完整安装Pigsty src
infra-demo 一次性完整初始化四节点演示沙箱环境的特殊剧本 src
infra-jupyter 在元节点上加装可选数据分析服务组件Jupyter Lab src
infra-pgweb 在元节点上加装可选的Web客户端工具PGWeb src
nodes 节点置备,将节点纳入Pigsty管理,可用于后续数据库部署 src
nodes-remove 节点移除,卸载节点DCS与监控,不再纳入Pigsty管理 src
pgsql 部署PostgreSQL集群,或集群扩容 src
pgsql-remove 下线PostgreSQL集群,或集群缩容 src
pgsql-createuser 创建PostgreSQL业务用户 src
pgsql-createdb 创建PostgreSQL业务数据库 src
pgsql-monly 仅监控模式,接入现存PostgreSQL实例或RDS src
pgsql-migration 生成PostgreSQL半自动数据库迁移方案(Beta) src
pgsql-audit 生成PostgreSQL审计合规报告(Beta) src
pgsql-matrix 复用PG角色部署一套MatrixDB数据仓库集群(Beta) src
redis 部署集群/主从/Sentinel模式的Redis数据库 src
redis-remove Redis集群/节点下线 src

典型使用流程如下:

  1. 使用 infra 系列剧本在元节点/本机安装 Pigsty ,部署基础设施。

    所有剧本都在元节点上发起执行,infra 系列剧本只作用于元节点本身。

  2. 使用 nodes 系列剧本将其他节点纳入或移除Pigsty管理

    节点被托管后,可从元节点Grafana访问节点监控与日志,节点加入Consul集群。

  3. 使用 pgsql 系列剧本在纳入管理的节点上部署PostgreSQL集群

    在托管节点上执行部署后,可以从元节点访问PostgreSQL监控与日志。

  4. 使用 redis 系列剧本在纳入管理的节点上部署Redis集群

    在托管节点上执行部署后,可以从元节点访问Redis监控与日志。

                                           meta     node
[infra.yml]  ./infra.yml [-l meta]        +pigsty   +docker +consul +etcd
[nodes.yml]  ./nodes.yml -l pg-test                 +docker +consul +monitor
[pgsql.yml]  ./pgsql.yml -l pg-test                 +pgsql
[redis.yml]  ./redis.yml -l pg-test                 +redis

绝大多数剧本都是幂等设计,这意味着一些部署剧本在没有开启保护选项的情况下,可能会抹除现有数据库并创建新数据库。 当您处理现有数据库集群,或在生产环境进行操作时,请充分阅读并理解文档,再三校对命令,谨慎操作。对于误操作导致的数据库损失,作者不负任何责任。


Ansible快速上手

Pigsty剧本使用Ansible编写,用户并不需要完全理解Ansible的原理,只需要很少的知识即足以充分利用 Ansible 剧本。

  • Ansible安装:如何安装Ansible?(Pigsty用户通常无需操心)
  • 主机子集:如何针对特定主机执行剧本?
  • 任务子集:如何执行剧本中的某些特定任务?
  • 额外参数:如何传入额外的命令行参数以控制剧本行为?

Ansible安装

Ansible剧本需要使用ansible-playbook可执行命令,可使用包管理器安装Ansible,Ansible的安装由Pigsty自动处理,用户通常无需操心。

执行Ansible剧本时,直接将剧本作为可执行程序执行即可。执行剧本时有三个核心的参数需要关注:-l|-t|-e,分别用于限制执行的主机,与执行的任务,以及传入额外的参数。

主机子集

可以通过 -l|--limit <selector> 参数选择执行的目标,不指定此参数时,大多数剧本默认会以配置文件中定义的所有主机作为执行对象,这是非常危险的。 强烈建议在执行剧本时,指定执行的对象。

常用的对象有两种,集群与主机,例如:

./pgsql.yml                 # 在配置清单的所有主机上执行pgsql剧本(危险!)
./pgsql.yml -l pg-test      # 针对 pg-test 集群中的主机执行pgsql剧本
./pgsql.yml -l 10.10.10.10  # 针对 10.10.10.10 的主机执行pgsql剧本
./pgsql.yml -l pg-*         # 针对符合 pg-* 模式 (glob) 的集群执行剧本

任务子集

可以通过-t|--tags <tags>来选择执行的任务子集,不指定此参数时,会执行完整的剧本,指定此参数时,则将执行所选的任务子集,这是非常实用的。

./pgsql.yml -t pg_hba                            # 重新生成并应用集群HBA规则

用户可以通过,分隔,一次执行多个任务,例如当集群角色成员发生变化时,可以使用以下命令调整集群负载均衡配置。

./pgsql.yml -t haproxy_config,haproxy_reload     # 重新生成集群负载均衡器配置并应用

额外参数

可以通过-e|--extra-vars KEY=VALUE 传入额外的命令行参数,覆盖已有参数,或控制一些特殊的行为。

例如,以下剧本的部分行为可以通过命令行参数进行控制。

./nodes.yml -e ansible_user=admin -k -K      # 在配置节点时,使用另一个管理员用户 admin,并输入ssh与sudo密码
./pgsql.yml -e pg_clean=clean        # 在安装PG时,强制抹除已有运行中数据库实例(危险)
./infra-remove.yml -e rm_metadata=true       # 在卸载Pigsty时,一并移除数据
./infra-remove.yml -e rm_metadpkgs=true      # 在卸载Pigsty时,一并卸载软件
./nodes-remove.yml -e rm_dcs_server=true     # 在移除节点时,即使上面有DCS Server也强制移除
./pgsql-remove.yml -e rm_pgdata=true         # 在移除PG时,一并移除数据
./pgsql-remove.yml -e rm_pgpkgs=true         # 在移除PG时,一并卸载软件

4 - 部署

将Pigsty部署至您自己的服务器与虚拟机上

部署Pigsty分为两步:准备资源,与配置部署

准备资源

安装Pigsty前,您需要准备符合要求的环境软件

配置部署

您需要参考组件部署指南进行筹划,通过配置清单向Pigsty表明自己的需求,并通过剧本贯彻意图。

部署样例

  • 标准部署:您自己准备全新节点,完成标准Pigsty部署流程。
  • 沙箱部署 : 通过预制的vagrant模板一键拉起本地虚拟机沙箱环境。
  • 多云部署:使用terraform模板在云服务供应商处拉起所需虚拟机资源,并执行部署。
  • 仅监控部署 : 使用单节点Pigsty监控现有数据库集群。

4.1 - 环境准备

部署Pigsty所需的环境准备:主机节点,管理员用户,SSH,Sudo与DNS

4.1.1 - 节点置备

在部署Pigsty前,用户需要准备机器节点资源。

在部署Pigsty前,用户需要准备机器节点资源,包括至少一个元节点,与任意数量的普通节点

节点可以使用任意类型:物理机、本地虚拟机、云虚拟机,容器等,只需要满足以下条件:

  • 处理器架构:x86_64
  • 硬件规格至少为1核/1GB
  • 操作系统:CentOS 7.8.2003 (或其他RHEL 7等效发行版)
  • 管理用户可以从 元节点 ssh 登陆其他节点并执行sudo

元节点本身也是一个普通的节点。

节点数量

如果您计划将Pigsty用作开箱即用的PostgreSQL数据库实例,则一台节点足矣。

对于部署生产环境的高可用PostgreSQL数据库集群来说,您最少需要三个节点,我们建议使用4个节点。

如果您还计划将Pigsty用作更多主机/数据库的管控,则可以准备更多的节点备用。

置备节点

您可以参考 本地虚拟机置备 教程,使用Vagrant与Virtualbox一键在本地 x86_64 笔记上拉起沙箱环境所需的四台虚拟机。 您也可以参考 云端虚拟机置备 教程,使用Terraform在云供应商上创建沙箱环境所需的四台虚拟机。

4.1.2 - 元节点置备

Pigsty需要至少元节点作为整个环境的控制中心。

Pigsty需要元节点作为整个环境的控制中心,并提供基础设施 服务。

元节点的数量最少为1个,沙箱环境默认使用1个元节点。

默认情况下,Pigsty的基础设施以副本的形式部署在多个元节点上,DCS(Consul/Etcd)例外,DCS以Quorum的形式存在。

Pigsty的数据库集群需要使用DCS以实现高可用功能,您可以使用自动部署于元节点上的DCS集群,或使用外部的DCS集群。在大规模生产环境中,如果您没有专用的外部DCS集群,建议使用3个元节点以充分保证DCS服务的可用性。

用户应当确保自己可以登录元节点,并能使用管理用户从元节点上通过ssh登陆其他数据库节点,并带有sudoroot权限。用户应当确保自己可以直接或间接访问元节点的80端口,以访问Pigsty提供的用户界面。

  • 元节点数量:奇数个,至少一个
  • 能够使用管理员用户登陆元节点
  • 能够(直接或间接)通过浏览器访问元节点80端口
  • 管理用户可以从元节点远程ssh登陆数据库节点并执行sudo (包括自身)

4.1.3 - 管理用户置备

如何准备所需的管理员用户,配置SSH免密登陆,与免密sudo

Pigsty需要一个管理用户,该用户能够从元节点免密码SSH登陆其他节点,并免密码执行sudo命令。

如果您使用的是云服务器,通常在申请创建云服务器时,便会自动创建这样的管理用户给到客户。

管理用户

Pigsty需要一个管理用户,该用户能够从元节点上SSH登陆其他节点,并执行sudo命令。

  • 可以在元节点上使用该用户
  • 可以使用该用户SSH登陆所有被元节点(包括自身)
  • 可以在登陆所有被元节点后执行sudo命令(包括自身)
  • 管理用户不是postgres{{ dbsu }} (使用DBSU作为管理员有安全隐患)
  • ssh 登陆免密码,sudo 命令免密码(或您知晓如何通过-k,-K手工输入)

执行部署与变更时,您所使用的管理用户必须拥有所有节点的sshsudo权限。免密码并非必需,您总是可以在执行剧本时通过-k|-K参数传入ssh与sudo的密码,甚至通过 -eansible_host=<another_user> 使用其他用户来执行剧本。但Pigsty强烈建议为管理用户配置SSH免密码登陆与免密码sudo

Pigsty推荐将管理用户的创建,权限配置与密钥分发放在虚拟机的Provisioning阶段完成,作为机器资源交付内容的一部分。对于生产环境来说,机器交付时应当已经配置有这样一个具有免密远程SSH登陆并执行免密sudo的用户。通常绝大多数云平台和运维体系都可以做到这一点。

Pigsty剧本nodes 可以在节点上创建管理用户,但这涉及到一个先有鸡还是先有蛋但的问题:为了在远程节点执行Ansible剧本,需要有一个管理用户。为了创建一个专用管理用户,需要在远程节点上执行Ansible剧本。 作为Bootstrap阶段的妥协,只要您有SSH登陆与SUDO权限,即使没有密码,也可以用于执行Ansible剧本,详情请参考 Nodes:创建管理用户

配置SSH免密访问

在元节点上,假设执行命令的用户名为vagrant

生成密钥

vagrant用户的身份执行以ssh-keygen一路回车,会为vagrant生成公私钥对,用于登陆。

[vagrant@node-3 ~]$ ssh-keygen
Generating public/private rsa key pair.
Enter file in which to save the key (/home/vagrant/.ssh/id_rsa):
/home/vagrant/.ssh/id_rsa already exists.
Overwrite (y/n)? y
Enter passphrase (empty for no passphrase):
Enter same passphrase again:
Your identification has been saved in /home/vagrant/.ssh/id_rsa.
Your public key has been saved in /home/vagrant/.ssh/id_rsa.pub.
The key fingerprint is:
SHA256:nys41SqjxFcQYDJO2WkT/ZOB2rlechcOztPEZhrYSR0 vagrant@node-3
The key's randomart image is:
+---[RSA 2048]----+
|  +o+=.. .E.     |
| o.+= o.o .      |
|  .. +.* =       |
|    . +.O *      |
|       +S% .     |
|   .  o.O.=.     |
|    o..* +o      |
|   . .* o  .     |
|    .. + ..      |
+----[SHA256]-----+
[vagrant@node-3 ~]$
[vagrant@node-3 ~]$
  • 默认公钥:~/.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登陆远程机器。

配置免密SUDO

假设用户名为vagrant,则通过visudo 命令,或创建/etc/sudoers.d/vagrant 文件添加以下记录:

%vagrant ALL=(ALL) NOPASSWD: ALL

则 vagrant 用户即可免密sudo执行所有命令

4.1.4 - 本地虚拟机置备

如何使用Vagrant与Virtualbox迅速在本机创建Pigsty部署所需的虚拟机资源

通常为了测试“数据库集群”这样的系统,用户需要事先准备若干台虚拟机。尽管云服务已经非常方便,但本地虚拟机访问通常比云虚拟机访问方便,响应迅速,成本低廉。本地虚拟机配置相对繁琐,Vagrant 可解决这一问题。

Pigsty用户无需了解vagrant的原理,只需要知道vagrant可以简单、快捷地按照用户的需求,在笔记本、PC或Mac上拉起若干台虚拟机。用户需要完成的工作,就是将自己的虚拟机需求,以vagrant配置文件的形式表达出来。

太长;不看

对于MacOS用户,直接使用homebrew命令行一键安装Vagrant与Virtualbox即可,安装完毕后,一键拉起4台虚拟机。

make deps    # 安装homebrew,并通过homebrew安装vagrant与virtualbox(需重启)
make dns     # 向本机/etc/hosts写入静态域名 (需sudo输入密码)
make start   # 使用Vagrant拉起单个meta节点  (start4则为4个节点)

其他操作系统与平台请参考 VagrantVirtualbox 图形安装指南。

实际上底下真正管事的命令是:

# 安装Homebrew
/bin/bash -c "$(curl -fsSL https://raw.githubusercontent.com/Homebrew/install/HEAD/install.sh)"

# 安装Vagrant与Virtualbox
brew install vagrant virtualbox ansible

# 拉起由Vagrantfile预先定义的4台虚拟机
cd vagrant; vagrant up

Vagrant安装

这里介绍了图形界面下下载、安装Vagrant的过程

访问Vagrant官网

https://www.vagrantup.com/downloads

下载Vagrant

最新版本为2.2.19

安装Vagrant

点击 vagrant.pkg 执行安装,安装过程需要输入密码。https://www.virtualbox.org/

在MacOS上安装Virtualbox非常简单,其他操作系统上与之类似。

Virtualbox安装

这里介绍了图形界面下下载、安装Virtualbox的过程

前往Virtualbox官网https://www.virtualbox.org/

下载Virtualbox

最新版本为6.1.24

安装Virtualbox

点击 VirtualBox.pkg 执行安装,安装过程需要输入密码并重启。

如果安装失败,请检查您的 系统偏好设置 - 安全性与隐私 - 通用 - 允许以下位置的App中点击“允许”按钮。

Vagrant配置文件

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核数和内存资源等,如配置文件中的注释所述,详情参阅Vagrant与Pigsty文档。

沙箱环境默认使用IMAGE_NAME = "centos/7",首次执行时会从vagrant官方下载centos 7.8 virtualbox 镜像,确保宿主机拥有合适的网络访问权限(科学上网)!

快捷方式

Pigsty已经提供了对常用vagrant命令的包装,用户可以在项目的Makefile中看到虚拟机管理的相关命令:

make        # 启动集群
make new4   # 销毁并创建新集群
make dns    # 将Pigsty域名记录写入本机/etc/hosts (需要sudo权限)
make ssh    # 将虚拟机SSH配置信息写入 ~/.ssh/config

更多信息,请参考Makefile

#------------------------------#
# vagrant vm management
#------------------------------#
# default node (meta)
up:
	cd vagrant && vagrant up meta
dw:
	cd vagrant && vagrant halt meta
del:
	cd vagrant && vagrant destroy -f meta
new: del up
#------------------------------#
# extra nodes: node-{1,2,3}
up-test:
	cd vagrant && vagrant up node-1 node-2 node-3
dw-test:
	cd vagrant && vagrant halt node-1 node-2 node-3
del-test:
	cd vagrant && vagrant destroy -f node-1 node-2 node-3
new-test: del-test up-test
#------------------------------#
# all nodes (meta, node-1, node-2, node-3)
up4:
	cd vagrant && vagrant up
dw4:
	cd vagrant && vagrant halt
del4:
	cd vagrant && vagrant destroy -f
new4: del4 up4
clean: del4
#------------------------------#
# status
st: status
status:
	cd vagrant && vagrant status
suspend:
	cd vagrant && vagrant suspend
resume:
	cd vagrant && vagrant resume
#------------------------------#

4.1.5 - 云端虚拟机置备

如何使用Terraform迅速在阿里云创建Pigsty部署所需的虚拟机资源

如果您手头没有 x86_64 架构的PC、笔记本、Mac,使用即用即毁的云虚拟机可能是另一个不错的选择。

Terraform

Terraform 是开源免费的 基础设施即代码 工具。您只需要声明好所需的云虚拟机、网络与安全组配置等,一键即可拉起对应的资源。

在MacOS下安装Terraform,只需要执行brew install terraform即可。然后您需要有云厂商账号,并获取AccessKey与AccessSecret凭证,充点钱,就可以开始云端沙箱部署之旅啦。

TF配置文件

项目根目录 terraform/ 中提供了若干云厂商的 Terraform 资源定义文件,您可以使用这些模板快速在云上申请虚拟机资源用于部署Pigsty。这里以阿里云为例:

cd terraform        # 进入terraform目录中
vi alicloud.tf      # 编辑配置文件,填入您的阿里云AccessKey与SecretKey
阿里云样例Terraform文件
provider "alicloud" {
  access_key = "xxxxxx"
  secret_key = "xxxxxx"
  region = "cn-beijing"
}

# use 10.10.10.0/24 cidr block as demo network
resource "alicloud_vpc" "vpc" {
  vpc_name   = "pigsty-demo-network"
  cidr_block = "10.10.10.0/24"
}

# add virtual switch for pigsty demo network
resource "alicloud_vswitch" "vsw" {
  vpc_id     = "${alicloud_vpc.vpc.id}"
  cidr_block = "10.10.10.0/24"
  zone_id    = "cn-beijing-k"
}

# add default security group and allow all tcp traffic
resource "alicloud_security_group" "default" {
  name   = "default"
  vpc_id = "${alicloud_vpc.vpc.id}"
}
resource "alicloud_security_group_rule" "allow_all_tcp" {
  ip_protocol       = "tcp"
  type              = "ingress"
  nic_type          = "intranet"
  policy            = "accept"
  port_range        = "1/65535"
  priority          = 1
  security_group_id = "${alicloud_security_group.default.id}"
  cidr_ip           = "0.0.0.0/0"
}

# https://registry.terraform.io/providers/aliyun/alicloud/latest/docs/resources/instance
resource "alicloud_instance" "pg-meta-1" {
  instance_name              = "pg-meta-1"
  host_name                  = "pg-meta-1"
  instance_type              = "ecs.s6-c1m2.small"
  vswitch_id                 = "${alicloud_vswitch.vsw.id}"
  security_groups            = ["${alicloud_security_group.default.id}"]
  image_id                   = "centos_7_8_x64_20G_alibase_20200914.vhd"
  password                   = "PigstyDemo4"
  private_ip                 = "10.10.10.10"
  internet_max_bandwidth_out = 40 # 40Mbps , alloc a public IP
}

resource "alicloud_instance" "pg-test-1" {
  instance_name   = "pg-test-1"
  host_name       = "pg-test-1"
  instance_type   = "ecs.s6-c1m1.small"
  vswitch_id      = "${alicloud_vswitch.vsw.id}"
  security_groups = ["${alicloud_security_group.default.id}"]
  image_id        = "centos_7_8_x64_20G_alibase_20200914.vhd"
  password        = "PigstyDemo4"
  private_ip      = "10.10.10.11"
}

resource "alicloud_instance" "pg-test-2" {
  instance_name   = "pg-test-2"
  host_name       = "pg-test-2"
  instance_type   = "ecs.s6-c1m1.small"
  vswitch_id      = "${alicloud_vswitch.vsw.id}"
  security_groups = ["${alicloud_security_group.default.id}"]
  image_id        = "centos_7_8_x64_20G_alibase_20200914.vhd"
  password        = "PigstyDemo4"
  private_ip      = "10.10.10.12"
}

resource "alicloud_instance" "pg-test-3" {
  instance_name   = "pg-test-3"
  host_name       = "pg-test-3"
  instance_type   = "ecs.s6-c1m1.small"
  vswitch_id      = "${alicloud_vswitch.vsw.id}"
  security_groups = ["${alicloud_security_group.default.id}"]
  image_id        = "centos_7_8_x64_20G_alibase_20200914.vhd"
  password        = "PigstyDemo4"
  private_ip      = "10.10.10.13"
}


output "meta_ip" {
  value = "${alicloud_instance.pg-meta-1.public_ip}"
}

执行计划

首先,使用terraform命令,创建上面定义的云资源(共享1C1G临时用用很便宜,按需付费)

terraform init      # 安装 terraform provider: aliyun (仅第一次需要)
terraform apply     # 生成执行计划:创建虚拟机,虚拟网段/交换机/安全组

执行 apply 并输入 yes后,terraform会调用阿里云API创建对应的虚拟机资源。

Terraform Apply执行结果
Terraform used the selected providers to generate the following execution plan. Resource actions are indicated with the following symbols:
  + create

Terraform will perform the following actions:

  # alicloud_instance.pg-meta-1 will be created
  + resource "alicloud_instance" "pg-meta-1" {
      + availability_zone                  = (known after apply)
      + credit_specification               = (known after apply)
      + deletion_protection                = false
      + dry_run                            = false
      + host_name                          = "pg-meta-1"
      + id                                 = (known after apply)
      + image_id                           = "centos_7_8_x64_20G_alibase_20200914.vhd"
      + instance_charge_type               = "PostPaid"
      + instance_name                      = "pg-meta-1"
      + instance_type                      = "ecs.s6-c1m2.small"
      + internet_charge_type               = "PayByTraffic"
      + internet_max_bandwidth_in          = (known after apply)
      + internet_max_bandwidth_out         = 40
      + key_name                           = (known after apply)
      + password                           = (sensitive value)
      + private_ip                         = "10.10.10.10"
      + public_ip                          = (known after apply)
      + role_name                          = (known after apply)
      + secondary_private_ip_address_count = (known after apply)
      + secondary_private_ips              = (known after apply)
      + security_groups                    = (known after apply)
      + spot_strategy                      = "NoSpot"
      + status                             = "Running"
      + subnet_id                          = (known after apply)
      + system_disk_category               = "cloud_efficiency"
      + system_disk_performance_level      = (known after apply)
      + system_disk_size                   = 40
      + volume_tags                        = (known after apply)
      + vswitch_id                         = (known after apply)
    }

  # alicloud_instance.pg-test-1 will be created
  + resource "alicloud_instance" "pg-test-1" {
      + availability_zone                  = (known after apply)
      + credit_specification               = (known after apply)
      + deletion_protection                = false
      + dry_run                            = false
      + host_name                          = "pg-test-1"
      + id                                 = (known after apply)
      + image_id                           = "centos_7_8_x64_20G_alibase_20200914.vhd"
      + instance_charge_type               = "PostPaid"
      + instance_name                      = "pg-test-1"
      + instance_type                      = "ecs.s6-c1m1.small"
      + internet_max_bandwidth_in          = (known after apply)
      + internet_max_bandwidth_out         = 0
      + key_name                           = (known after apply)
      + password                           = (sensitive value)
      + private_ip                         = "10.10.10.11"
      + public_ip                          = (known after apply)
      + role_name                          = (known after apply)
      + secondary_private_ip_address_count = (known after apply)
      + secondary_private_ips              = (known after apply)
      + security_groups                    = (known after apply)
      + spot_strategy                      = "NoSpot"
      + status                             = "Running"
      + subnet_id                          = (known after apply)
      + system_disk_category               = "cloud_efficiency"
      + system_disk_performance_level      = (known after apply)
      + system_disk_size                   = 40
      + volume_tags                        = (known after apply)
      + vswitch_id                         = (known after apply)
    }

  # alicloud_instance.pg-test-2 will be created
  + resource "alicloud_instance" "pg-test-2" {
      + availability_zone                  = (known after apply)
      + credit_specification               = (known after apply)
      + deletion_protection                = false
      + dry_run                            = false
      + host_name                          = "pg-test-2"
      + id                                 = (known after apply)
      + image_id                           = "centos_7_8_x64_20G_alibase_20200914.vhd"
      + instance_charge_type               = "PostPaid"
      + instance_name                      = "pg-test-2"
      + instance_type                      = "ecs.s6-c1m1.small"
      + internet_max_bandwidth_in          = (known after apply)
      + internet_max_bandwidth_out         = 0
      + key_name                           = (known after apply)
      + password                           = (sensitive value)
      + private_ip                         = "10.10.10.12"
      + public_ip                          = (known after apply)
      + role_name                          = (known after apply)
      + secondary_private_ip_address_count = (known after apply)
      + secondary_private_ips              = (known after apply)
      + security_groups                    = (known after apply)
      + spot_strategy                      = "NoSpot"
      + status                             = "Running"
      + subnet_id                          = (known after apply)
      + system_disk_category               = "cloud_efficiency"
      + system_disk_performance_level      = (known after apply)
      + system_disk_size                   = 40
      + volume_tags                        = (known after apply)
      + vswitch_id                         = (known after apply)
    }

  # alicloud_instance.pg-test-3 will be created
  + resource "alicloud_instance" "pg-test-3" {
      + availability_zone                  = (known after apply)
      + credit_specification               = (known after apply)
      + deletion_protection                = false
      + dry_run                            = false
      + host_name                          = "pg-test-3"
      + id                                 = (known after apply)
      + image_id                           = "centos_7_8_x64_20G_alibase_20200914.vhd"
      + instance_charge_type               = "PostPaid"
      + instance_name                      = "pg-test-3"
      + instance_type                      = "ecs.s6-c1m1.small"
      + internet_max_bandwidth_in          = (known after apply)
      + internet_max_bandwidth_out         = 0
      + key_name                           = (known after apply)
      + password                           = (sensitive value)
      + private_ip                         = "10.10.10.13"
      + public_ip                          = (known after apply)
      + role_name                          = (known after apply)
      + secondary_private_ip_address_count = (known after apply)
      + secondary_private_ips              = (known after apply)
      + security_groups                    = (known after apply)
      + spot_strategy                      = "NoSpot"
      + status                             = "Running"
      + subnet_id                          = (known after apply)
      + system_disk_category               = "cloud_efficiency"
      + system_disk_performance_level      = (known after apply)
      + system_disk_size                   = 40
      + volume_tags                        = (known after apply)
      + vswitch_id                         = (known after apply)
    }

  # alicloud_security_group.default will be created
  + resource "alicloud_security_group" "default" {
      + id                  = (known after apply)
      + inner_access        = (known after apply)
      + inner_access_policy = (known after apply)
      + name                = "default"
      + security_group_type = "normal"
      + vpc_id              = (known after apply)
    }

  # alicloud_security_group_rule.allow_all_tcp will be created
  + resource "alicloud_security_group_rule" "allow_all_tcp" {
      + cidr_ip           = "0.0.0.0/0"
      + id                = (known after apply)
      + ip_protocol       = "tcp"
      + nic_type          = "intranet"
      + policy            = "accept"
      + port_range        = "1/65535"
      + priority          = 1
      + security_group_id = (known after apply)
      + type              = "ingress"
    }

  # alicloud_vpc.vpc will be created
  + resource "alicloud_vpc" "vpc" {
      + cidr_block        = "10.10.10.0/24"
      + id                = (known after apply)
      + ipv6_cidr_block   = (known after apply)
      + name              = (known after apply)
      + resource_group_id = (known after apply)
      + route_table_id    = (known after apply)
      + router_id         = (known after apply)
      + router_table_id   = (known after apply)
      + status            = (known after apply)
      + vpc_name          = "pigsty-demo-network"
    }

  # alicloud_vswitch.vsw will be created
  + resource "alicloud_vswitch" "vsw" {
      + availability_zone = (known after apply)
      + cidr_block        = "10.10.10.0/24"
      + id                = (known after apply)
      + name              = (known after apply)
      + status            = (known after apply)
      + vpc_id            = (known after apply)
      + vswitch_name      = (known after apply)
      + zone_id           = "cn-beijing-k"
    }

Plan: 8 to add, 0 to change, 0 to destroy.

Changes to Outputs:
  + meta_ip = (known after apply)

Do you want to perform these actions?
  Terraform will perform the actions described above.
  Only 'yes' will be accepted to approve.

  Enter a value: yes

alicloud_vpc.vpc: Creating...
alicloud_vpc.vpc: Creation complete after 6s [id=vpc-2zed78z7n5z06o1dmydhj]
alicloud_security_group.default: Creating...
alicloud_vswitch.vsw: Creating...
alicloud_security_group.default: Creation complete after 1s [id=sg-2ze7x7zu8tcdsefroofa]
alicloud_security_group_rule.allow_all_tcp: Creating...
alicloud_security_group_rule.allow_all_tcp: Creation complete after 0s [id=sg-2ze7x7zu8tcdsefroofa:ingress:tcp:1/65535:intranet:0.0.0.0/0:accept:1]
alicloud_vswitch.vsw: Creation complete after 6s [id=vsw-2zejctjdr16ryz194jxz4]
alicloud_instance.pg-test-3: Creating...
alicloud_instance.pg-test-2: Creating...
alicloud_instance.pg-test-1: Creating...
alicloud_instance.pg-meta-1: Creating...
alicloud_instance.pg-test-3: Still creating... [10s elapsed]
alicloud_instance.pg-test-2: Still creating... [10s elapsed]
alicloud_instance.pg-test-1: Still creating... [10s elapsed]
alicloud_instance.pg-meta-1: Still creating... [10s elapsed]
alicloud_instance.pg-meta-1: Creation complete after 16s [id=i-2zef4frw6kezb47339wr]
alicloud_instance.pg-test-1: Still creating... [20s elapsed]
alicloud_instance.pg-test-2: Still creating... [20s elapsed]
alicloud_instance.pg-test-3: Still creating... [20s elapsed]
alicloud_instance.pg-test-2: Creation complete after 23s [id=i-2zefzvz0fyl7mloc4v30]
alicloud_instance.pg-test-1: Still creating... [30s elapsed]
alicloud_instance.pg-test-3: Still creating... [30s elapsed]
alicloud_instance.pg-test-3: Creation complete after 33s [id=i-2zeeyodo2pc8b1k2d167]
alicloud_instance.pg-test-1: Creation complete after 33s [id=i-2zef4frw6kezb47339ws]

SSH配置与微调

其中,管理机将分配一个按量付费的公网IP,您也可以使用命令terraform output将其打印出来。

# 打印公网IP与root密码
ssh_pass='PigstyDemo4'
public_ip=$(terraform output | grep -Eo '[0-9]{1,3}\.[0-9]{1,3}\.[0-9]{1,3}\.[0-9]{1,3}')
echo "meta node: root:${ssh_pass}@${public_ip}"

接下来,我们先来配置本地登录云端管理机器的SSH配置(默认用户root,密码PigstyDemo4

# 创建 ~/.ssh/pigsty_terraform 文件,包含云端管理机器的SSH定义(可选,好用一点)
cat > ~/.ssh/pigsty_terraform <<-EOF
Host demo
  User root
  HostName ${public_ip}
  UserKnownHostsFile /dev/null
  StrictHostKeyChecking no
  PasswordAuthentication yes
EOF
chmod 0600 ~/.ssh/pigsty_terraform 

# 启用该配置
if ! grep --quiet "Include ~/.ssh/pigsty_terraform" ~/.ssh/config ; then
    (echo 'Include ~/.ssh/pigsty_terraform' && cat ~/.ssh/config) >  ~/.ssh/config.tmp;
    mv ~/.ssh/config.tmp ~/.ssh/config && chmod 0600 ~/.ssh/config;
fi

然后,您可以通过SSH别名demo访问该云端管理机了。

# 添加本地到元节点的免密访问
sshpass -p ${ssh_pass} ssh-copy-id demo 

然后,您就可以免密从本地访问该节点了,如果只需要进行单节点安装,这样就行了。接下来,在该元节点上完成标准安装

特殊注意事项

阿里云虚拟机CentOS 7.8镜像中运行有 nscd ,锁死了 glibc 版本,会导致安装时出现RPM依赖错误。

在所有机器上执行 yum remove -y nscd 即可解决此问题。

完成上述准备工作后,所有机器准备工作已经就绪,可以开始常规的 Pigsty下载配置安装三部曲啦。

4.1.6 - DNS域名配置

为Pigsty Web服务配置自定义域名

Pigsty默认通过域名访问所有Web系统,尽管您可以使用 IP:Port的方式访问主要系统的Web界面,但这并不是推荐的行为。

因为有一些Web服务(例如Consul)监听的地址是 127.0.0.1 而非 0.0.0.0,因此您只能通过本机上的Nginx代理访问,并使用域名来区分。

太长;不看

在MacOS与Linux中,执行以下命令 bin/dns,配置Pigsty所需的DNS记录

sudo make dns

实际上是将以下记录写入 /etc/hosts 中(需要输入sudo密码),在Windows中则自行添加至:C:\Windows\System32\drivers\etc\hosts中。

# pigsty dns records
10.10.10.10 meta pigsty p.pigsty g.pigsty a.pigsty c.pigsty l.pigsty
10.10.10.10 api.pigsty adm.pigsty cli.pigsty ddl.pigsty lab.pigsty git.pigsty sss.pigsty
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.2  pg-meta  # sandbox vip for pg-meta
10.10.10.3  pg-test  # sandbox vip for pg-test

默认域名

默认情况下,Pigsty使用的域名包括:

10.10.10.10 meta pigsty p.pigsty g.pigsty a.pigsty c.pigsty l.pigsty                      # 必选
10.10.10.10 api.pigsty adm.pigsty cli.pigsty ddl.pigsty lab.pigsty git.pigsty sss.pigsty

所有Web服务的域名均通过 nginx_upstream 进行配置,例如,沙箱demo的域名配置如下:

nginx_upstream:                   # domain names and upstream servers
  - { name: home         , domain: pigsty     , endpoint: "10.10.10.10:80"   }
  - { name: grafana      , domain: g.pigsty   , endpoint: "10.10.10.10:3000" }
  - { name: loki         , domain: l.pigsty   , endpoint: "10.10.10.10:3100" }
  - { name: prometheus   , domain: p.pigsty   , endpoint: "10.10.10.10:9090" }
  - { name: alertmanager , domain: a.pigsty   , endpoint: "10.10.10.10:9093" }
  - { name: consul       , domain: c.pigsty   , endpoint: "127.0.0.1:8500"   } #== ^ required ==#
  - { name: postgrest    , domain: api.pigsty , endpoint: "127.0.0.1:8884"   } #== v optional ==#
  - { name: pgadmin      , domain: adm.pigsty , endpoint: "127.0.0.1:8885"   }
  - { name: pgweb        , domain: cli.pigsty , endpoint: "127.0.0.1:8886"   }
  - { name: bytebase     , domain: ddl.pigsty , endpoint: "127.0.0.1:8887"   }
  - { name: jupyter      , domain: lab.pigsty , endpoint: "127.0.0.1:8888"   }
  - { name: gitea        , domain: git.pigsty , endpoint: "127.0.0.1:8889"   }
  - { name: minio        , domain: sss.pigsty , endpoint: "127.0.0.1:9000"   }

配置自定义域名

您可以定制Pigsty各自系统使用的域名,例如在Pigsty的公开Demo中,就使用了不同的域名,并由互联网DNS服务商负责解析

nginx_upstream:                   # domain names and upstream servers
  - { name: home         , domain: home.pigsty.cc , endpoint: "10.10.10.10:80"   }  # default -> index.html (80)
  - { name: grafana      , domain: demo.pigsty.cc , endpoint: "10.10.10.10:3000" }  # pigsty grafana (3000)
  - { name: loki         , domain: l.pigsty.cc    , endpoint: "10.10.10.10:3100" }  # pigsty loki (3100)
  - { name: prometheus   , domain: p.pigsty.cc    , endpoint: "10.10.10.10:9090" }  # pigsty prometheus (9090)
  - { name: alertmanager , domain: a.pigsty.cc    , endpoint: "10.10.10.10:9093" }  # pigsty alertmanager (9093)
  - { name: consul       , domain: c.pigsty.cc    , endpoint: "127.0.0.1:8500"   }  # pigsty consul UI (8500) (domain required)
  - { name: postgrest    , domain: api.pigsty.cc  , endpoint: "127.0.0.1:8884"   }  #== v optional ==#
  - { name: pgadmin      , domain: adm.pigsty.cc  , endpoint: "127.0.0.1:8885"   }
  - { name: pgweb        , domain: cli.pigsty.cc  , endpoint: "127.0.0.1:8886"   }
  - { name: bytebase     , domain: ddl.pigsty.cc  , endpoint: "127.0.0.1:8887"   }
  - { name: jupyter      , domain: lab.pigsty.cc  , endpoint: "127.0.0.1:8888"   }
  - { name: gitea        , domain: git.pigsty.cc  , endpoint: "127.0.0.1:8889"   }
  - { name: minio        , domain: sss.pigsty.cc  , endpoint: "127.0.0.1:9000"   }

如果您没有购买互联网域名,则可以自定义的域名配置到您自己网络的DNS服务器中,或者干脆写入需要访问Pigsty Web服务的服务器的静态解析记录中。

例如在Nginx与MacOS上,您需要将上述域名记录写入 /etc/hosts (需要sudo权限),在Windows中,则需要添加至:C:\Windows\System32\drivers\etc\hosts中。

4.2 - 软件准备

部署Pigsty所需的软件,安装包,以及如何在没有互联网访问的环境中进行离线安装

4.2.1 - Pigsty 软件下载

Pigsty 软件资源列表,以及从哪里获取它们。

Pigsty的唯一权威发布地址为 Github 仓库: Vonng/pigsty,所有软件发行版都位于该项目 Release 页面

太长不看

# 使用此命令下载 pigsty.tgz 源码包,该脚本将区分墙内墙外,在大陆使用CDN加速下载
bash -c "$(curl -fsSL http://download.pigsty.cc/get)"  # get latest pigsty source

# 进入Pigsty源码目录,使用自带脚本下载离线软件包,同样区分墙内墙外环境。
cd pigsty; ./download pkg

软件包列表

当前,一个发行版本包含以下软件内容:

  • pigsty.tgz必选项,Pigsty源代码
  • pkg.tgz可选项,基于CentOS 7.8.2003 提前制作的离线软件安装包;如需离线安装Pigsty,需要下载此软件包。
  • matrix.tgz可选项,如果需要安装Greenplum与MatrixDB,请额外下载此软件包
  • docker.tgz可选项,如果需要使用一些基于Docker的扩展软件应用,可下载此软件包
  • app.tgz可选项,如果想要下载Pigsty自带的可视化应用Applet样例,可下载此软件包

除了源码包 pigsty.tgz 为必选项目,其他软件包均为可选。例如,如果不下载 pkg.tgz,Pigsty就会在基础设施初始化时,直接通过互联网从 repo_upstream 下载所需的所有软件包。

下载脚本

Pigsty本身提供了一个下载脚本:download,来下载这些软件包

$ ./download
    download and extract pigsty packages: pigsty.tgz pkg.tgz app.tgz matrix.tgz
    usage:
        download pigsty pkg   # download pigsty essentials

        download pigsty.tgz   # download pigsty source tarball
        download pkg.tgz      # download pigsty offline pkgs
        download app.tgz      # download extra pigsty apps
        download matrix.tgz   # download matrixdb packages
        download docker.tgz   # download docker images cache

        download pigsty       # download and extract pigsty to ~/pigsty
        download pkg          # download and extract pkg    to /www/pigsty
        download app          # download and extract app    to ~/app
        download matrix       # download and extract matrix to /www/matrix

此脚本会自动检测当前主机网络环境(by ping google),正常从Github下载Release,墙内则通过腾讯CDN下载软件包。

4.2.2 - Pigsty 离线安装

如何在没有互联网访问的环境中离线安装Pigsty

Pigsty是一个复杂的软件系统,为了确保系统的稳定,Pigsty会在初始化过程中从互联网下载所有依赖的软件包并建立本地仓库 (本地Yum源)。

所有依赖的软件总大小约1GB左右,下载速度取决于用户的网络情况。尽管Pigsty已经尽量使用镜像源以加速下载,但少量包的下载仍可能受到防火墙的阻挠,可能出现非常慢的情况。用户可以通过 proxy_env 配置项设置下载代理,以完成首次下载。

如果您使用了不同于CentOS 7.8的操作系统,通常建议用户采用完整的在线下载安装流程。并在首次初始化完成后缓存下载的软件,参见制作离线安装包

如果您希望跳过漫长的下载过程,或者执行控制的元节点没有互联网访问,则可以考虑下载预先打包好的离线安装包

离线安装包的内容

为了快速拉起Pigsty,建议使用离线下载软件包并上传的方式完成安装。

离线安装包收纳了本地Yum源的所有软件包。默认情况下,Pigsty会在基础设施初始化时创建本地Yum源,

{{ nginx_home }}
  |---- {{ repo_name }}.repo
  ^---- {{ repo_name}}/repo_complete
  ^---- {{ repo_name}}/**************.rpm

默认情况下,{{ nginx_home }} 是Nginx静态文件服务器的根目录,默认为/wwwrepo_name 是自定义的本地源名称,默认为pigsty

以默认情况为例,/www/pigsty 目录包含了所有 RPM 软件包,离线安装包实际上就是 /www/pigsty 目录的压缩包 。

离线安装包的原理是,Pigsty在执行基础设施初始化的过程中,会检查本地Yum源相关文件是否已经存在。如果已经存在,则会跳过下载软件包及其依赖的过程。

检测所用的标记文件为{{ nginx_home }}/{{ repo_name }}/repo_complete,默认情况下为/www/pigsty/repo_complete,如果该标记文件存在,(通常是由Pigsty在创建本地源之后设置),则表示本地源已经建立完成,可以直接使用。否则,Pigsty会执行常规的下载逻辑。下载完毕后,您可以将该目录压缩复制归档,用于加速其他环境的初始化。

沙箱环境

下载离线安装包

Pigsty自带了一个沙箱环境,沙箱环境的离线安装包默认放置于files目录中,可以从Github Release页面下载。

VERSION=v1.5.1
curl -SL https://github.com/Vonng/pigsty/releases/download/${VERSION}/pkg.tgz -o /tmp/pkg.tgz

Pigsty的官方CDN也提供最新版本的pkg.tgz下载,只需要执行以下命令即可。

curl http://download.pigsty.cc/v1.5.1/pkg.tgz -o /tmp/pkg.tgz

上传离线安装包

使用Pigsty沙箱时,下载离线安装包至本地files目录后,则可以直接使用 Makefile 提供的快捷指令make copy-pkg上传离线安装包至元节点上。

使用 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 沙箱时,可以通过 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"

在生产环境离线安装包

在生产环境使用离线安装包前,您必须确保生产环境的操作系统与制作该离线安装包的机器操作系统一致。Pigsty提供的离线安装包默认使用CentOS 7.8。

使用不同操作系统版本的离线安装包可能会出错,也可能不会,我们强烈建议不要这么做。

如果需要在其他版本的操作系统(例如CentOS7.3,7.7等)上运行Pigsty,建议用户在安装有同版本操作系统的沙箱中完整执行一遍初始化流程,不使用离线安装包,而是直接从上游源下载的方式进行初始化。对于没有网络访问的生产环境元节点而言,制作离线软件包是至关重要的。

常规初始化完成后,用户可以通过make cache或手工执行相关命令,将特定操作系统的软件缓存打为离线安装包。供生产环境使用。

从初始化完成的本地元节点构建离线安装包:

tar -zcf /tmp/pkg.tgz -C /www pigsty     # 制作离线软件包

在生产环境使用离线安装包与沙箱环境类似,用户需要将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/

4.2.3 - Pigsty源码包

如何下载并使用可选的Pigsty Docker扩展离线镜像包

用户需要将Pigsty项目下载至元节点。

如果您是软件开发者,贡献者,则请使用Github克隆Master主干。如果您是软件用户,请务必使用具体的版本,而非Github Master分支,该分支可能处于开发中途的不一致状态中。

下载Pigsty源码

用户可以从 Github Release 页面下载最新版本的Pigsty源码包:

VERSION=v1.5.1
https://github.com/Vonng/pigsty/releases/download/${VERSION}/pigsty.tgz 

也可以从 Pigsty CDN 下载最新版本的Pigsty源代码

VERSION=v1.5.1
http://download.pigsty.cc/${VERSION}/pigsty.tgz

执行以下脚本,将自动获取最新稳定版本的Pigsty:

bash -c "$(curl -fsSL http://download.pigsty.cc/get)"

Pigsty 源码包自带的下载脚本 download 也可以用于下载特定版本的Pigsty源码包本身

./download pigsty.tgz  # 下载最新稳定版本的离线软件包至 /tmp/pigsty.tgz
./download pigsty      # 不仅下载 /tmp/pigsty.tgz ,还将其解压至 ~/pigsty ,如果目标目录已经存在则跳过解压

克隆Pigsty源代码

git clone https://github.com/Vonng/pigsty
git clone git@github.com:Vonng/pigsty.git

4.2.4 - Pigsty pkg.tgz 离线软件包

如何下载并使用可选的Pigsty离线软件包

Pigsty提供了基于 CentOS 7.8.2003 环境下制作的离线软件包,如果您正好使用此系统镜像,则可以确保无需互联网即可成功安装。

离线软件包的默认下载放置路径为/tmp/pkg.tgz,Pigsty在执行 ./configure 的过程中,如果没有发现该路径下存在可用的离线软件包,会提示您下载,您也可以跳过,直接从原始上游下载。

不使用离线软件包时,Pigsty默认会从互联网上游Repo中直接下载所需软件(约1GB),这一过程耗时取决于您的网络条件,一些来自Github或墙外的软件包可能下载速度非常缓慢,甚至完全无法访问。

如果您使用的操作系统是其他 EL7 兼容发行版,则可能存在 极个别 RPM 软件包版本不兼容问题,您可以参考 Pigsty离线安装 或 FAQ 介绍的方法,从原始上游下载替换带有问题的RPM软件包。

下载离线软件包

从Github下载最新、权威的软件包

VERSION=v1.5.1
wget https://github.com/Vonng/pigsty/releases/download/${VERSION}/pkg.tgz -o /tmp/pkg.tgz 

中国大陆可以使用CDN下载:

VERSION=v1.5.1
curl http://download.pigsty.cc/${VERSION}/pkg.tgz -o  /tmp/pkg.tgz

更简洁的方式是使用 Pigsty 源码包自带的下载脚本 download

./download pkg.tgz  # 下载最新稳定版本的离线软件包至 /tmp/pkg.tgz
./download pkg      # 不仅下载 /tmp/pkg.tgz ,还将其解压至 /www/pigsty 并配置本地静态文件源,开箱即用。

离线软件安装包快捷命令

copy-pkg:
	scp dist/${VERSION}/pkg.tgz meta:/tmp/pkg.tgz

use-pkg:
	ssh meta '/home/vagrant/pigsty/configure --ip 10.10.10.10 --non-interactive --download -m demo'

load-docker:
	ssh meta 'cat /tmp/docker.tgz | gzip -d -c - | docker load'

release-pkg: cache
	scp meta:/tmp/pkg.tgz dist/${VERSION}/pkg.tgz

rp: release-pkg

4.2.5 - Pigsty Docker扩展镜像包

如何下载并使用可选的Pigsty Docker扩展离线镜像包

Docker是开箱即用的容器基础设施,您可以使用Docker拉起开箱即用的软件容器,而无需过多关心安装、部署等运维管理细节。

Pigsty带有一些Docker应用样例,这些Docker应用都可以直接从DockerHub或其他镜像站点直接拉取。

对于没有互联网访问的场景,Pigsty制作了几个常用容器镜像的软件包:docker.tgz,这是一个可选项,包含的软件如下:

docker pull kong                     # latest # 139MB
docker pull minio/minio              # latest # 227MB
docker pull alpine                   # latest # 5.57MB
docker pull registry                 # latest # 24.2MB
docker pull dpage/pgadmin4           # latest # 341MB
docker pull sosedoff/pgweb           # latest # 192MB
docker pull postgrest/postgrest      # latest # 16.3MB
docker pull swaggerapi/swagger-ui    # latest # 77MB
docker pull bytebase/bytebase:1.0.5  # 1.0.5  # 78.1MB
docker pull vonng/pg_exporter        # latest # 7.64B
docker pull gitea/gitea              # latest # 256MB

软件包的制作方式

docker save kong alpine registry dpage/pgadmin4 sosedoff/pgweb postgrest/postgrest swaggerapi/swagger-ui minio/minio bytebase/bytebase:1.0.5 vonng/pg_exporter gitea/gitea | gzip -9 -c > /tmp/docker.tgz  

您可以直接使用 cat /tmp/docker.tgz | gzip -d -c - | docker load 的方式加载这些镜像,或者在初始化节点前,将其放置于 /tmp/docker.tgz ,则Pigsty在部署Docker时,会自动加载此位置的镜像压缩包。

下载Docker扩展软件包

从Github下载最新、权威的软件包

VERSION=v1.5.1
wget https://github.com/Vonng/pigsty/releases/download/${VERSION}/docker.tgz -o /tmp/docker.tgz 

中国大陆可以使用CDN下载:

VERSION=v1.5.1
curl http://download.pigsty.cc/${VERSION}/docker.tgz -o /tmp/docker.tgz

更简洁的方式是使用 Pigsty 源码包自带的下载脚本 download

./download docker.tgz  # 下载最新稳定版本的docker扩展软件包至 /tmp/docker.tgz

Docker扩展软件包快捷方式

copy-docker:
	scp dist/${VERSION}/docker.tgz meta:/tmp/docker.tgz

load-docker:
	ssh meta 'cat /tmp/docker.tgz | gzip -d -c - | docker load'

release-docker:
	ssh meta 'docker save kong alpine registry dpage/pgadmin4 sosedoff/pgweb postgrest/postgrest swaggerapi/swagger-ui minio/minio bytebase/bytebase:1.0.5 vonng/pg_exporter gitea/gitea | gzip -9 -c > /tmp/docker.tgz'
	scp meta:/tmp/docker.tgz dist/${VERSION}/docker.tgz

rp3: release-docker

4.2.6 - Pigsty Applet扩展软件包

如何下载并使用可选的 Pigsty 可视化小应用演示样例包 app.tgz

GitHub Repo : Vonng/pigsty-app

Pigsty提供了基于了一些可视化应用样例,这些样例及其基础数据被制成了一个单独的,可选的软件包 app.tgz,大小约 70MB。

下载应用Applet演示包

从Github下载最新、权威的软件包

VERSION=v1.5.1
wget https://github.com/Vonng/pigsty/releases/download/${VERSION}/app.tgz -o /tmp/app.tgz 

中国大陆可以使用CDN下载:

VERSION=v1.5.1
curl http://download.pigsty.cc/${VERSION}/app.tgz -o files/app.tgz

更简洁的方式是使用 Pigsty 源码包自带的下载脚本 download

./download app.tgz  # 下载最新稳定版本的离线软件包至 /tmp/app.tgz
./download app      # 不仅下载 /tmp/app.tgz ,还将其解压至 ~/app

4.2.7 - Pigsty MatrixDB扩展软件包

如何下载并使用可选的 Pigsty MatrixDB扩展离线软件包

Pigsty v1.4 引入了 MatrixDB 部署支持,这是Greenplum7 (尚未发布)的一个功能超集版本。

但并不是所有用户都会用到数据仓库,因此在Pigsty中,与Greenplum/MatrixDB相关的软件包被单独打包为一个扩展软件包 matrix.tgz

当您需要使用 MatrixDB 或 Greenplum 时,可以参考 pigsty-mxdb 配置文件直接从原始上游下载,或下载 matrix.tgz 并解压至管理节点 /www/matrix 使用。

下载离线软件包

从Github下载最新、权威的软件包

VERSION=v1.5.1
wget https://github.com/Vonng/pigsty/releases/download/${VERSION}/matrix.tgz -o /tmp/matrix.tgz 

中国大陆可以使用CDN下载:

VERSION=v1.5.1
curl http://download.pigsty.cc/${VERSION}/matrix.tgz -o  /tmp/matrix.tgz

更简洁的方式是使用 Pigsty 源码包自带的下载脚本 download

./download matrix.tgz  # 下载最新稳定版本的离线软件包至 /tmp/matrix.tgz
./download matrix      # 不仅下载 /tmp/matrix.tgz ,还将其解压至 /www/matrix 并配置本地静态文件源,开箱即用。

制作MatrixDB扩展软件包

copy-matrix:
	scp dist/${VERSION}/matrix.tgz meta:/tmp/matrix.tgz

use-matrix:
	ssh meta 'sudo tar -xf /tmp/matrix.tgz -C /www'
	scp files/matrix.repo meta:/tmp/matrix.repo
	ssh meta sudo mv -f /tmp/matrix.repo /www/matrix.repo

rp2: release-matrix
release-matrix:
	#ssh meta 'sudo cp -r /www/matrix /tmp/matrix; sudo chmod -R a+r /www/matrix'
	ssh meta sudo tar zcvf /tmp/matrix.tgz -C /www matrix
	scp meta:/tmp/matrix.tgz dist/${VERSION}/matrix.tgz`

4.2.8 - Ansible

Pigsty剧本使用Ansible编写,但用户无需了解此软件的使用细节。

Ansible剧本需要使用ansible-playbook可执行命令,Ansible可以通过包管理器安装:

# 在EL7兼容系统中可通过以下命令安装 Ansible。
yum install ansible

# 在MacOS中可以使用Homebrew安装 Ansible
brew install ansible

安装后,可以检查安装的软件版本:

$ echo $(ansible --version)
ansible 2.10.3

当使用离线软件包时,Pigsty会在配置过程中尝试从离线软件包中安装ansible。

Pigsty依赖Ansible进行环境初始化。但如果元节点本身没有安装Ansible,也没有互联网访问怎么办?

离线软件包中本身带有 Ansible,可以直接通过本地文件Yum源的方式使用。

手工从离线软件包中安装Ansible

假设用户已经将离线安装包解压至默认位置:/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

4.3 - 沙箱环境

介绍Pigsty的沙箱环境,一个配置规格、对象标识符、与默认数据库预先确定的环境,用于教学演示之用。

Pigsty支持使用 本地沙箱云端沙箱 两种方式,可用于快速在本机或云端准备标准的1/4节点演示环境。

尽管安装Pigsty已经非常简单了,但是搭建满足要求虚拟机仍然是比较费事的,您可能需要用到各类虚拟机软件。

因此Pigsty提供了沙箱环境,进一步免除用户准备环境的烦恼。完整地创建并跑通沙箱安装部署流程,对于在生产环境中部署有Pigsty 很大的帮助。

沙箱环境简介

沙箱环境是一个配置规格、对象标识符、与默认数据库预先确定的环境,无论是本地版还是云端版都保持一致。

沙箱环境使用固定的IP地址,以便于演示说明,沙箱的元节点IP地址固定为:10.10.10.1010.10.10.10 也是所有配置文件模板中元节点IP地址的占位符,执行 配置 时,该IP地址会被作为元节点的实际IP地址

您可以使用单节点沙箱,这种部署下,只有一个元节点meta,节点上部署有完整的基础设施,和一个单例Postgres数据库pg-meta

  • meta 10.10.10.10 pg-meta.pg-meta-1

单节点沙箱则适合用于个人开发、实验、学习;作为数据分析与可视化的环境;以及设计、演示、分发交互式数据应用,四节点沙箱可以完整演示Pigsty的功能,充分探索高可用架构与监控系统的能力,请您自行按需选择。

在四节点沙箱环境中,有三个额外的节点,与一个额外一套三节点PostgreSQL集群 pg-test

  • node-1 10.10.10.11 pg-test.pg-test-1
  • node-2 10.10.10.12 pg-test.pg-test-2
  • node-3 10.10.10.13 pg-test.pg-test-3

同时,沙箱环境还会使用以下两个IP地址与两条静态DNS记录,用于接入数据库集群。

  • 10.10.10.2 pg-meta
  • 10.10.10.2 pg-test

Pigsty提供了基于Vagrant的本地沙箱(使用Virtualbox拉起本地虚拟机),以及基于Terraform的云端沙箱(使用云厂商API创建虚拟机)。

  • 本地沙箱可以在普通Mac/PC上运行,不需要任何费用,但若想在本机运行完整的4节点沙箱环境,您的Mac/PC应当至少有 4C/8G的硬件规格。

  • 云端沙箱可以方便地向他人展示与共享,使用前需要您创建一个云账号,虚拟机资源按需创建使用,用后可以一键销毁,会有一些费用(通常非常便宜,一天几块钱)

沙箱环境部署

Pigsty设计了一个标准的,4节点的演示教学环境,称为沙箱环境,使用Vagrant或Terraform快速在本机或公有云上拉起所需的四台虚拟机资源,并进行部署测试。跑通流程后稍作修改,便可用于生产环境部署

]

以默认的沙箱环境为例,假设您已经在10.10.10.10元节点上完成单机Pigsty的安装:

./infra.yml # 在沙箱环境的 10.10.10.10 meta 机器上,完成完整的单机Pigsty安装

主机初始化

现希望将三个节点:10.10.10.11, 10.10.10.12, 10.10.10.13 纳入管理,则可使用 nodes.yml 剧本:

./nodes.yml -l pg-test      # 初始化集群pg-test包含的三台机器节点(配置节点+纳入监控)

执行完毕后,这三台节点已经带有DCS服务,主机监控与日志收集。可以用于后续的数据库集群部署。详情请参考节点 配置剧本

PostgreSQL部署

使用 pgsql.yml 剧本,可以在这三台节点上初始化一主两从的高可用PostgreSQL数据库集群 pg-test

./pgsql.yml  -l pg-test      # 初始化高可用PGSQL数据库集群pg-test

部署完成后,即可从监控系统 中看到新创建的PostgreSQL集群。

详情请参考:PgSQL数据库集群 配置定制剧本

Redis部署

除了标准的PostgreSQL集群,您还可以部署各种其他类型的集群,甚至其他类型的数据库。

例如在沙箱中部署Redis,可以使用Redis数据库集群 配置剧本

./nodes.yml    # 配置所有用于安装Redis的节点
./redis.yml    # 在所有节点上按照配置声明Redis

MatrixDB部署

例如在沙箱中部署开源数据仓库MatrixDB(Greenplum7),可以使用以下命令:

./configure -m mxdb  # 使用沙箱环境MatrixDB配置文件模板
./download matrix    # 下载MatrixDB软件包并构建本地源
./infra.yml -e no_cmdb=true  # 如果您准备在meta节点上部署 MatrixDB Master,添加no_cmdb选项,否则正常安装即可。   
./nodes.yml                  # 配置所有用于安装MatrixDB的节点
./pigsty-matrixdb.yml        # 在上述节点上安装MatrixDB

4.4 - 监控系统部署

如何使用Pigsty监控已有的PostgreSQL实例?如RDS for PG

对于由Pigsty所创建的实例,所有监控组件均已自动配置妥当。但对于非Pigsty所创建的现存Pigsty实例,若希望使用Pigsty监控系统的部分对其监控,则需一些额外的配置。

太长;不看

  1. 在目标实例创建监控对象:监控对象配置

  2. 在配置清单中声明该集群:

    pg-test:
      hosts:                                # 为每个实例分配唯一本地端口
        10.10.10.11: { pg_seq: 1, pg_role: primary , pg_exporter_port: 20001}
        10.10.10.12: { pg_seq: 2, pg_role: replica , pg_exporter_port: 20002}
        10.10.10.13: { pg_seq: 3, pg_role: offline , pg_exporter_port: 20003}
      vars:
        pg_cluster: pg-test                 # 填入集群名称
        pg_version: 14                      # 填入数据库大版本
        pg_databases: [{ name: test }]      # 填入数据库列表(每个数据库对象作为一个数组元素)
    
    # 在全局/集群/实例配置中提供监控用户密码 pg_monitor_username/pg_monitor_password
    
  3. 针对该集群执行剧本:./pgsql-monly.yml -l pg-test

  4. 该剧本会在Grafana中注册目标PostgreSQL数据源,因此PGCAT功能完整可用。该剧本会在元节点本地部署PG Exporter监控远程PG实例,故PGSQL中纯数据库相关指标可用。但主机节点、连接池、负载均衡、高可用Patroni相关指标则不可用。

监控部署概述

如果用户只希望使用Pigsty的监控系统部分,比如希望使用Pigsty监控系统监控已有的PostgreSQL实例,那么可以使用 仅监控部署(monitor only) 模式。仅监控模式下,您可以使用Pigsty管理监控其他PostgreSQL实例(目前默认支持10+以上的版本,更老的版本可以通过手工修改 pg_exporter 配置文件支持)

首先,您需要在1台元节点上完成标准的Pigsty的标准安装流程,然后便可以将更多的数据库实例接入监控。按照目标数据库节点的访问权限,又可以分为两种情况:

如果目标节点可被管理

如果目标DB节点可以被Pigsty所管理(ssh可达,sudo可用),那么您可以使用 pgsql.yml 剧本中的pg-exporter任务,使用相同的的方式,在目标节点上部署监控组件:PG Exporter, 您也可以使用该剧本的其他任务,在已有实例节点上部署额外的组件及其监控:连接池Pgbouncer与负载均衡器HAProxy。此外,您也可以使用 nodes.yml 中的 node-exporterpromtail 任务,部署主机节点监控与日志收集组件。从而获得与原生Pigsty数据库实例完全一致的使用体验。

因为目标数据库集群已存在,您需要参考本节的内容手工在目标数据库集群上创建监控用户、模式与扩展。其余流程与完整部署并无区别。

# 修改pigsty配置参数,在节点上添加yum repo,然后通过yum安装软件包
exporter_install: yum # none|yum|binary, none by default
exporter_repo_url: http://<your primary ip address>/pigsty.repo

./nodes.yml -l <yourcluster> -t node-exporter  # 部署节点指标监控
./nodes.yml -l <yourcluster> -t promtail       # 部署节点日志收集
./pgsql.yml -l <yourcluster> -t pg-exporter    # 部署PG指标监控收集

如果只有数据库连接串

如果您只能通过PGURL(数据库连接串)的方式访问目标数据库,则可以考虑使用仅监控模式/精简模式(Monitor Only:Monly)监控目标数据库。在此模式下,所有监控组件均部署在安装Pigsty的元节点上。监控系统不会有 节点,连接池,负载均衡器,高可用组件的相关指标,但数据库本身,以及数据目录(Catalog)中的实时状态信息仍然可用。

为了执行精简监控部署,您同样需要参考本节的内容手工在目标数据库集群上创建监控用户、模式与扩展,并确保可以从元节点上使用监控用户访问目标数据库。此后,针对目标集群执行 pgsql-monly.yml剧本即可完成部署。

本文着重介绍此种监控部署模式

图:仅监控模式架构示意图,部署于管理机本地的多个PG Exporter用于监控多个远程数据库实例。

精简部署与标准部署的区别

Pigsty监控系统由三个核心模块组成:

事项\等级 L1 L2 L3
名称 基础部署 托管部署 完整部署
英文 basic managed full
场景 只有连接串 DB已存在,节点可管理 实例由Pigsty创建
PGCAT功能 ✅ 完整可用 ✅ 完整可用 ✅ 完整可用
PGSQL功能 ✅ 限PG指标 ✅ 限PG与节点指标 ✅ 完整功能
连接池指标 ❌ 不可用 ⚠️ 选装 ✅ 预装项
负载均衡器指标 ❌ 不可用 ⚠️ 选装 ✅ 预装项
PGLOG功能 ❌ 不可用 ⚠️ 选装 ✅ 预装项
PG Exporter ⚠️ 部署于元节点 ✅ 部署于DB节点 ✅ 部署于DB节点
Node Exporter ❌ 不部署 ✅ 部署于DB节点 ✅ 部署于DB节点
侵入DB节点 ✅ 无侵入 ⚠️ 安装Exporter ⚠️ 完全由Pigsty管理
监控现有实例 ✅ 可支持 ✅ 可支持 ❌ 仅用于Pigsty托管实例
监控用户与视图 人工创建 人工创建 Pigsty自动创建
部署使用剧本 pgsql-monly.yml pgsql.yml -t pg-exporter,promtail
nodes.yml -t node-exporter
pgsql.yml -t pg-exporter
nodes.yml -t node-exporter
所需权限 元节点可达的PGURL DB节点ssh与sudo权限 DB节点ssh与sudo权限
功能概述 基础功能:PGCAT+PGSQL 大部分功能 完整功能

监控已有实例:精简模式

为数据库实例部署监控系统分为三步:准备监控对象修改配置清单执行部署剧本

准备监控对象

为了将外部现存PostgreSQL实例纳入监控,您需要有一个可用于访问该实例/集群的连接串。任何可达连接串(业务用户,超级用户)均可使用,但我们建议使用一个专用监控用户以避免权限泄漏。

  • 监控用户:默认使用的用户名为 dbuser_monitor, 该用户需要属于 pg_monitor 角色组,或确保具有相关视图访问权限。
  • 监控认证:默认使用密码访问,您需要确保HBA策略允许监控用户从管理机或DB节点本地访问数据库。
  • 监控模式:固定使用名称 monitor,用于安装额外的监控视图与扩展插件,非必选,但强烈建议创建。
  • 监控扩展:强烈建议启用PG自带的监控扩展 pg_stat_statements

关于监控对象的准备细节,请参考文后:监控对象配置 一节。

修改配置清单

如同部署一个全新的Pigsty实例一样,您需要在配置清单(配置文件或CMDB)中声明该目标集群。例如,为集群与实例指定身份标识。不同之处在于,您还需要在实例层次为每一个实例手工分配一个唯一的本地端口号( pg_exporter_port)。

下面是一个数据库集群声明样例:

pg-test:
  hosts:                                # 为每个实例分配唯一本地端口
    10.10.10.11: { pg_seq: 1, pg_role: primary , pg_exporter_port: 20001}
    10.10.10.12: { pg_seq: 2, pg_role: replica , pg_exporter_port: 20002}
    10.10.10.13: { pg_seq: 3, pg_role: offline , pg_exporter_port: 20003}
  vars:
    pg_cluster: pg-test                 # 填入集群名称
    pg_version: 14                      # 填入数据库大版本
    pg_databases: [{ name: test }]      # 填入数据库列表(每个数据库对象作为一个数组元素)
    
# 在全局/集群/实例配置中提供监控用户密码 pg_monitor_username/pg_monitor_password

注,即使您通过域名访问数据库,依然需要通过填入实际IP地址的方式来声明数据库集群。

若要启用PGCAT功能,您需要显式在 pg_databases 中列出目标集群的数据库名称列表,在此列表中的数据库将被注册为Grafana的数据源,您可以直接通过Grafana访问该实例的Catalog数据。若您不希望使用PGCAT相关功能,不设置该变量,或置为空数组即可。

连接信息

说明:Pigsty将默认使用以下规则生成监控连接串。但参数 pg_exporter_url 存在时,将直接覆盖拼接连接串。

postgres://{{ pg_monitor_username }}:{{ pg_monitor_password }}@{{ inventory_hostname }}:{{ pg_port }}/postgres?sslmode=disable

您可以在全局使用统一的监控用户/密码设置,或者在集群层面实例层次根据实际情况按需配置以下连接参数

pg_monitor_username: dbuser_monitor  # 监控用户名,若使用全局统一配置则无需在此配置
pg_monitor_password: DBUser.Monitor  # 监控用户密码,若使用全局统一配置则无需在此配置
pg_port: 5432                        # 若使用非标准的数据库端口,在此修改
示例:在实例层面指定连接信息 ```yaml pg-test: hosts: # Specify the access URL for the instance 10.10.10.11: pg_seq: 1 pg_role: primary pg_exporter_port: 20001 pg_monitor_username: monitor_user1 pg_monitor_password: monitor_pass1 10.10.10.12: pg_seq: 2 pg_role: replica pg_exporter_port: 20002 # Specify pg_exporter_url directly pg_exporter_url: 'postgres://someuser:pass@rds.pg.hongkong.xxx:5432/postgres?sslmode=disable'' 10.10.10.13: pg_seq: 3 pg_role: offline pg_exporter_port: 20003 pg_monitor_username: monitor_user3 pg_monitor_password: monitor_pass3 vars: pg_cluster: pg-test # Fill in cluster name pg_version: 14 # Fill in the major version of the database pg_databases: [{ name: test }] # Fill in the database list (each database object as an array element) ```

执行部署剧本

集群声明完成后,将其纳入监控非常简单,在元节点上针对目标集群使用剧本 pgsql-monly.yml 即可:

./pgsql-monly.yml -l <cluster>     # 在指定集群上完成监控部署

监控已有实例:托管部署

在托管部署模式下,目标DB节点可以被Pigsty所管理(ssh可达,sudo可用),用户将在已有的节点上加装以下监控组件:promtail, node_exporter, pg_exporter。

您可以使用 nodes.yml中的node-exporter任务,以及 pgsql.yml 剧本中的pg-exporter任务,在目标节点上部署监控组件:node_exporterpg_exporter

因为目标数据库集群已存在,您需要在目标数据库集群上创建监控用户、模式与扩展

# 修改pigsty配置参数,在节点上添加yum repo,然后通过yum安装软件包
exporter_install: yum # none|yum|binary, none by default
exporter_repo_url: http://<your primary ip address>/pigsty.repo

./nodes.yml -l <yourcluster> -t promtail       # 部署节点日志收集(可选,注意日志位置)
./nodes.yml -l <yourcluster> -t node-exporter  # 部署节点指标监控
./pgsql.yml -l <yourcluster> -t pg-exporter    # 部署PG指标监控收集

exporter_install的值为yum时,Pigsty会从 exporter_repo_url 指定的URL下载Repo文件至节点本地的/etc/yum.repos.d中。通常您应当填入管理节点上的Pigsty本地源地址,例如:http://10.10.10.10/pigsty.repo


监控对象配置

如何在已有实例上配置监控所需的用户,模式,扩展、视图与函数。

监控用户

以Pigsty默认使用的监控用户dbuser_monitor为例,在目标数据库集群创建以下用户。

CREATE USER dbuser_monitor;
GRANT pg_monitor TO dbuser_monitor;
COMMENT ON ROLE dbuser_monitor IS 'system monitor user';
ALTER USER dbuser_monitor SET log_min_duration_statement = 1000;
ALTER USER dbuser_monitor PASSWORD 'DBUser.Monitor'; -- 按需修改监控用户密码(建议修改!!)

请注意,这里创建的监控用户与密码需要与 pg_monitor_usernamepg_monitor_password 保持一致。

配置数据库 pg_hba.conf 文件,添加以下规则以允许监控用户从本地,以及管理机使用密码访问数据库。

# allow local role monitor with password
local   all  dbuser_monitor                    md5
host    all  dbuser_monitor  127.0.0.1/32      md5
host    all  dbuser_monitor  <管理机器IP地址>/32 md5

监控模式

监控模式与扩展是可选项,即使没有,Pigsty监控系统的主体也可以正常工作,但我们强烈建议创建监控模式,并至少启用PG官方自带的 pg_stat_statements,该扩展提供了关于查询性能的重要数据。注意:该扩展必须列入数据库参数shared_preload_libraries 中方可生效,修改该参数需要重启数据库。

创建扩展模式:

CREATE SCHEMA IF NOT EXISTS monitor;               -- 创建监控专用模式
GRANT USAGE ON SCHEMA monitor TO dbuser_monitor;   -- 允许监控用户使用

监控扩展

创建扩展插件:

-- 强烈建议启用 pg_stat_statements 扩展
CREATE EXTENSION IF NOT EXISTS "pg_stat_statements" WITH SCHEMA "monitor";

-- 可选的其他扩展
CREATE EXTENSION IF NOT EXISTS "pgstattuple" WITH SCHEMA "monitor";
CREATE EXTENSION IF NOT EXISTS "pg_qualstats" WITH SCHEMA "monitor";
CREATE EXTENSION IF NOT EXISTS "pg_buffercache" WITH SCHEMA "monitor";
CREATE EXTENSION IF NOT EXISTS "pageinspect" WITH SCHEMA "monitor";
CREATE EXTENSION IF NOT EXISTS "pg_prewarm" WITH SCHEMA "monitor";
CREATE EXTENSION IF NOT EXISTS "pg_visibility" WITH SCHEMA "monitor";
CREATE EXTENSION IF NOT EXISTS "pg_freespacemap" WITH SCHEMA "monitor";

监控视图

监控视图提供了若干常用的预处理结果,并对某些需要高权限的监控指标进行权限封装(例如共享内存分配),便于查询与使用。强烈建议在所有需要监控的数据库中创建

监控模式与监控视图定义
--==================================================================--
--                            Monitor Schema                        --
--==================================================================--

----------------------------------------------------------------------
-- cleanse
----------------------------------------------------------------------
CREATE SCHEMA IF NOT EXISTS monitor;
GRANT USAGE ON SCHEMA monitor TO dbuser_monitor;
GRANT USAGE ON SCHEMA monitor TO "{{ pg_admin_username }}";
GRANT USAGE ON SCHEMA monitor TO "{{ pg_replication_username }}";

--==================================================================--
--                            Monitor Views                         --
--==================================================================--

----------------------------------------------------------------------
-- Table bloat estimate : monitor.pg_table_bloat
----------------------------------------------------------------------
DROP VIEW IF EXISTS monitor.pg_table_bloat CASCADE;
CREATE OR REPLACE VIEW monitor.pg_table_bloat AS
SELECT CURRENT_CATALOG AS datname, nspname, relname , tblid , bs * tblpages AS size,
       CASE WHEN tblpages - est_tblpages_ff > 0 THEN (tblpages - est_tblpages_ff)/tblpages::FLOAT ELSE 0 END AS ratio
FROM (
         SELECT ceil( reltuples / ( (bs-page_hdr)*fillfactor/(tpl_size*100) ) ) + ceil( toasttuples / 4 ) AS est_tblpages_ff,
                tblpages, fillfactor, bs, tblid, nspname, relname, is_na
         FROM (
                  SELECT
                      ( 4 + tpl_hdr_size + tpl_data_size + (2 * ma)
                          - CASE WHEN tpl_hdr_size % ma = 0 THEN ma ELSE tpl_hdr_size % ma END
                          - CASE WHEN ceil(tpl_data_size)::INT % ma = 0 THEN ma ELSE ceil(tpl_data_size)::INT % ma END
                          ) AS tpl_size, (heappages + toastpages) AS tblpages, heappages,
                      toastpages, reltuples, toasttuples, bs, page_hdr, tblid, nspname, relname, fillfactor, is_na
                  FROM (
                           SELECT
                               tbl.oid AS tblid, ns.nspname , tbl.relname, tbl.reltuples,
                               tbl.relpages AS heappages, coalesce(toast.relpages, 0) AS toastpages,
                               coalesce(toast.reltuples, 0) AS toasttuples,
                               coalesce(substring(array_to_string(tbl.reloptions, ' ') FROM 'fillfactor=([0-9]+)')::smallint, 100) AS fillfactor,
                               current_setting('block_size')::numeric AS bs,
                               CASE WHEN version()~'mingw32' OR version()~'64-bit|x86_64|ppc64|ia64|amd64' THEN 8 ELSE 4 END AS ma,
                               24 AS page_hdr,
                               23 + CASE WHEN MAX(coalesce(s.null_frac,0)) > 0 THEN ( 7 + count(s.attname) ) / 8 ELSE 0::int END
                                   + CASE WHEN bool_or(att.attname = 'oid' and att.attnum < 0) THEN 4 ELSE 0 END AS tpl_hdr_size,
                               sum( (1-coalesce(s.null_frac, 0)) * coalesce(s.avg_width, 0) ) AS tpl_data_size,
                               bool_or(att.atttypid = 'pg_catalog.name'::regtype)
                                   OR sum(CASE WHEN att.attnum > 0 THEN 1 ELSE 0 END) <> count(s.attname) AS is_na
                           FROM pg_attribute AS att
                                    JOIN pg_class AS tbl ON att.attrelid = tbl.oid
                                    JOIN pg_namespace AS ns ON ns.oid = tbl.relnamespace
                                    LEFT JOIN pg_stats AS s ON s.schemaname=ns.nspname AND s.tablename = tbl.relname AND s.inherited=false AND s.attname=att.attname
                                    LEFT JOIN pg_class AS toast ON tbl.reltoastrelid = toast.oid
                           WHERE NOT att.attisdropped AND tbl.relkind = 'r' AND nspname NOT IN ('pg_catalog','information_schema')
                           GROUP BY 1,2,3,4,5,6,7,8,9,10
                       ) AS s
              ) AS s2
     ) AS s3
WHERE NOT is_na;
COMMENT ON VIEW monitor.pg_table_bloat IS 'postgres table bloat estimate';

----------------------------------------------------------------------
-- Index bloat estimate : monitor.pg_index_bloat
----------------------------------------------------------------------
DROP VIEW IF EXISTS monitor.pg_index_bloat CASCADE;
CREATE OR REPLACE VIEW monitor.pg_index_bloat AS
SELECT CURRENT_CATALOG AS datname, nspname, idxname AS relname, tblid, idxid, relpages::BIGINT * bs AS size,
       COALESCE((relpages - ( reltuples * (6 + ma - (CASE WHEN index_tuple_hdr % ma = 0 THEN ma ELSE index_tuple_hdr % ma END)
                                               + nulldatawidth + ma - (CASE WHEN nulldatawidth % ma = 0 THEN ma ELSE nulldatawidth % ma END))
                                  / (bs - pagehdr)::FLOAT  + 1 )), 0) / relpages::FLOAT AS ratio
FROM (
         SELECT nspname,idxname,indrelid AS tblid,indexrelid AS idxid,
                reltuples,relpages,
                current_setting('block_size')::INTEGER                                                               AS bs,
                (CASE WHEN version() ~ 'mingw32' OR version() ~ '64-bit|x86_64|ppc64|ia64|amd64' THEN 8 ELSE 4 END)  AS ma,
                24                                                                                                   AS pagehdr,
                (CASE WHEN max(COALESCE(pg_stats.null_frac, 0)) = 0 THEN 2 ELSE 6 END)                               AS index_tuple_hdr,
                sum((1.0 - COALESCE(pg_stats.null_frac, 0.0)) *
                    COALESCE(pg_stats.avg_width, 1024))::INTEGER                                                     AS nulldatawidth
         FROM pg_attribute
                  JOIN (
             SELECT pg_namespace.nspname,
                    ic.relname                                                   AS idxname,
                    ic.reltuples,
                    ic.relpages,
                    pg_index.indrelid,
                    pg_index.indexrelid,
                    tc.relname                                                   AS tablename,
                    regexp_split_to_table(pg_index.indkey::TEXT, ' ') :: INTEGER AS attnum,
                    pg_index.indexrelid                                          AS index_oid
             FROM pg_index
                      JOIN pg_class ic ON pg_index.indexrelid = ic.oid
                      JOIN pg_class tc ON pg_index.indrelid = tc.oid
                      JOIN pg_namespace ON pg_namespace.oid = ic.relnamespace
                      JOIN pg_am ON ic.relam = pg_am.oid
             WHERE pg_am.amname = 'btree' AND ic.relpages > 0 AND nspname NOT IN ('pg_catalog', 'information_schema')
         ) ind_atts ON pg_attribute.attrelid = ind_atts.indexrelid AND pg_attribute.attnum = ind_atts.attnum
                  JOIN pg_stats ON pg_stats.schemaname = ind_atts.nspname
             AND ((pg_stats.tablename = ind_atts.tablename AND pg_stats.attname = pg_get_indexdef(pg_attribute.attrelid, pg_attribute.attnum, TRUE))
                 OR (pg_stats.tablename = ind_atts.idxname AND pg_stats.attname = pg_attribute.attname))
         WHERE pg_attribute.attnum > 0
         GROUP BY 1, 2, 3, 4, 5, 6
     ) est;
COMMENT ON VIEW monitor.pg_index_bloat IS 'postgres index bloat estimate (btree-only)';


----------------------------------------------------------------------
-- Relation Bloat : monitor.pg_bloat
----------------------------------------------------------------------
DROP VIEW IF EXISTS monitor.pg_bloat CASCADE;
CREATE OR REPLACE VIEW monitor.pg_bloat AS
SELECT coalesce(ib.datname, tb.datname)                                                   AS datname,
       coalesce(ib.nspname, tb.nspname)                                                   AS nspname,
       coalesce(ib.tblid, tb.tblid)                                                       AS tblid,
       coalesce(tb.nspname || '.' || tb.relname, ib.nspname || '.' || ib.tblid::RegClass) AS tblname,
       tb.size                                                                            AS tbl_size,
       CASE WHEN tb.ratio < 0 THEN 0 ELSE round(tb.ratio::NUMERIC, 6) END                 AS tbl_ratio,
       (tb.size * (CASE WHEN tb.ratio < 0 THEN 0 ELSE tb.ratio::NUMERIC END)) ::BIGINT    AS tbl_wasted,
       ib.idxid,
       ib.nspname || '.' || ib.relname                                                    AS idxname,
       ib.size                                                                            AS idx_size,
       CASE WHEN ib.ratio < 0 THEN 0 ELSE round(ib.ratio::NUMERIC, 5) END                 AS idx_ratio,
       (ib.size * (CASE WHEN ib.ratio < 0 THEN 0 ELSE ib.ratio::NUMERIC END)) ::BIGINT    AS idx_wasted
FROM monitor.pg_index_bloat ib
         FULL OUTER JOIN monitor.pg_table_bloat tb ON ib.tblid = tb.tblid;

COMMENT ON VIEW monitor.pg_bloat IS 'postgres relation bloat detail';


----------------------------------------------------------------------
-- monitor.pg_index_bloat_human
----------------------------------------------------------------------
DROP VIEW IF EXISTS monitor.pg_index_bloat_human CASCADE;
CREATE OR REPLACE VIEW monitor.pg_index_bloat_human AS
SELECT idxname                            AS name,
       tblname,
       idx_wasted                         AS wasted,
       pg_size_pretty(idx_size)           AS idx_size,
       round(100 * idx_ratio::NUMERIC, 2) AS idx_ratio,
       pg_size_pretty(idx_wasted)         AS idx_wasted,
       pg_size_pretty(tbl_size)           AS tbl_size,
       round(100 * tbl_ratio::NUMERIC, 2) AS tbl_ratio,
       pg_size_pretty(tbl_wasted)         AS tbl_wasted
FROM monitor.pg_bloat
WHERE idxname IS NOT NULL;
COMMENT ON VIEW monitor.pg_index_bloat_human IS 'postgres index bloat info in human-readable format';

----------------------------------------------------------------------
-- monitor.pg_table_bloat_human
----------------------------------------------------------------------
DROP VIEW IF EXISTS monitor.pg_table_bloat_human CASCADE;
CREATE OR REPLACE VIEW monitor.pg_table_bloat_human AS
SELECT tblname                                          AS name,
       idx_wasted + tbl_wasted                          AS wasted,
       pg_size_pretty(idx_wasted + tbl_wasted)          AS all_wasted,
       pg_size_pretty(tbl_wasted)                       AS tbl_wasted,
       pg_size_pretty(tbl_size)                         AS tbl_size,
       tbl_ratio,
       pg_size_pretty(idx_wasted)                       AS idx_wasted,
       pg_size_pretty(idx_size)                         AS idx_size,
       round(idx_wasted::NUMERIC * 100.0 / idx_size, 2) AS idx_ratio
FROM (SELECT datname,
             nspname,
             tblname,
             coalesce(max(tbl_wasted), 0)                         AS tbl_wasted,
             coalesce(max(tbl_size), 1)                           AS tbl_size,
             round(100 * coalesce(max(tbl_ratio), 0)::NUMERIC, 2) AS tbl_ratio,
             coalesce(sum(idx_wasted), 0)                         AS idx_wasted,
             coalesce(sum(idx_size), 1)                           AS idx_size
      FROM monitor.pg_bloat
      WHERE tblname IS NOT NULL
      GROUP BY 1, 2, 3
     ) d;
COMMENT ON VIEW monitor.pg_table_bloat_human IS 'postgres table bloat info in human-readable format';



----------------------------------------------------------------------
-- Activity Overview: monitor.pg_session
----------------------------------------------------------------------
DROP VIEW IF EXISTS monitor.pg_session CASCADE;
CREATE OR REPLACE VIEW monitor.pg_session AS
SELECT coalesce(datname, 'all') AS datname, numbackends, active, idle, ixact, max_duration, max_tx_duration, max_conn_duration
FROM (
         SELECT datname,
                count(*)                                         AS numbackends,
                count(*) FILTER ( WHERE state = 'active' )       AS active,
                count(*) FILTER ( WHERE state = 'idle' )         AS idle,
                count(*) FILTER ( WHERE state = 'idle in transaction'
                    OR state = 'idle in transaction (aborted)' ) AS ixact,
                max(extract(epoch from now() - state_change))
                FILTER ( WHERE state = 'active' )                AS max_duration,
                max(extract(epoch from now() - xact_start))      AS max_tx_duration,
                max(extract(epoch from now() - backend_start))   AS max_conn_duration
         FROM pg_stat_activity
         WHERE backend_type = 'client backend'
           AND pid <> pg_backend_pid()
         GROUP BY ROLLUP (1)
         ORDER BY 1 NULLS FIRST
     ) t;
COMMENT ON VIEW monitor.pg_session IS 'postgres activity group by session';


----------------------------------------------------------------------
-- Sequential Scan: monitor.pg_seq_scan
----------------------------------------------------------------------
DROP VIEW IF EXISTS monitor.pg_seq_scan CASCADE;
CREATE OR REPLACE VIEW monitor.pg_seq_scan AS
    SELECT schemaname                                                        AS nspname,
           relname,
           seq_scan,
           seq_tup_read,
           seq_tup_read / seq_scan                                           AS seq_tup_avg,
           idx_scan,
           n_live_tup + n_dead_tup                                           AS tuples,
           round(n_live_tup * 100.0::NUMERIC / (n_live_tup + n_dead_tup), 2) AS live_ratio
    FROM pg_stat_user_tables
    WHERE seq_scan > 0
      and (n_live_tup + n_dead_tup) > 0
    ORDER BY seq_scan DESC;
COMMENT ON VIEW monitor.pg_seq_scan IS 'table that have seq scan';
查看共享内存分配的函数(PG13以上可用)
DROP FUNCTION IF EXISTS monitor.pg_shmem() CASCADE;
CREATE OR REPLACE FUNCTION monitor.pg_shmem() RETURNS SETOF
   pg_shmem_allocations AS $$ SELECT * FROM pg_shmem_allocations;$$ LANGUAGE SQL SECURITY DEFINER;
COMMENT ON FUNCTION monitor.pg_shmem() IS 'security wrapper for pg_shmem';

4.5 - 安全考量

生产网段隔离 + Pigsty默认的权限模型通常足以满足一般安全要求

Pigsty依赖的工作假设是,部署位于内网工作环境。

如果您在带有公网IP网卡的机器上安装部署Pigsty,需要特别注意网络防火墙相关配置。

通常建议您开启外网网卡上的防火墙进行端口过滤,只允许 80 端口的Web服务入站流量,请尽可能避免直接通过公网端口使用数据库。

依赖内网网络安全,辅以Pigsty默认的权限模型,通常足以满足一般安全要求。

通常不建议您自行折腾CA,SSL,除非您真的知道自己在做什么。

网络安全

  • 确保生产网段与开发、公网隔离
  • 确保元节带有合理的访问控制机制(严格限制仅DBA可登录)

数据库安全

元数据安全

  • 限制Consul UI界面访问权限
  • 限制ETCD访问
  • 为Consul启用SSL
  • 为ETCD启用SSL

4.6 - 部署样例

在实际环境中部署Pigsty的几个例子

4.6.1 - Vagrant沙箱环境

针对本地Vagrant沙箱的Pigsty配置示例

Pigsty自带一个基于Vagrant的沙箱环境

该沙箱所使用的配置文件即Pigsty根目录中的 pigsty.yml ,Github原地址为:https://github.com/Vonng/pigsty/blob/master/pigsty.yml

该配置文件可作为一个标准的学习样例,例如使用相同规格的虚拟机环境部署时,通常只需要在这份配置文件的基础上进行极少量修改就可以直接使用。

4.6.2 - 腾讯云VPC部署

使用腾讯云VPC虚拟机部署Pigsty

本样例将基于腾讯云VPC部署Pigsty

资源准备

申请虚拟机

买几台虚拟机,如下图所示,其中11这一台作为元节点,带有公网IP,数据库节点3台,普通1核1G即可。

配置SSH远程登录

现在假设我们的管理用户名为vonng,就是我啦!现在首先配置我在元节点上到其他三台节点的ssh免密码访问。

# vonng@172.21.0.11           # meta
ssh-copy-id root@172.21.0.3   # pg-test-1
ssh-copy-id root@172.21.0.4   # pg-test-2
ssh-copy-id root@172.21.0.16  # pg-test-3
scp ~/.ssh/id_rsa.pub root@172.21.0.3:/tmp/
scp ~/.ssh/id_rsa.pub root@172.21.0.4:/tmp/
scp ~/.ssh/id_rsa.pub root@172.21.0.16:/tmp/
ssh root@172.21.0.3 'useradd vonng; mkdir -m 700 -p /home/vonng/.ssh; mv /tmp/id_rsa.pub /home/vonng/.ssh/authorized_keys; chown -R vonng /home/vonng; chmod 0600 /home/vonng/.ssh/authorized_keys;'
ssh root@172.21.0.4 'useradd vonng; mkdir -m 700 -p /home/vonng/.ssh; mv /tmp/id_rsa.pub /home/vonng/.ssh/authorized_keys; chown -R vonng /home/vonng; chmod 0600 /home/vonng/.ssh/authorized_keys;'
ssh root@172.21.0.16 'useradd vonng; mkdir -m 700 -p /home/vonng/.ssh; mv /tmp/id_rsa.pub /home/vonng/.ssh/authorized_keys; chown -R vonng /home/vonng; chmod 0600 /home/vonng/.ssh/authorized_keys;'

然后配置该用户免密码执行sudo的权限:

ssh root@172.21.0.3  "echo '%vonng ALL=(ALL) NOPASSWD: ALL' > /etc/sudoers.d/vonng"
ssh root@172.21.0.4  "echo '%vonng ALL=(ALL) NOPASSWD: ALL' > /etc/sudoers.d/vonng"
ssh root@172.21.0.16 "echo '%vonng ALL=(ALL) NOPASSWD: ALL' > /etc/sudoers.d/vonng"

# 校验配置是否成功
ssh 172.21.0.3 'sudo ls'
ssh 172.21.0.4 'sudo ls'
ssh 172.21.0.16 'sudo ls'

下载项目

# 从Github克隆代码
git clone https://github.com/Vonng/pigsty

# 如果您不能访问Github,也可以使用Pigsty CDN下载代码包
curl http://pigsty-1304147732.cos.accelerate.myqcloud.com/latest/pigsty.tar.gz -o pigsty.tgz && tar -xf pigsty.tgz && cd pigsty 

下载离线安装包

# 从Github Release页面下载
# https://github.com/Vonng/pigsty

# 如果您不能访问Github,也可以使用Pigsty CDN下载离线软件包
curl http://pigsty-1304147732.cos.accelerate.myqcloud.com/latest/pkg.tgz -o files/pkg.tgz

# 将离线安装包解压至元节点指定位置 (也许要sudo)
mv -rf /www/pigsty /www/pigsty-backup && mkdir -p /www/pigsty
tar -xf files/pkg.tgz --strip-component=1 -C /www/pigsty/

调整配置

我们可以基于Pigsty沙箱的配置文件进行调整。因为都是普通低配虚拟机,因此不需要任何实质配置修改,只需要修改连接参数与节点信息即可。简单的说,只要改IP地址就可以了!

现在将沙箱中的IP地址全部替换为云环境中的实际IP地址。(如果使用了L2 VIP,VIP也需要替换为合理的地址)

说明 沙箱IP 虚拟机IP
元节点 10.10.10.10 172.21.0.11
数据库节点1 10.10.10.11 172.21.0.3
数据库节点2 10.10.10.12 172.21.0.4
数据库节点3 10.10.10.13 172.21.0.16
pg-meta VIP 10.10.10.2 172.21.0.8
pg-test VIP 10.10.10.3 172.21.0.9

编辑配置文件:pigsty.yml,如果都是规格差不多的虚拟机,通常您只需要修改IP地址即可。特别需要注意的是在沙箱中我们是通过SSH Alias来连接的(诸如meta, node-1之类),记得移除所有ansible_host配置,我们将直接使用IP地址连接目标节点。

cat pigsty.yml | \
	sed 's/10.10.10.10/172.21.0.11/g' |\
	sed 's/10.10.10.11/172.21.0.3/g' |\
	sed 's/10.10.10.12/172.21.0.4/g' |\
	sed 's/10.10.10.13/172.21.0.16/g' |\
	sed 's/10.10.10.2/172.21.0.8/g' |\
	sed 's/10.10.10.3/172.21.0.9/g' |\
	sed 's/10.10.10.3/172.21.0.9/g' |\
	sed 's/, ansible_host: meta//g' |\
	sed 's/ansible_host: meta//g' |\
	sed 's/, ansible_host: node-[123]//g' |\
	sed 's/vip_interface: eth1/vip_interface: eth0/g' |\
	sed 's/vip_cidrmask: 8/vip_cidrmask: 24/g' > pigsty2.yml
mv pigsty.yml pigsty-backup.yml; mv pigsty2.yml pigsty.yml

就这?

是的,配置文件已经修改完了!我们可以看看到底修改了什么东西

$ diff pigsty.yml pigsty-backup.yml
38c38
<       hosts: {172.21.0.11: {}}
---
>       hosts: {10.10.10.10: {ansible_host: meta}}
46c46
<         172.21.0.11: {pg_seq: 1, pg_role: primary}
---
>         10.10.10.10: {pg_seq: 1, pg_role: primary, ansible_host: meta}
109,111c109,111
<         vip_address: 172.21.0.8             # virtual ip address
<         vip_cidrmask: 24                     # cidr network mask length
<         vip_interface: eth0                 # interface to add virtual ip
---
>         vip_address: 10.10.10.2             # virtual ip address
>         vip_cidrmask: 8                     # cidr network mask length
>         vip_interface: eth1                 # interface to add virtual ip
120,122c120,122
<         172.21.0.3: {pg_seq: 1, pg_role: primary}
<         172.21.0.4: {pg_seq: 2, pg_role: replica}
<         172.21.0.16: {pg_seq: 3, pg_role: offline}
---
>         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: offline, ansible_host: node-3}
147,149c147,149
<         vip_address: 172.21.0.9             # virtual ip address
<         vip_cidrmask: 24                     # cidr network mask length
<         vip_interface: eth0                 # interface to add virtual ip
---
>         vip_address: 10.10.10.3             # virtual ip address
>         vip_cidrmask: 8                     # cidr network mask length
>         vip_interface: eth1                 # interface to add virtual ip
326c326
<       - 172.21.0.11 yum.pigsty
---
>       - 10.10.10.10 yum.pigsty
329c329
<       - 172.21.0.11
---
>       - 10.10.10.10
393c393
<       - server 172.21.0.11 iburst
---
>       - server 10.10.10.10 iburst
417,430c417,430
<       - 172.21.0.8  pg-meta                       # sandbox vip for pg-meta
<       - 172.21.0.9  pg-test                       # sandbox vip for pg-test
<       - 172.21.0.11 meta-1                        # sandbox node meta-1 (node-0)
<       - 172.21.0.3 node-1                        # sandbox node node-1
<       - 172.21.0.4 node-2                        # sandbox node node-2
<       - 172.21.0.16 node-3                        # sandbox node node-3
<       - 172.21.0.11 pigsty
<       - 172.21.0.11 y.pigsty yum.pigsty
<       - 172.21.0.11 c.pigsty consul.pigsty
<       - 172.21.0.11 g.pigsty grafana.pigsty
<       - 172.21.0.11 p.pigsty prometheus.pigsty
<       - 172.21.0.11 a.pigsty alertmanager.pigsty
<       - 172.21.0.11 n.pigsty ntp.pigsty
<       - 172.21.0.11 h.pigsty haproxy.pigsty
---
>       - 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
442c442
<     grafana_url: http://admin:admin@172.21.0.11:3000 # grafana url
---
>     grafana_url: http://admin:admin@10.10.10.10:3000 # grafana url
478,480c478,480
<       meta-1: 172.21.0.11                         # you could use existing dcs cluster
<       # meta-2: 172.21.0.3                       # host which have their IP listed here will be init as server
<       # meta-3: 172.21.0.4                       # 3 or 5 dcs nodes are recommend for production environment
---
>       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
692c692
<           - host    all     all                         172.21.0.11/32      md5
---
>           - host    all     all                         10.10.10.10/32      md5

执行剧本

您可以使用同样的 沙箱初始化 来完成 基础设施和数据库集群的初始化。

其输出结果除了IP地址,与沙箱并无区别。参考输出

访问Demo

现在,您可以通过公网IP访问元节点上的服务了!请注意做好信息安全工作。

与沙箱环境不同的是,如果您需要从公网访问Pigsty管理界面,需要自己把定义的域名写入/etc/hosts中,或者使用真正申请的域名。

否则就只能通过IP端口直连的方式访问,例如: http://<meta_node_public_ip>:3000

Nginx监听的域名可以通过可以通过 nginx_upstream 选项。

nginx_upstream:
  - { name: home,          host: pigsty.cc,   url: "127.0.0.1:3000"}
  - { name: consul,        host: c.pigsty.cc, url: "127.0.0.1:8500" }
  - { name: grafana,       host: g.pigsty.cc, url: "127.0.0.1:3000" }
  - { name: prometheus,    host: p.pigsty.cc, url: "127.0.0.1:9090" }
  - { name: alertmanager,  host: a.pigsty.cc, url: "127.0.0.1:9093" }
  - { name: haproxy,       host: h.pigsty.cc, url: "127.0.0.1:9091" }

4.6.3 - 生产环境部署

基于高规格硬件执行生产环境部署

5 - 模块:INFRA

在元节点提供基础设施组件服务

5.1 - INFRA概览

Pigsty提供了一套完整的,开箱即用的PaaS基础设施。

每一套 Pigsty 部署(Deployment) 中,都需要有一些基础设施,才能使整个系统正常工作。基础设施通常由专业的运维团队或云厂商负责,但Pigsty作为一个开箱即用的PaaS解决方案,将基本的基础设施集成至供给方案中。

Pigsty会在元节点(默认为当前安装的节点)上部署一套完整的基础设施,包括:

组件 端口 默认域名 说明
Nginx 80 pigsty 所有Web服务的入口,文件服务器
Yum Repo 80 yum.pigsty 本地YUM软件源
Grafana 3000 g.pigsty 监控系统/可视化平台
AlertManager 9093 a.pigsty 报警聚合管理组件
Prometheus 9090 p.pigsty 监控时序数据库
Loki 3100 l.pigsty 实时日志收集基础设施
Consul 8500 c.pigsty 分布式配置管理与服务发现
Docker 2375 - 运行无状态服务的容器平台
PostgreSQL 5432 - Pigsty CMDB
Ansible - - 用于发起管理命令的组件
Consul DNS 8600 - Consul提供的DNS服务(可选)
Dnsmasq 53 - DNS域名解析服务器(可选)
NTP 123 - NTP时间服务器(可选)

基础设施部署于 元节点 上。一套环境中包含一个或多个元节点,用于基础设施部署。除了 分布式配置存储(DCS) 之外,所有基础设施组件都采用副本式部署。

若配置有多个元节点,元节点上的DCS(etcd/consul)会共同作为DCS服务器集群。

Nginx

Nginx是Pigsty所有WebUI类服务的访问入口,默认使用管理节点80端口。

有许多带有WebUI的基础设施组件通过Nginx对外暴露服务,例如Grafana,Prometheus,AlertManager,Consul,以及HAProxy流量管理页等。 此外,YumRepo,文档,执行计划可视化器等静态文件资源也通过Nginx对外提供服务。

Nginx会根据 nginx_upstream 的内容,通过域名的方式,将访问请求转发至对应的上游组件处理。 Pigsty强烈建议使用域名访问Pigsty UI系统,而不是直接通过IP+端口的方式访问,基于以下几个理由:

  • 一些组件默认只监听 127.0.0.1 ,因此只能通过Nginx代理访问
  • 通过域名访问可以将访问收拢至Nginx,审计一切请求,并方便地集成认证机制。
  • 域名更容易记忆,并提供了配置灵活性。

如果您没有可用的互联网域名或本地DNS解析,您可以在 /etc/hostsC:\Windows\System32\drivers\etc\hosts中添加本地静态解析记录。

Nginx相关配置参数位于:配置:INFRA - NGINX

Yum Repo

Pigsty会在安装时首先建立一个本地Yum软件源,以加速后续软件安装。

该Yum源由Nginx提供服务,默认位于为 /www/pigsty,可以访问 http://yum.pigsty/pigsty 获取。Pigsty的离线软件包即是将已经建立好的Yum Repo目录整个打成压缩包。

当Pigsty尝试构建本地源时,如果发现本地源目录 /www/pigsty 已经存在,且带有 /www/pigsty/repo_complete 标记文件,则会认为本地源已经构建完成,从而跳过从原始上游下载软件的步骤,消除了对互联网访问的依赖。

Repo文件位于 /www/pigsty.repo,默认可以通过http://yum.pigsty/pigsty.repo 获取

curl http://yum.pigsty/pigsty.repo -o /etc/yum.repos.d/pigsty.repo

您也可以在没有Nginx的情况下直接使用文件本地源:

[pigsty-local]
name=Pigsty local $releasever - $basearch
baseurl=file:///www/pigsty/
enabled=1
gpgcheck=0

Yum Repo相关配置参数位于:配置:INFRA - REPO

Grafana

Grafana是开源的可视化/监控平台,是Pigsty WebUI的核心,默认监听3000端口,可以直接通过IP:3000或域名http://g.pigsty访问。

Pigsty的监控系统基于Dashboard构建,通过URL进行连接与跳转。您可以快速地在监控中下钻上卷,快速定位故障与问题。

此外,Grafana还可以用作通用的低代码前后端平台,制作交互式可视化数据应用。因此,Pigsty使用的Grafana带有一些额外的可视化插件,例如ECharts面板。

Grafana相关配置参数位于:配置:INFRA - GRAFANA

AlertManager

AlertManager是与Prometheus配套的告警平台,默认监听9093端口,可以直接通过IP:9093或域名http://a.pigsty访问。

Prometheus的告警事件会发送至AlertManager,但如果需要进一步处理,用户需要进一步对其进行配置,例如提供SMTP服务配置以发送告警邮件。

Prometheus

Prometheus是监控时序数据库,默认监听9090端口,可以直接通过IP:9090或域名http://p.pigsty访问。

Prometheus是监控用时序数据库。

  • Prometheus默认通过本地静态文件服务发现获取监控对象,并为其关联身份信息。
  • Prometheus可以选择使用Consul服务发现,自动获取监控对象。
  • Prometheus从Exporter拉取监控指标数据,进行预计算加工后存入自己的TSDB中。
  • Prometheus计算报警规则,将报警事件发往Alertmanager处理。

Prometheus相关配置参数位于:配置:INFRA - PROMETHEUS

Loki

Prometheus是监控时序数据库,默认监听3100端口。

Loki是用于日志收集的日志数据库,节点上的Promtail向元节点上的Loki推送日志。

LOKI相关配置参数位于:配置:INFRA - LOKI

Consul

Consul Server用于保存DCS的状态,达成共识,提供元数据查询服务,亦提供基于DCS的服务发现。

Consul相关配置参数位于:配置:INFRA - DCS

Docker

Pigsty默认在元节点上安装Docker,您可以拉起各式各样的无状态应用,并使用外部数据库获得生产级的持久性。Docker相关配置参数位于:配置:INFRA - DOCKER

PostgreSQL

PostgreSQL相关配置参数位于:配置:PGSQL,使用CMDB作为配置源,请参考CMDB教程

  • 用于支持各种高级功能的MetaDB(亦是一个标准的数据库集群,由Ansible拉起)

  • 用于执行剧本,发起控制的Ansible,使用动态Inventory时会访问CMDB

  • 定时任务控制器(支持备份,清理,统计,巡检,等特性),会访问CMDB

Ansible

Pigsty默认会在元节点上安装Ansible,Ansible是一个流行的运维工具,采用声明式的配置风格与幂等的剧本设计,可以极大降低系统维护的复杂度。命令行工具 pigsty-cli 会调用Ansible Playbook发起管控

Ansible相关配置参数位于:配置:INFRA - CONNECT

Dnsmasq

Dnsmasq提供环境内的DNS解析服务(可选)

  • DNS服务为可选,可使用已有DNS服务器
  • 部分DNS解析将转交由Consul DNS进行

DNSMASQ相关配置参数位于:配置:INFRA - Nameserver

NTP

NTP服务用于同步环境内所有节点的时间(可选)

NTP相关配置参数位于:配置:NODES - NTP

Demo

Pigsty 提供了一个公开演示的demo,地址为: http://demo.pigsty.cc

因为演示实例为1核1GB的空虚拟机空实例,故显示内容较为单薄,请以实际效果为准。

5.2 - INFRA配置

使用配置文件与参数描述基础设施

使用 INFRA剧本部署PGSQL集群,将集群状态调整至 PGSQL配置所描述的状态。

配置Pigsty基础设施,由INFRA系列剧本使用。

基础设施配置主要处理此类问题:本地Yum源,机器节点基础服务:DNS,NTP,内核模块,参数调优,管理用户,安装软件包,DCS Server的架设,监控基础设施的安装与初始化(Grafana,Prometheus,Alertmanager),全局流量入口Nginx的配置等等。

通常来说,基础设施部分需要修改的内容很少,通常涉及到的主要修改只是对元节点的IP地址进行文本替换,这一步会在./configure过程中自动完成,另一处偶尔需要改动的地方是 nginx_upstream中定义的访问域名。其他参数很少需要调整,按需即可。

  • CONNECT : 连接参数
  • CA : 公私钥基础设施
  • NGINX : Nginx Web服务器
  • REPO : 本地源基础设施
  • NAMESERVER : DNS服务器
  • PROMETHEUS : 监控时序数据库
  • EXPORTER : 通用Exporter配置
  • GRAFANA : Grafana可视化平台
  • LOKI : Loki日志收集平台
  • DCS : 分布式配置存储元数据库(Consul Server/ETCD)
  • CONSUL : DCS实现:Consul
  • ETCD : DCS实现:ETCD

参数概览

部署于元节点上的 基础设施 由下列配置项所描述。

ID Name Section Type Level Comment
100 proxy_env CONNECT dict G 代理服务器配置
110 ca_method CA enum G CA的创建方式
111 ca_subject CA string G 自签名CA主题
112 ca_homedir CA path G CA证书根目录
113 ca_cert CA string G CA证书
114 ca_key CA string G CA私钥名称
120 nginx_enabled NGINX bool C/I 是否启用本地源
121 nginx_port NGINX int G Nginx端口
122 nginx_home NGINX path G Nginx文件根目录
123 nginx_upstream NGINX upstream[] G Nginx上游服务器
124 nginx_indexes NGINX app[] G 首页导航栏显示的应用列表
130 repo_name REPO string G 本地源名称
131 repo_address REPO string G 本地源外部访问地址
132 repo_rebuild REPO bool A 是否重建Yum源
133 repo_remove REPO bool A 是否移除已有REPO文件
134 repo_upstreams REPO repo[] G Yum源的上游来源
135 repo_packages REPO string[] G Yum源需下载软件列表
136 repo_url_packages REPO url[] G 通过URL直接下载的软件
140 nameserver_enabled NAMESERVER bool C/I 是否在元节点上启用DNSMASQ
141 dns_records NAMESERVER string[] G 动态DNS解析记录
150 prometheus_enabled PROMETHEUS bool C/I 是否在元节点上启用Prometheus
151 prometheus_data_dir PROMETHEUS path G Prometheus数据库目录
152 prometheus_options PROMETHEUS string G Prometheus命令行参数
153 prometheus_reload PROMETHEUS bool A Reload而非Recreate
154 prometheus_sd_method PROMETHEUS enum G 服务发现机制:static
155 prometheus_scrape_interval PROMETHEUS interval G Prom抓取周期
156 prometheus_scrape_timeout PROMETHEUS interval G Prom抓取超时
157 prometheus_sd_interval PROMETHEUS interval G Prom服务发现刷新周期
160 exporter_install EXPORTER enum G 安装监控组件的方式
161 exporter_repo_url EXPORTER string G 监控组件的YumRepo
162 exporter_metrics_path EXPORTER string G 监控暴露的URL Path
170 grafana_enabled GRAFANA bool C/I 是否在元节点上启用Grafana
171 grafana_endpoint GRAFANA url G Grafana地址
172 grafana_admin_username GRAFANA string G Grafana管理员用户名
173 grafana_admin_password GRAFANA string G Grafana管理员密码
174 grafana_database GRAFANA enum G Grafana后端数据库类型
175 grafana_pgurl GRAFANA url G Grafana的PG数据库连接串
176 grafana_plugin_method GRAFANA enum G 如何安装Grafana插件
177 grafana_plugin_cache GRAFANA path G Grafana插件缓存地址
178 grafana_plugin_list GRAFANA string[] G 安装的Grafana插件列表
179 grafana_plugin_git GRAFANA url[] G 从Git安装的Grafana插件
180 loki_enabled LOKI bool C/I 是否在元节点上启用Loki
181 loki_endpoint LOKI url G 用于接收日志的loki服务端点
182 loki_clean LOKI bool A 在初始化Loki时清理数据
183 loki_options LOKI string G Loki的命令行参数
184 loki_data_dir LOKI string G Loki的数据目录
185 loki_retention LOKI interval G Loki日志默认保留天数
190 dcs_name DCS string G DCS服务名称
191 dcs_servers DCS dict G DCS服务器地址字典
192 dcs_registry DCS enum G 服务注册的位置
193 dcs_safeguard DCS bool C/A 完全禁止清理DCS实例
194 dcs_clean DCS bool C/A 初始化时清除现存DCS实例
195 consul_enabled CONSUL bool G 是否全局启用Consul
196 consul_data_dir CONSUL string G Consul数据目录
197 etcd_enabled ETCD bool G 是否全局启用ETCD
198 etcd_data_dir ETCD string G ETCD数据目录

CONNECT

proxy_env

在某些受到“互联网封锁”的地区,有些软件的下载会受到影响。例如从中国大陆访问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,mirrors.aliyuncs.com,mirrors.tuna.tsinghua.edu.cn,mirrors.zju.edu.cn"

ansible_host

如果您的目标机器藏在SSH跳板机之后,或者进行了某些定制化修改无法通过ssh ip的方式直接访问,则可以考虑使用 Ansible连接参数

例如下面的例子中,ansible_host 通过SSH别名的方式告知Pigsty通过ssh node-1 的方式而不是ssh 10.10.10.11的方式访问目标数据库节点。通过这种方式,用户可以自由指定数据库节点的连接方式,并将连接配置保存在管理用户的~/.ssh/config中独立管理。

  pg-test:
    vars: { pg_cluster: pg-test }
    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: offline, ansible_host: node-3}

ansible_host是ansible连接参数中最典型的一个。通常只要用户可以通过 ssh <name>的方式访问目标机器,为实例配置ansible_host变量,值为<name>即可,其他常用的Ansible SSH连接参数如下所示:

  • ansible_host : 在此指定目标机器的IP、主机名或SSH别名

  • ansible_port : 指定一个不同于22的SSH端口

  • ansible_user : 指定SSH使用的用户名

  • ansible_ssh_pass : SSH密码(请不要存储明文,可通过-k参数指定从键盘输入)

  • ansible_ssh_private_key_file : SSH私钥路径

  • ansible_ssh_common_args : SSH通用参数


CA

用于搭建本地公私钥基础设施,当您需要SSL证书等高级安全特性时,可以使用此任务。

ca_method

CA的创建方式, 类型:enum,层级:G,默认值为:"create"

  • create:创建新的公私钥用于CA
  • copy:拷贝现有的CA公私钥用于构建CA

ca_subject

自签名CA主题, 类型:string,层级:G,默认值为:"/CN=root-ca"

ca_homedir

CA证书根目录, 类型:path,层级:G,默认值为:"/ca"

ca_cert

CA证书名称, 类型:string,层级:G,默认值为:"ca.crt"

ca_key

CA私钥名称, 类型:string,层级:G,默认值为:"ca.key"


NGINX

Pigsty通过元节点上的Nginx对外暴露所有Web类服务,如首页,Grafana,Prometheus,AlertManager,Consul,以及可选的PGWeb与Jupyter Lab。此外,本地软件源,本地文档,与其他本地WEB工具如Pev2,Pgbadger也由Nginx对外提供服务。

您可以绕过Nginx直接通过端口访问元节点上的部分服务,但部分服务出于安全性原因不宜对外暴露,只能通过Nginx代理访问。Nginx通过域名区分不同的服务,因此,如果您为各个服务配置的域名在当前环境中无法解析,则需要您自行在/etc/hosts中配置后使用。

nginx_enabled

是否启用本地源, 类型:bool,层级:C/I,默认值为:true

是否在元节点上启用Nginx Server?

设置为false则会在当前节点跳过设置Nginx与构建本地源的过程。当您有多个元节点时,可以在备用元节点上设置此参数为false

nginx_port

本地源端口, 类型:int,层级:G,默认值为:80

Pigsty通过元节点上的该端口访问所有Web服务,请确保您可以访问元节点上的该端口。

nginx_home

本地源文件根目录, 类型:path,层级:G,默认值为:"/www"

该目录将作为HTTP服务器的根对外暴露,包含本地源,以及其他静态文件内容。

nginx_upstream

Nginx上游服务器, 类型:upstream[],层级:G,默认值为:

nginx_upstream:                   # domain names and upstream servers
- { name: home,         domain: pigsty,     endpoint: "10.10.10.10:80" }
- { name: grafana,      domain: g.pigsty,   endpoint: "10.10.10.10:3000" }
- { name: loki,         domain: l.pigsty,   endpoint: "10.10.10.10:3100" }
- { name: prometheus,   domain: p.pigsty,   endpoint: "10.10.10.10:9090" }
- { name: alertmanager, domain: a.pigsty,   endpoint: "10.10.10.10:9093" }
- { name: consul,       domain: c.pigsty,   endpoint: "127.0.0.1:8500" }

每一条记录包含三个子段:name, domain, endpoint,分别代表组件名称,外部访问域名,以及内部的TCP端点。

默认记录的name 定义是固定的,通过硬编码引用,请勿修改。您可以任意新增其他名称的上游服务器记录。

domain是外部访问此上游服务器时应当使用的域名,当您访问Pigsty Web服务时,应当使用域名通过Nginx代理访问。

endpoint是内部可达的TCP端点,占位IP地址10.10.10.10会在Configure过程中被替换为元节点IP。

如果您使用了多个元节点,并通过 grafana_enabledprometheus_enabledloki_enabled 等参数在实例层次为不同元节点分配了角色,则需要在这里将对应服务的IP地址替换为实际承载该服务的IP地址。

nginx_indexes

首页导航栏显示的应用列表, 类型:app[],层级:G,默认值为:

nginx_indexes:                            # application nav links on home page
  - { name: Pev2    , url : '/pev2'        , comment: 'postgres explain visualizer 2' }
  - { name: Logs    , url : '/logs'        , comment: 'realtime pgbadger log sample' }
  - { name: Report  , url : '/report'      , comment: 'daily log summary report ' }
  - { name: Pkgs    , url : '/pigsty'      , comment: 'local yum repo packages' }
  - { name: Repo    , url : '/pigsty.repo' , comment: 'local yum repo file' }
  - { name: ISD     , url : '${grafana}/d/isd-overview'   , comment: 'noaa isd data visualization' }
  - { name: Covid   , url : '${grafana}/d/covid-overview' , comment: 'covid data visualization' }

每一条记录都会渲染为Pigsty首页App下拉菜单的导航连接,应用均为可选项目,默认挂载于Pigsty默认服务器下http://pigsty/ 其中,url 参数指定了应用的URL PATH,特例是如果URL中存在${grafana}字符串,会被自动替换为nginx_upstream 中定义的Grafana域名。


REPO

当在元节点上安装Pigsty时,Pigsty会在本地拉起一个YUM软件源,供当前环境安装RPM软件包使用。

Pigsty在初始化过程中,会从互联网上游源(由 repo_upstreams指定), 下载所有软件包及其依赖(由 repo_packages指定)至 {{ nginx_home }} / {{ repo_name }} (默认为/www/pigsty)。所有依赖的软件总大小约1GB左右,下载速度取决于您的网络情况。

建立本地Yum源时,如果该目录已经存在,而且目录中存在名为repo_complete的标记文件,Pigsty会认为本地Yum源已经初始化完毕,跳过软件下载阶段。

尽管Pigsty已经尽量使用镜像源以加速下载,但少量包的下载仍可能受到防火墙的阻挠。如果某些软件包的下载速度过慢,您可以通过proxy_env配置项设置下载代理以完成首次下载,或直接下载预先打包好的离线安装包

离线安装包即是把{{ nginx_home }}/{{ repo_name }}目录整个打成压缩包pkg.tgz。在configure过程中,如果Pigsty发现离线软件包/tmp/pkg.tgz存在,则会将其解压至{{ nginx_home }}/{{ repo_name }}目录,进而在安装时跳过软件下载的步骤。

默认的离线安装包基于CentOS 7.8.2003 x86_64操作系统制作,如果您使用的操作系统与此不同,或并非使用全新安装的操作系统环境,则有概率出现RPM软件包冲突与依赖错误的问题,请参照FAQ解决。

repo_name

本地源名称, 类型:string,层级:G,默认值为:"pigsty",不建议修改此参数。

repo_address

本地源外部访问地址, 类型:string,层级:G,默认值为:"pigsty"

本地yum源对外提供服务的地址,可以是域名也可以是IP地址,默认为yum.pigsty

如果使用域名,您必须确保在当前环境中,该域名会正确解析到本地源所在的服务器,也就是元节点。

如果您的本地yum源没有使用标准的80端口,您需要在地址中加入端口,并与 nginx_port 变量保持一致。

您可以通过节点参数中的静态DNS配置 node_etc_hosts_default) 来为当前环境中的所有节点默认写入pigsty本地源域名。

repo_rebuild

是否重建Yum源, 类型:bool,层级:A,默认值为:false

如果为true,那么在任何情况下都会执行Repo重建的工作,即无视离线软件包存在与否。

repo_remove

是否移除已有REPO文件, 类型:bool,层级:A,默认值为:true

如果为真,在执行本地源初始化的过程中,元节点上/etc/yum.repos.d中所有已有的repo会被全部移除,备份至/etc/yum.repos.d/backup 目录中。

因为操作系统已有的源内容不可控,建议强制移除已有源并通过 repo_upstreams 进行显式配置。

当您的节点有其他自行配置的源,或需要从特定源下载一些特殊版本的RPM包时,可以设置为false,保留已有源。

repo_upstreams

Yum源的上游来源, 类型:repo[],层级:

默认使用阿里云的CentOS7镜像源,清华大学Grafana镜像源,PackageCloud的Prometheus源,PostgreSQL官方源,以及SCLo,Harbottle,Nginx等软件源。

repo_packages

Yum源需下载软件列表, 类型:string[],层级:G,默认值为:

epel-release nginx wget yum-utils yum createrepo sshpass zip unzip                                              # ----  boot   ---- #
ntp chrony uuid lz4 bzip2 nc pv jq vim-enhanced make patch bash lsof wget git tuned perf ftp lrzsz rsync        # ----  node   ---- #
numactl grubby sysstat dstat iotop bind-utils net-tools tcpdump socat ipvsadm telnet ca-certificates keepalived # ----- utils ----- #
readline zlib openssl openssh-clients libyaml libxml2 libxslt libevent perl perl-devel perl-ExtUtils*           # ---  deps:pg  --- #
readline-devel zlib-devel uuid-devel libuuid-devel libxml2-devel libxslt-devel openssl-devel libicu-devel       # --- deps:devel -- #
grafana prometheus2 pushgateway alertmanager mtail consul consul_exporter consul-template etcd dnsmasq          # -----  meta ----- #
node_exporter nginx_exporter blackbox_exporter redis_exporter                                                   # ---- exporter --- #
ansible python python-pip python-psycopg2                                                                       # - ansible & py3 - #
python3 python3-psycopg2 python36-requests python3-etcd python3-consul python36-urllib3 python36-idna python36-pyOpenSSL python36-cryptography
patroni patroni-consul patroni-etcd pgbouncer pg_cli pgbadger pg_activity tail_n_mail                           # -- pgsql common - #
pgcenter boxinfo check_postgres emaj pgbconsole pg_bloat_check pgquarrel barman barman-cli pgloader pgFormatter pitrery pspg pgxnclient PyGreSQL
postgresql14* postgis32_14* citus_14* pglogical_14* timescaledb-2-postgresql-14 pg_repack_14 wal2json_14        # -- pg14 packages -#
pg_qualstats_14 pg_stat_kcache_14 pg_stat_monitor_14 pg_top_14 pg_track_settings_14 pg_wait_sampling_14 pg_probackup-std-14
pg_statement_rollback_14 system_stats_14 plproxy_14 plsh_14 pldebugger_14 plpgsql_check_14 pgmemcache_14 # plr_14
mysql_fdw_14 ogr_fdw_14 tds_fdw_14 sqlite_fdw_14 firebird_fdw_14 hdfs_fdw_14 mongo_fdw_14 osm_fdw_14 pgbouncer_fdw_14
hypopg_14 geoip_14 rum_14 hll_14 ip4r_14 prefix_14 pguri_14 tdigest_14 topn_14 periods_14
bgw_replstatus_14 count_distinct_14 credcheck_14 ddlx_14 extra_window_functions_14 logerrors_14 mysqlcompat_14 orafce_14
repmgr_14 pg_auth_mon_14 pg_auto_failover_14 pg_background_14 pg_bulkload_14 pg_catcheck_14 pg_comparator_14
pg_cron_14 pg_fkpart_14 pg_jobmon_14 pg_partman_14 pg_permissions_14 pg_prioritize_14 pgagent_14
pgaudit16_14 pgauditlogtofile_14 pgcryptokey_14 pgexportdoc_14 pgfincore_14 pgimportdoc_14 powa_14 pgmp_14 pgq_14
pgquarrel-0.7.0-1 pgsql_tweaks_14 pgtap_14 pgtt_14 postgresql-unit_14 postgresql_anonymizer_14 postgresql_faker_14
safeupdate_14 semver_14 set_user_14 sslutils_14 table_version_14 # pgrouting_14 osm2pgrouting_14
clang coreutils diffutils rpm-build rpm-devel rpmlint rpmdevtools bison flex # gcc gcc-c++                      # - build utils - #
docker-ce docker-compose kubelet kubectl kubeadm kubernetes-cni helm                                            # - cloud native- #

每一行都是一组由空格分割的软件包名称,在这里指定的软件会通过repotrack进行下载。

repo_url_packages

通过URL直接下载的软件, 类型:url[],层级:G

通过URL,而非YUM下载一些软件:

  • pg_exporter必须项,监控系统核心组件
  • vip-manager必选项,启用L2 VIP时所必须的软件包,用于管理VIP
  • loki, promtail必选项,日志收集服务端与客户端二进制。
  • haproxy:通常为必选项,用于提供负载均衡服务,不启用/不使用时可以跳过。
  • polysh:可选,并行在多台节点上执行ssh命令
  • pev2:可选,PostgreSQL执行计划可视化
  • redis可选,当安装Redis时为必选
https://github.com/Vonng/loki-rpm/releases/download/v2.5.0/loki-2.5.0.x86_64.rpm
https://github.com/Vonng/loki-rpm/releases/download/v2.5.0/promtail-2.5.0.x86_64.rpm
https://github.com/Vonng/pg_exporter/releases/download/v0.5.0/pg_exporter-0.5.0.x86_64.rpm
https://github.com/cybertec-postgresql/vip-manager/releases/download/v1.0.2/vip-manager-1.0.2-1.x86_64.rpm
https://github.com/Vonng/haproxy-rpm/releases/download/v2.5.7/haproxy-2.5.7-1.el7.x86_64.rpm
https://github.com/Vonng/pigsty-pkg/releases/download/misc/redis-6.2.7-1.el7.remi.x86_64.rpm
https://github.com/dalibo/pev2/releases/download/v0.24.0/pev2.tar.gz
https://github.com/Vonng/pigsty-pkg/releases/download/misc/polysh-0.4-1.noarch.rpm

NAMESERVER

Pigsty默认可以使用DNSMASQ在元节点上搭建一个开箱即用的域名服务器,限于中国的互联网管理政策(53端口需备案),默认不启用。

nameserver_enabled

是否启用DNSMASQ,部署于元节点上,提供DNS服务, 类型:bool,层级:C/I,默认值为:true

dns_records

动态DNS解析记录, 类型:string[],层级:G,默认值为[]空列表,在沙箱环境中默认有以下解析记录。

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
  - 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 pg-meta-1       # sandbox instance pg-meta-1
  - 10.10.10.11 pg-test-1       # sandbox instance node-1
  - 10.10.10.12 pg-test-2       # sandbox instance node-2
  - 10.10.10.13 pg-test-3       # sandbox instance node-3

PROMETHEUS

Prometheus是Pigsty监控系统核心组件,用于拉取时序数据,进行指标预计算,评估告警规则。

prometheus_enabled

是否在元节点上启用Prometheus?类型:bool,层级:C/I,默认值为:true

如果您有多个元节点,默认情况下,Pigsty会在所有元节点上部署Prometheus。如果您想一台用于Prometheus监控指标收集,一台用于Loki日志收集,则可以在其他元节点的实例层次上将此参数设置为false

prometheus_data_dir

Prometheus数据库目录, 类型:path,层级:G,默认值为:"/data/prometheus/data"

prometheus_options

Prometheus命令行参数, 类型:string,层级:G,默认值为:"--storage.tsdb.retention=15d --enable-feature=promql-negative-offset"

默认参数会允许Prometheus启用负时间偏移量功能,并默认保留15天监控数据。如果您的磁盘有余裕,可以增大监控数据的保留时长。

prometheus_reload

在执行Prometheus任务时,是否仅仅只是重载配置,而不是整个重建。类型:bool,层级:A,默认值为:false

默认情况下,执行执行prometheus任务时会清除已有监控数据,如果设置为true,执行Prometheus任务时不会清除已有数据目录。

prometheus_sd_method

服务发现机制:static|consul, 类型:enum,层级:G,默认值为:"static"

Prometheus使用的服务发现机制,默认为static,另外的选项 consul 将使用Consul进行服务发现(将逐步弃用)。 Pigsty建议使用static服务发现,该方式提供了更高的可靠性与灵活性,Consul服务发现将逐步停止支持。

static服务发现依赖/etc/prometheus/targets/{infra,nodes,pgsql,redis}/*.yml中的配置进行服务发现。 采用这种方式的优势是,监控系统不依赖Consul,当节点宕机时,监控目标会报错提示,而不是直接消失。此外,当Pigsty监控系统与外部管控方案集成时,这种模式对原系统的侵入性较小。

可以使用以下命令,从配置文件生成Prometheus所需的监控对象配置文件。

./nodes.yml -t register_prometheus  # 生成主机监控目标列表
./pgsql.yml -t register_prometheus  # 生成PostgreSQL/Pgbouncer/Patroni/Haproxy监控目标列表
./redis.yml -t register_prometheus  # 生成Redis监控目标列表

prometheus_scrape_interval

Prometheus抓取周期, 类型:interval,层级:G,默认值为:"10s"

在生产环境,10秒 - 30秒是一个较为合适的抓取周期。如果您需要更精细的的监控数据粒度,则可以调整此参数。

prometheus_scrape_timeout

Prometheus抓取超时, 类型:interval,层级:G,默认值为:"8s"

设置抓取超时可以有效避免监控系统查询导致的雪崩,原则是本参数必须小于并接近 prometheus_scrape_interval ,确保每次抓取时长不超过抓取周期。

prometheus_sd_interval

Prometheus服务发现刷新周期, 类型:interval,层级:G,默认值为:"10s"

每隔本参数指定的时长,Prometheus就会重新检查本地文件目录,刷新监控目标对象。


EXPORTER

定义通用的指标暴露器选项,例如Exporter的安装方式,监听的URL路径等。

exporter_install

安装监控组件的方式, 类型:enum,层级:G,默认值为:"none"

指明安装Exporter的方式:

  • none:不安装,(默认行为,Exporter已经在先前由 node.pkgs 任务完成安装)
  • yum:使用yum安装(如果启用yum安装,在部署Exporter前执行yum安装 node_exporterpg_exporter
  • binary:使用拷贝二进制的方式安装(从元节点中直接拷贝node_exporterpg_exporter 二进制,不推荐)

使用yum安装时,如果指定了exporter_repo_url(不为空),在执行安装时会首先将该URL下的REPO文件安装至/etc/yum.repos.d中。这一功能可以在不执行节点基础设施初始化的环境下直接进行Exporter的安装。 不推荐普通用户使用binary安装,这种模式通常用于紧急故障抢修与临时问题修复。

<meta>:<pigsty>/files/node_exporter ->  <target>:/usr/bin/node_exporter
<meta>:<pigsty>/files/pg_exporter   ->  <target>:/usr/bin/pg_exporter

exporter_repo_url

监控组件的Yum Repo URL, 类型:string,层级:G,默认值为:""

默认为空,当 exporter_installyum 时,该参数指定的Repo会被添加至节点源列表中。

exporter_metrics_path

监控暴露的URL Path, 类型:string,层级:G,默认值为:"/metrics"

所有Exporter对外暴露指标的URL PATH,默认为/metrics,该变量被外部角色prometheus引用,Prometheus会根据这里的配置,对监控对象应用此配置。

受此参数影响的指标暴露器包括:


GRAFANA

Grafana是Pigsty监控系统的可视化平台。

grafana_enabled

是否在元节点上启用Grafana?类型:bool,层级:C/I,默认值为:true

如果您有多个元节点,默认情况下,Pigsty会在所有元节点上部署Grafana。您可以在不想启用Grafana的元节点的实例层次上将此参数设置为false

grafana_endpoint

Grafana地址, 类型:url,层级:G,默认值为:"http://10.10.10.10:3000"

Grafana对外提供服务的端点,Grafana初始化与安装监控面板会使用该端点调用Grafana API

在Configure过程中,占位IP10.10.10.10会在configure过程中被实际IP替换。

grafana_admin_username

Grafana管理员用户名, 类型:string,层级:G,默认值为:"admin"

grafana_admin_password

Grafana管理员密码, 类型:string,层级:G,默认值为:"pigsty"

grafana_database

Grafana后端数据库类型, 类型:enum,层级:G,默认值为:"sqlite3"

备选为postgres,使用postgres时,必须确保目标数据库已经存在并可以访问。即首次初始化基础设施前,无法使用元节点上的Postgres,因为Grafana先于该数据库而创建。

为了避免产生循环依赖(Grafana依赖Postgres,PostgreSQL依赖包括Grafana在内的基础设施),您需要在首次完成安装后,修改此参数并重新执行 grafana相关任务。 详情请参考【教程:使用Postgres作为Grafana后端数据库

grafana_pgurl

Grafana的PostgreSQL数据库连接串, 类型:url,层级:G,默认值为:"postgres://dbuser_grafana:DBUser.Grafana@meta:5436/grafana"

仅当参数 grafana_databasepostgres 时有效。

grafana_plugin_method

如何安装Grafana插件, 类型:enum,层级:G,默认值为:"install"

Grafana插件的供给方式

  • none:不安装插件
  • install: 安装Grafana插件(默认),若已存在则跳过。
  • always: 无论如何都重新下载安装Grafana插件

Grafana需要访问互联网以下载若干扩展插件,如果您的元节点没有互联网访问,则应当确保使用了离线安装包。 离线安装包中默认已经包含了所有下载好的Grafana插件,位于 grafana_plugin_cache 指定的路径下。当从互联网下载插件时,Pigsty会在下载完成后打包下载好的插件,并放置于该路径下。

grafana_plugin_cache

Grafana插件缓存地址, 类型:path,层级:G,默认值为:"/www/pigsty/plugins.tgz"

grafana_plugin_list

安装的Grafana插件列表, 类型:string[],层级:G,默认值为:

grafana_plugin_list:
  - marcusolsson-csv-datasource
  - marcusolsson-json-datasource
  - marcusolsson-treemap-panel

每个数组元素是一个字符串,表示插件的名称。插件会通过grafana-cli plugins install的方式进行安装。

grafana_plugin_git

从Git安装的Grafana插件, 类型:url[],层级:G,默认值为:

grafana_plugin_git:                          # plugins that will be downloaded via git
  - https://github.com/Vonng/vonng-echarts-panel

一些插件无法通过官方命令行下载,但可以通过Git Clone的方式下载。插件会通过cd /var/lib/grafana/plugins && git clone 的方式进行安装。

默认会下载一个可视化插件:vonng-echarts-panel,提供为Grafana提供Echarts绘图支持。


LOKI

LOKI是Pigsty使用的默认日志收集服务器。

loki_enabled

是否在元节点上启用Loki?类型:bool,层级:C/I,默认值为:true

如果您有多个元节点,默认情况下,Pigsty会在所有元节点上部署Loki。如果您想一台用于Prometheus监控指标收集,一台用于Loki日志收集,则可以在其他元节点的实例层次上将此参数设置为false

loki_clean

是否在安装Loki时清理数据库目录, 类型:bool,层级:A,默认值为:false

loki_endpoint

用于接收日志的loki服务端点, 类型:url,层级:G,默认值为:"http://10.10.10.10:3100/loki/api/v1/push"

loki_options

Loki的命令行参数, 类型:string,层级:G,默认值为:"-config.file=/etc/loki.yml -config.expand-env=true"

默认的配置参数用于指定Loki配置文件位置,并启用在配置文件中展开环境变量的功能,不建议移除这两个选项。

loki_data_dir

Loki的数据目录, 类型:string,层级:G,默认值为:"/data/loki"

loki_retention

Loki日志默认保留天数, 类型:interval,层级:G,默认值为:"15d"


DCS

Distributed Configuration Store (DCS) 是一种分布式,高可用的元数据库。Pigsty使用DCS来实现数据库高可用,服务发现等功能也通过DCS实现。

Pigsty目前支持使用Consul与ETCD作为DCS。通过 pg_dcs_type 指明高可用PG使用的DCS种类,通过 dcs_registry 指明服务注册的位置。

Consul服务的可用性对于数据库高可用至关重要,因此在生产环境摆弄DCS服务时,需要特别小心。DCS本身的可用性,通过多副本实现。例如,3节点的Consul集群最多允许1个节点故障,5节点的Consul集群则可以允许两个节点故障,在大规模生产环境中,建议使用至少3个DCS Server。 Pigsty使用的DCS服务器通过参数 dcs_servers 指定,您可以使用外部的现有DCS服务器集群。也可以使用Pigsty本身管理的节点部署DCS Servers。

在默认情况下,Pigsty会在节点纳入管理时(nodes.yml)部署设置DCS服务,如果当前节点定义于 dcs_servers 中,则该节点会被初始化为 DCS Server。

Pigsty会在元节点本身部署一个单节点的DCS Server,使用多个元节点时,您也可以将其复用为DCS Server。尽管如此,元节点与DCS Server并不绑定。您可以使用任意节点作为DCS Servers。

但大的原则是,在部署任意高可用数据库集群前,您应当确保所有DCS Servers已经完成初始化。

dcs_servers

DCS服务器, 类型:dict,层级:G,默认值为:

dcs_servers:
  meta-1: 10.10.10.10      # 默认在元节点上部署单个DCS Server
  # meta-2: 10.10.10.11
  # meta-3: 10.10.10.12 

字典格式,Key为DCS服务器实例名称,Value为服务器IP地址。 默认情况下,Pigsty将在节点初始化剧本中为节点配置DCS服务,默认为Consul。

您可以使用外部的DCS服务器,依次填入所有外部DCS Servers的地址即可,否则Pigsty默认将在元节点(10.10.10.10占位)上部署一个单实例DCS Server。 如果当前节点定义于 dcs_servers 中,即IP地址与任意Value匹配,则该节点会被初始化为 DCS Server,其Key将被用作Consul Server

dcs_registry

服务注册的位置, 类型:enum,层级:G,默认值为:"consul"

  • none:不执行服务注册(当执行仅监控部署时,必须指定none模式)
  • consul:将服务注册至Consul中
  • etcd:将服务注册至Etcd中(尚未支持)

pg_dcs_type

使用的DCS类型, 类型:enum,层级:G,默认值为:"consul"

有两种选项:consuletcd ,但ETCD尚未正式支持。

CONSUL

Consul用于服务网格,健康监测,传递共识,代理DCS Server访问。

dcs_safeguard

安全保险,禁止清除存在的Consul实例,类型:bool,层级:C/A,默认值为:false

如果为true,任何情况下,Pigsty剧本都不会移除运行中的Consul实例,包括 nodes-remove.yml

详情请参考 保护机制

dcs_clean

是否在初始化时抹除现存Consul实例?类型:bool,层级:C/A,默认值为:false

针对 nodes.yml 剧本的抹除豁免,如果指定该参数为真,那么在 nodes.yml 剧本执行时,会自动抹除已有的Consul实例。

只有当该参数启用时,nodes.yml 才是一个真正幂等的剧本。

这是一个危险的操作,因此必须显式指定。

安全保险参数 dcs_safeguard 打开时,本参数无效。

dcs_name

DCS集群名称, 类型:string,层级:G,默认值为:"pigsty"

在Consul中代表数据中心名称,在Etcd中没有意义。

consul_data_dir

Consul数据目录, 类型:string,层级:G,默认值为:"/data/consul"

5.3 - INFRA剧本

使用infra系列剧本在元节点上安装Pigsty,并加装可选功能。
剧本 功能 链接
infra 在元节点上完整安装Pigsty src
infra-demo 一次性完整初始化四节点演示沙箱环境的特殊剧本 src
infra-remove 在元节点上卸载Pigsty src
infra-jupyter 在元节点上加装可选数据分析服务组件组件Jupyter Lab src
infra-pgweb 在元节点上加装可选的Web客户端工具PGWeb src

infra

infra.yml 剧本会在元节点 (默认为当前节点)上完成Pigsty的安装与部署。

当您将Pigsty用作开箱即用的数据库时,只要在本节点上直接执行 infra.yml ,即可完成安装。

What

执行该剧本将完成以下任务

  • 配置元节点的目录与环境变量
  • 下载并建立一个本地yum软件源,加速后续安装。(若使用离线软件包,则跳过下载阶段)
  • 将当前元节点作为一个普通节点纳入 Pigsty 管理
  • 部署基础设施组件,包括 Prometheus, Grafana, Loki, Alertmanager, Consul Server等
  • 在当前节点上部署一个普通的PostgreSQL单实例集群,纳入监控。

Where

该剧本默认针对元节点执行

  • Pigsty默认将使用当前执行此剧本的节点作为Pigsty的元节点。
  • Pigsty在配置过程中默认会将当前节点标记为元节点,并使用当前节点首要IP地址替换配置模板中的占位IP地址10.10.10.10
  • 元节点除了可以发起管理,部署有基础设施外。与一个部署了PG的普通托管节点并无区别。
  • Pigsty默认使用元节点部署DCS Server,用于数据库高可用,但您完全可以选用外部DCS集群。
  • 使用多个元节点是可能的,参考 DCS3 配置模板:部署3节点的DCS Server,允许其中一台宕机。

How

执行该剧本的一些注意事项

  • 本剧本为幂等剧本,重复执行会抹除元节点上的Consul Server与CMDB(关闭保护选项情况下)
  • 使用离线软件包时,完整执行该剧本耗时约5-8分钟,视机器配置而异。
  • 不使用离线软件包而直接从互联网原始上游下载软件时,可能耗时10-20分钟,根据您的网络条件而异。
  • 本剧本会将元节点作为一个普通节点纳入管理,并部署PG数据库,覆盖了nodes.ymlpgsql.yml的所有内容,因此infra.yml如果可以在元节点上成功执行完毕,那么则在相同状态的普通节点上一定可以成功完成数据库部署。
  • 元节点上默认的pg-meta将用作Pigsty元数据库,用于承载高级特性。

Tasks

该剧本

./infra.yml --tags=environ                       # 重新在元节点上配置环境
./infra.yml --tags=repo -e repo_rebuild=true     # 强制重新创建本地源
./infra.yml --tags=repo_upstream                 # 加入上游YumRepo
./infra.yml --tags=prometheus                    # 重新创建Prometheus
./infra.yml --tags=nginx_config,nginx_restart    # 重新生成Nginx配置文件并重启
……

配置清单中,隶属于 meta分组下的节点将被设置 meta_node 标记,用作 Pigsty 的元节点。


infra-demo

infra-demo.yml 是用于演示环境的特殊剧本,通过交织元节点与普通节点初始化的方式,可以一次性完成4节点沙箱环境的初始化。 在四节点沙箱中,本剧本可等效为

./infra.yml              # 在元节点安装 Pigsty
./infra-pgweb.yml        # 在元节点加装 PgWeb
./nodes.yml -l pg-test   # 将 pg-test 所属三节点纳入管理
./pgsql.yml -l pg-test   # 在 pg-test 三节点上部署数据库集群

此外,当您尝试部署复数个元节点时,如果选择默认将DCS Server部署在所有元节点上时,也可以使用此剧本一次性拉起所有元节点以及其上的DCS与数据库集群。

请注意,配置不当的情况下,此剧本有一次性抹平整个环境的奇效,在生产环境可以移除以避免 “Fat Finger” 的风险。


infra-remove

infra-remove.yml 剧本是 infra 剧本的反向操作。

会将Pigsty从元节点卸载,剧本会依次卸载下列组件。

  • grafana-server
  • prometheus
  • alertmanager
  • node_exporter
  • consul
  • loki

infra-jupyter

infra-jupyter.yml 剧本用于在元节点上加装 Jupyter Lab服务

详细教程请参考 教程:启用Jupyter Lab服务

5.4 - INFRA监控

Pigsty中关于基础设施的Grafana监控面板

5.4.1 - Home

Home监控面板是整个Pigsty监控系统的默认主页与导航入口

Live Demo地址:http://demo.pigsty.cc

5.4.2 - INFRA Overview

INFRA Overview 展现Pigsty整体概览,并提供到具体基础设施监控的导航

INFRA Overview 展现Pigsty整体概览,并提供到具体基础设施监控的导航

Live Demo地址:http://demo.pigsty.cc/d/infra-overview

5.4.3 - Nginx Overview

Nginx Overview 展现Pigsty中Nginx访问端点的指标与日志

Nginx Overview 展现Pigsty中访问端点Web服务器Nginx的指标与日志。

Live Demo地址:http://demo.pigsty.cc/d/nginx-overview

5.4.4 - Grafana Overview

Grafana Overview 展现Pigsty中监控面板组件Grafana的监控指标。

Grafana Overview 展现Pigsty中监控面板组件Grafana的监控指标。

Live Demo地址:http://demo.pigsty.cc/d/grafana-overview

5.4.5 - Prometheus Overview

Prometheus Overview 展现Pigsty中时序数据库Prometheus的监控指标。

Prometheus Overview 展现Pigsty中时序数据库Prometheus的监控指标。

Live Demo地址:http://demo.pigsty.cc/d/prometheus-overview

5.4.6 - Loki Overview

Loki Overview 展现Pigsty中日志数据库Loki的监控指标。

Loki Overview 展现Pigsty中日志数据库Loki的监控指标。

Live Demo地址:http://demo.pigsty.cc/d/loki-overview

5.4.7 - DCS Overview

DCS Overview 展现Pigsty中Consul与ETCD的状态。

DCS Overview 展现Pigsty中时序数据库Consul与ETCD的监控指标

Live Demo地址:http://demo.pigsty.cc/d/dcs-overview

5.4.8 - CMDB Overview

CMDB Overview 展现Pigsty中Postgres CMDB的配置清单内容

CMDB Overview 展现Pigsty中Postgres CMDB的配置清单内容

Live Demo地址:http://demo.pigsty.cc/d/cmdb-overview

6 - 模块:NODES

将更多主机节点纳入Pigsty管理。

6.1 - NODES概览

Pigsty使用节点(Node)进行安装与部署,节点可以是物理机,虚拟机,甚至Pod。

在Pigsty中有两种节点:元节点 与(普通)节点

元节点用于发起管理,普通节点是纳入Pigsty管理的节点。

  • 元节点(Meta):执行 infra.yml 剧本安装Pigsty,安装 INFRANODESPGSQL 三个模块。
  • 节点(Node):通过 nodes.yml 剧本纳入管理的普通节点,默认安装 NODES 模块。

元节点也是一个普通的节点:节点是元节点的父类,元节点是节点的超集。

6.1.1 - 节点

Pigsty使用节点(Node)进行安装与部署,节点可以是物理机,虚拟机,甚至Pod。

您可以使用Pigsty管理更多的节点,并使用这些节点部署数据库。

纳入Pigsty管理的节点会被 nodes.yml 调整至 配置:NODES 所描述的状态,加装节点监控与日志收集组件,您可以从监控系统中查阅节点状态与日志。被Pigsty管理的节点可以进一步用于部署各种数据库,或您自己的应用。

节点身份

每个节点都有身份参数,通过在<cluster>.hosts<cluster>.vars中的相关参数进行配置。

在Pigsty中,节点有两个重要的身份参数: nodenamenode_cluster,这两者将在监控系统中用作节点的 实例标识ins) 与 集群标识cls)。nodenamenode_cluster 并不是必选参数,当留白或置空时,nodename 会使用节点当前的主机名,而 node_cluster 则会使用固定的默认值:nodes

此外,Pigsty还会使用IP地址作为数据库节点的唯一标识, IP地址即配置清单中主机的inventory_hostname ,体现为<cluster>.hosts对象中的key。尽管一个节点可能有多块网卡和多个IP地址,但您必须指定一个首要IP地址作为节点唯一标识。该地址应当为内网地址,即您访问该节点上的数据库时使用那个IP地址。

该IP地址并不一定是管理节点SSH访问使用的IP地址,您可以通过 Ansible Connect 相关参数,通过SSH隧道或跳板机中转的方式间接操作管理目标节点。

名称 类型 层级 必要性 说明
inventory_hostname ip - 必选 节点IP地址
nodename string I 可选 节点名称
node_cluster string C 可选 节点集群名称

以下集群配置声明了一个三节点集群:

node-test:
  hosts:
    10.10.10.11: { nodename: node-test-1 }
    10.10.10.12: { pg_hostname: true } # 从PG借用身份 pg-test-2
    10.10.10.13: {  } # 不显式指定nodename,则使用原有hostname: node-3
  vars:
    node_cluster: node-test
host node_cluster nodename instance
10.10.10.11 node-test node-test-1 pg-test-1
10.10.10.12 node-test pg-test-2 pg-test-2
10.10.10.13 node-test node-3 pg-test-3

在监控系统中,相关的时序监控数据标签为:

node_load1{cls="pg-meta", ins="pg-meta-1", ip="10.10.10.10", job="nodes"}
node_load1{cls="pg-test", ins="pg-test-1", ip="10.10.10.11", job="nodes"}
node_load1{cls="pg-test", ins="pg-test-2", ip="10.10.10.12", job="nodes"}
node_load1{cls="pg-test", ins="pg-test-3", ip="10.10.10.13", job="nodes"}

节点默认服务

组件 端口 说明
Consul Agent 8500 分布式配置管理,服务发现组件Consul的本地Agent
Node Exporter 9100 机器节点监控指标导出器
Promtail 9080 实时收集Postgres,Pgbouncer,Patroni日志 (选装)
Consul DNS 8600 Consul Agent提供的DNS服务

PGSQL节点服务

PGSQL节点是用于部署PostgreSQL集群的节点, 在标准节点上额外加装了 PGSQL 模块。

在执行默认的PostgreSQL部署时,因为Pigsty默认采用节点独占1:1部署,因此可以通过 pg_hostname 参数,将数据库实例的身份参数(pg_clusterpg_instance)借用至节点的 nodenamenode_cluster 身份参数上。

除了 节点默认服务 外,PGSQL节点上运行有下列服务:

组件 端口 说明
Postgres 5432 Postgres数据库服务
Pgbouncer 6432 Pgbouncer连接池服务
Patroni 8008 Patroni高可用组件
Consul 8500 分布式配置管理,服务发现组件Consul的本地Agent
Haproxy Primary 5433 集群读写服务(主库连接池)代理
Haproxy Replica 5434 集群只读服务(从库连接池)代理
Haproxy Default 5436 集群主库直连服务(用于管理,DDL/DML变更)
Haproxy Offline 5438 集群离线读取服务(直连离线实例,用于ETL,交互式查询)
Haproxy service 543x 集群提供的额外自定义服务将依次分配端口
Haproxy Admin 9101 Haproxy监控指标与流量管理页面
PG Exporter 9630 Postgres监控指标导出器
PGBouncer Exporter 9631 Pgbouncer监控指标导出器
Node Exporter 9100 机器节点监控指标导出器
Promtail 9080 实时收集Postgres,Pgbouncer,Patroni日志 (选装)
Consul DNS 8600 Consul提供的DNS服务
vip-manager - 将VIP绑定至集群主库上

节点交互

以单个 元节点 和 单个 节点 构成的环境为例,架构如下图所示:

元节点与数据库节点之间的交互主要包括:

  • 数据库集群/节点的域名依赖元节点的Nameserver进行解析 (可选)。

  • 数据库节点软件安装需要用到元节点上的Yum Repo。

  • 数据库集群/节点的监控指标会被元节点的Prometheus收集。

  • 数据库的日志会被Promtail收集并发往Loki。

  • Pigsty会从元节点上发起对数据库节点的管理:

    • 执行集群创建,扩缩容,实例/集群回收
    • 创建业务用户、业务数据库、修改服务、HBA修改;
    • 执行日志采集、垃圾清理,备份,巡检等
  • 数据库节点的Consul会向元节点的DCS同步本地注册的服务,并代理状态读写操作。

  • 数据库节点会从元节点(或其他NTP服务器)同步时间l

6.1.2 - 元节点

元节点即完整安装Pigsty,带有管理功能的节点,部署有完整的基础设施组件。

元节点即完整安装Pigsty,带有管理功能的节点,部署有完整的基础设施组件。

当您在某节点上执行 ./configure 命令时,当前节点会被默认作为元节点,填入配置文件 meta 分组中。

在每套环境中,Pigsty最少需要一个元节点,该节点将作为整个环境的控制中心。元节点负责各种管理工作:保存状态,管理配置,发起任务,收集指标,等等。整个环境的基础设施组件,Nginx,Grafana,Prometheus,Alertmanager,NTP,DNS Nameserver,DCS都将部署在元节点上。

复用元节点

元节点亦可复用为普通数据库节点,在元节点上默认运行有名为 pg-meta 的PostgreSQL数据库集群。提供额外的扩展功能:CMDB,巡检报告,扩展应用,日志分析,数据分析与处理等

以Pigsty附带的四节点沙箱环境为例,组件在节点上的分布如下图所示:

沙箱由一个元节点与四个普通节点组成,这里元节点也被复用为一个普通节点。沙箱内部署有一套基础设施与两套数据库集群meta 为元节点,部署有基础设施组件,同时被复用为普通数据库节点,部署有单主数据库集群pg-metanode-1node-2node-3 为普通数据库节点,部署有数据库集群pg-test

元节点上的服务

元节点上默认运行的服务如下所示:

组件 端口 说明 默认域名
Nginx 80 所有Web服务的入口,文件服务器 pigsty
Yum 80 本地YUM软件源 yum.pigsty
Grafana 3000 监控系统/可视化平台 g.pigsty
AlertManager 9093 报警聚合管理组件 a.pigsty
Prometheus 9090 监控时序数据库 p.pigsty
Loki 3100 实时日志收集基础设施 l.pigsty
Consul (Server) 8500 分布式配置管理与服务发现 c.pigsty
Docker 2375 运行无状态服务的容器平台 -
PostgreSQL 5432 Pigsty CMDB -
Ansible - 用于发起管理命令的组件 -
Consul DNS 8600 Consul提供的DNS服务(可选) -
Dnsmasq 53 DNS域名解析服务器(可选) -
NTP 123 NTP时间服务器(可选) -
Pgbouncer 6432 Pgbouncer连接池服务 -
Patroni 8008 Patroni高可用组件 -
Haproxy Primary 5433 集群读写服务(主库连接池)代理 -
Haproxy Replica 5434 集群只读服务(从库连接池)代理 -
Haproxy Default 5436 集群主库直连服务(用于管理,DDL/DML变更) -
Haproxy Offline 5438 集群离线读取服务(直连离线实例,用于ETL,交互式查询) -
Haproxy Admin 9101 Haproxy监控指标与流量管理页面 -
PG Exporter 9630 Postgres监控指标导出器 -
PGBouncer Exporter 9631 Pgbouncer监控指标导出器 -
Node Exporter 9100 机器节点监控指标导出器 -
Promtail 9080 实时收集节点与数据库日志 -
vip-manager - 将VIP绑定至集群主库上

元节点与DCS

默认情况下,元节点上将部署元数据库 (Consul 或 Etcd),用户也可以使用已有的外部DCS集群。如果将DCS部署至元节点上,建议在生产环境使用3个元节点,以充分保证DCS服务的可用性。DCS外的基础设施组件都将以对等副本的方式部署在所有元节点上。元节点的数量要求最少1个,推荐3个,建议不超过5个。

DCS用于支持数据库高可用的故障检测与选主,在默认模式停止DCS服务会导致所有数据库集群拒绝写入,因此请务必确保DCS服务的可靠性(增加元节点数量,或使用外部独立维护的高可用DCS集群)

多个元节点

复数个元节点是可能的,通常一个元节点足矣,两个元节点可以互为备份,三个元节点自身便足以部署生产级DCS Server集群。

本着开箱即用的原则,Pigsty默认在所有元节点上部署DCS Server。但如果单纯是为了追求DCS Server集群的高可用而使用超过3个管理节点并没有太大的意义。您可以使用一个外部维护管理的,3~5节点的DCS集群来保证DCS服务可用性。

元节点的特征是节点地址配置于配置文件的 all.children.meta.host 分组中,带有meta_node: true 标记。在 configure 过程中,执行安装的当前节点会被配置为元节点,复数个元节点则需要手工配置,可参考三管理节点样例配置文件: pigsty-dcs3.yml

如果您没有使用任何外部DCS集群服务作为仲裁者,那么有意义的高可用最少需要3个节点。如果您只有两个节点,建议主库故障时人工介入以避免脑裂出现。

6.1.3 - 节点交互

以单个 元节点 和 单个 节点 构成的环境为例介绍两者间的交互。

以单个 元节点 和 单个 节点 构成的环境为例,架构如下图所示:

元节点与数据库节点之间的交互主要包括:

  • 数据库集群/节点的域名依赖元节点的Nameserver进行解析 (可选)。

  • 数据库节点软件安装需要用到元节点上的Yum Repo。

  • 数据库集群/节点的监控指标会被元节点的Prometheus收集。

  • 数据库的日志会被Promtail收集并发往Loki。

  • Pigsty会从元节点上发起对数据库节点的管理:

    • 执行集群创建,扩缩容,实例/集群回收
    • 创建业务用户、业务数据库、修改服务、HBA修改;
    • 执行日志采集、垃圾清理,备份,巡检等
  • 数据库节点的Consul会向元节点的DCS同步本地注册的服务,并代理状态读写操作。

  • 数据库节点会从元节点(或其他NTP服务器)同步时间l

6.1.4 - 节点身份

节点的身份参数与标识符

每个节点都有身份参数,通过在<cluster>.hosts<cluster>.vars中的相关参数进行配置。

Pigsty使用IP地址作为数据库节点的唯一标识,该IP地址必须是数据库实例监听并对外提供服务的IP地址,但不宜使用公网IP地址。尽管如此,用户并不一定非要通过该IP地址连接至该数据库。例如,通过SSH隧道或跳板机中转的方式间接操作管理目标节点也是可行的。但在标识数据库节点时,首要IPv4地址依然是节点的核心标识符,这一点非常重要,用户应当在配置时保证这一点。 IP地址即配置清单中主机的inventory_hostname ,体现为<cluster>.hosts对象中的key

除此之外,在Pigsty监控系统中,节点还有两个重要的身份参数:nodenamenode_cluster,这两者将在监控系统中用作节点的 实例标识ins) 与 集群标识cls)。在执行默认的PostgreSQL部署时,因为Pigsty默认采用节点独占1:1部署,因此可以通过 pg_hostname 参数,将数据库实例的身份参数( pg_clusterpg_instance)借用至节点的inscls标签上。

nodenamenode_cluster并不是必选的,当留白或置空时,nodename 会使用节点当前的主机名,而 node_cluster 则会使用固定的默认值:nodes

名称 类型 层级 必要性 说明
inventory_hostname ip - 必选 节点IP地址
nodename string I 可选 节点名称
node_cluster string C 可选 节点集群名称

以下集群配置声明了一个三节点节点集群:

node-test:
  hosts:
    10.10.10.11: { nodename: node-test-1 }
    10.10.10.12: { nodename: node-test-2 }
    10.10.10.13: { nodename: node-test-3 }
  vars:
    node_cluster: node-test

6.2 - NODES配置

Pigsty提供了完整的主机置备与监控功能,执行 nodes.yml 剧本即可将对应节点配置为对应状态,并纳入Pigsty监控系统。
ID Name Section Type Level Comment
300 meta_node NODE_IDENTITY bool C 表示此节点为元节点
301 nodename NODE_IDENTITY string I 指定节点实例标识
302 node_cluster NODE_IDENTITY string C 节点集群名,默认名为nodes
303 nodename_overwrite NODE_IDENTITY bool C 用Nodename覆盖机器HOSTNAME
304 nodename_exchange NODE_IDENTITY bool C 是否在剧本节点间交换主机名
310 node_etc_hosts NODE_DNS string[] C/I 同上,用于集群实例层级
311 node_etc_hosts_default NODE_DNS string[] C 写入机器的静态DNS解析
312 node_dns_method NODE_DNS enum C 如何配置DNS服务器?
313 node_dns_servers NODE_DNS string[] C 配置动态DNS服务器列表
314 node_dns_options NODE_DNS string[] C 配置/etc/resolv.conf
320 node_repo_method NODE_PACKAGE enum C 节点使用Yum源的方式
321 node_repo_remove NODE_PACKAGE bool C 是否移除节点已有Yum源
322 node_repo_local_urls NODE_PACKAGE url[] C 本地源的URL地址
331 node_packages NODE_PACKAGE string[] C 节点额外安装的软件列表
330 node_packages_default NODE_PACKAGE string[] C 节点安装软件列表
332 node_packages_meta NODE_PACKAGE string[] G 元节点所需的软件列表
333 node_packages_meta_pip NODE_PACKAGE string G 元节点上通过pip3安装的软件包
340 node_disable_firewall NODE_TUNE bool C 关闭节点防火墙
341 node_disable_selinux NODE_TUNE bool C 关闭节点SELINUX
342 node_disable_numa NODE_TUNE bool C 关闭节点NUMA
343 node_disable_swap NODE_TUNE bool C 关闭节点SWAP
344 node_static_network NODE_TUNE bool C 是否使用静态DNS服务器
345 node_disk_prefetch NODE_TUNE bool C 是否启用磁盘预读
346 node_kernel_modules NODE_TUNE string[] C 启用的内核模块
347 node_tune NODE_TUNE enum C 节点调优模式
348 node_sysctl_params NODE_TUNE dict C 操作系统内核参数
350 node_data_dir NODE_ADMIN path G 节点的数据盘挂载路径
351 node_admin_enabled NODE_ADMIN bool G 是否创建管理员用户
352 node_admin_uid NODE_ADMIN int G 管理员用户UID
353 node_admin_username NODE_ADMIN string G 管理员用户名
354 node_admin_ssh_exchange NODE_ADMIN bool C 在实例间交换管理员SSH密钥
355 node_admin_pk_current NODE_ADMIN bool A 是否将当前用户的公钥加入管理员账户
356 node_admin_pk_list NODE_ADMIN key[] C 可登陆管理员的公钥列表
360 node_timezone NODE_TIME string C NTP时区设置
361 node_ntp_enabled NODE_TIME bool C 是否配置NTP服务?
362 node_ntp_service NODE_TIME enum C NTP服务类型:ntp或chrony
363 node_ntp_servers NODE_TIME string[] C NTP服务器列表
364 node_crontab_overwrite NODE_TIME bool C/I 是否覆盖/etc/crontab
365 node_crontab NODE_TIME string[] C/I 主机定时任务列表
370 docker_enabled DOCKER bool C dockerd是否启用?
371 docker_cgroups_driver DOCKER int C docker cgroup驱动
372 docker_registry_mirrors DOCKER string C docker镜像仓库地址
373 docker_image_cache DOCKER string C docker镜像缓存包地址
380 node_exporter_enabled NODE_EXPORTER bool C 启用节点指标收集器
381 node_exporter_port NODE_EXPORTER int C 节点指标暴露端口
382 node_exporter_options NODE_EXPORTER string C/I 节点指标采集选项
390 promtail_enabled PROMTAIL bool C 是否启用Promtail日志收集服务
391 promtail_clean PROMTAIL bool C/A 是否在安装promtail时移除已有状态信息
392 promtail_port PROMTAIL int G promtail使用的默认端口
393 promtail_options PROMTAIL string C/I promtail命令行参数
394 promtail_positions PROMTAIL string C promtail状态文件位置

NODE_IDENTITY

节点身份参数

meta_node

表示此节点为元节点, 类型:bool,层级:C,默认值为:false

在配置清单中,meta分组下的节点默认带有此标记。带有此标记的节点会在节点软件包安装时进行额外的配置: 安装node_packages_meta指定的RPM软件包,并安装node_packages_meta_pip指定的Python软件包。

nodename

指定节点名, 类型:string,层级:I,默认值为空。

该选项可为节点显式指定名称,只在节点实例层次定义才有意义。使用默认空值或空字符串意味着不为节点指定名称,直接使用现有的 Hostname 作为节点名。

节点名nodename将在Pigsty监控系统中,用作节点实例的名称(ins标签)。此外,如果 nodename_overwrite 为真,节点名还会用作HOSTNAME。

备注:若启用pg_hostname 选项,则Pigsty会在初始化节点时,借用当前节点上一一对应PG实例的身份参数,如pg-test-1,作为节点名。

node_cluster

节点集群名,类型:string,层级:C,默认值为:"nodes"

该选项可为节点显式指定一个集群名称,通常在节点集群层次定义才有意义。使用默认空值将直接使用固定值nodes作为节点集群标识。

节点集群名node_cluster将在Pigsty监控系统中,用作节点集群的标签(cls)。

备注:若启用pg_hostname 选项,则Pigsty会在初始化节点时,借用当前节点上一一对应PG集群的身份参数,如pg-test,作为节点集群名。

nodename_overwrite

是否用节点名覆盖机器HOSTNAME, 类型:bool,层级:C,默认值为:true

布尔类型,默认为真,为真时,非空的节点名 nodename 将覆盖节点的当前主机名称。

如果 nodename 参数未定义,为空或为空字符串,则不会对主机名进行修改。

nodename_exchange

是否在剧本节点间交换主机名, 类型:bool,层级:C,默认值为:false

启用此参数时,同一组执行 nodes.yml 剧本的节点之间,会相互交换节点名称,写入/etc/hosts中。


NODE_DNS

Pigsty会为节点配置静态DNS解析记录与动态DNS服务器。

如果您的节点供应商已经为您配置了DNS服务器,您可以将 node_dns_method 设置为 none 跳过DNS设置。

node_etc_hosts

写入节点的静态DNS解析, 类型:string[],层级:C/I,默认值为空数组 []

node_etc_hosts 是一个数组,每一个元素都是形如ip domain_name的字符串,代表一条DNS解析记录,每一条记录都会在机器节点初始化时写入/etc/hosts中。

如果用户希望在全局配置基础设施地址,则可以使用 node_etc_hosts_default 参数,使用本参数添加集群/实例特定的静态DNS记录。

node_etc_hosts_default

默认写入所有节点的静态DNS记录, 类型:string[],层级:G,,默认值为Pigsty管理节点的域名解析记录:

node_etc_hosts_default:                 # static dns records in /etc/hosts
  - 10.10.10.10 meta pigsty c.pigsty g.pigsty l.pigsty p.pigsty a.pigsty cli.pigsty lab.pigsty api.pigsty

您应当确保向/etc/hosts中写入10.10.10.10 pigsty yum.pigsty这样的DNS记录,确保在DNS Nameserver启动之前便可以采用域名的方式访问本地yum源。

如果用户希望为单个集群与实例配置特定的静态DNS解析,则可以使用 node_etc_hosts 参数。

node_dns_method

如何配置DNS服务器?, 类型:enum,层级:C,默认值为:"add"

机器节点默认的动态DNS服务器的配置方式,有三种模式:

  • add:将 node_dns_servers 中的记录追加至/etc/resolv.conf,并保留已有DNS服务器。(默认)
  • overwrite:使用将 node_dns_servers 中的记录覆盖/etc/resolv.conf
  • none:跳过DNS服务器配置,如果您的环境中已经配置有DNS服务器,则可以跳过。

node_dns_servers

配置动态DNS服务器列表, 类型:string[],层级:C,默认值为 10.10.10.10

Pigsty默认会添加元节点作为DNS Server,元节点上的DNSMASQ会响应环境中的DNS请求。

node_dns_servers: # dynamic nameserver in /etc/resolv.conf
  - 10.10.10.10

node_dns_options

如果 node_dns_method 配置为addoverwrite,则本配置项中的记录会被追加或覆盖至/etc/resolv.conf中。具体格式请参考Linux文档关于/etc/resolv.conf的说明

Pigsty默认添加的解析选项为:

- options single-request-reopen timeout:1 rotate
- domain service.consul

NODE_PACKAGE

Pigsty会为纳入管理的节点配置Yum源,并安装软件包。

node_repo_method

节点使用Yum源的方式, 类型:enum,层级:C,默认值为:"local"

机器节点Yum软件源的配置方式,有三种模式:

  • local:使用元节点上的本地Yum源,默认行为,推荐使用此方式。
  • public:直接使用互联网源安装,将repo_upstream中的公共repo写入/etc/yum.repos.d/
  • none:不对本地源进行配置与修改。

node_repo_remove

是否移除节点已有Yum源, 类型:bool,层级:C,默认值为:true

如何处理节点上原有YUM源?如果启用,则Pigsty会移除 节点上/etc/yum.repos.d中原有的配置文件,并备份至/etc/yum.repos.d/backup

node_repo_local_urls

本地源的URL地址, 类型:url[],层级:C,默认值为:

如果 node_repo_method 配置为local,则这里列出的Repo文件URL会被下载至/etc/yum.repos.d

这里是一个Repo File URL 构成的数组,Pigsty默认会将元节点上的本地Yum源加入机器的源配置中。

node_repo_local_urls:
  - http://yum.pigsty/pigsty.repo

node_packages

节点安装的软件列表, 类型:string[],层级:C,默认值为空列表:[]

通过yum安装的额外软件包列表,每个数组元素为软件包名称,您可以在每一个元素中都指定一个逗号分隔的软件列表,软件包会依次安装。

默认在全局所有节点上安装的软件包通过参数 node_packages_default 进行配置,本参数可用于配置集群/节点特定的软件包。

node_packages_defaultnode_packages 类似,前者通常是全局统一配置,而 node_packages 则是针对具体节点进行例外处理。 例如,您可以为运行PG的节点安装额外的工具包。该变量通常在集群级别进行覆盖定义。

node_packages_default

节点安装软件列表, 类型:string[],层级:C,默认值为:

node_packages_meta:                           # packages for meta nodes only
  - grafana,prometheus2,alertmanager,loki,nginx_exporter,blackbox_exporter,pushgateway,redis,postgresql14
  - nginx,ansible,pgbadger,python-psycopg2,dnsmasq,polysh,coreutils,diffutils

软件包列表为数组,但每个元素可以包含由逗号分隔的多个软件包,Pigsty默认安装的软件包列表如下:

node_packages_meta

元节点所需的软件列表, 类型:string[],层级:G,默认值为:

node_packages_meta:                           # packages for meta nodes only
  - grafana,prometheus2,alertmanager,loki,nginx_exporter,blackbox_exporter,pushgateway,redis,postgresql14
  - nginx,ansible,pgbadger,python-psycopg2,dnsmasq,polysh,coreutils,diffutils

node_packages_default类似,但node_packages_meta中列出的软件包只会在元节点上安装,通常在元节点上使用的基础设施软件需要在此指定

node_packages_meta_pip

元节点上通过pip3安装的软件包, 类型:string,层级:G,默认值为:"jupyterlab"

软件包会下载至{{ nginx_home }}/{{ repo_name }}/python目录后统一安装。

目前默认会安装jupyterlab,提供完整的Python运行时环境。


NODE_TUNE

主机节点特性、内核模块与调优模板

node_disable_firewall

关闭节点防火墙, 类型:bool,层级:C,默认值为:true,请保持关闭。

node_disable_selinux

关闭节点SELINUX, 类型:bool,层级:C,默认值为:true,请保持关闭。

node_disable_numa

关闭节点NUMA, 类型:bool,层级:C,默认值为:false

布尔标记,是否关闭NUMA,默认不关闭。注意,关闭NUMA需要重启机器后方可生效!

如果您不清楚如何绑核,在生产环境使用数据库时建议关闭NUMA。

node_disable_swap

关闭节点SWAP, 类型:bool,层级:C,默认值为:false

通常情况下不建议关闭SWAP,如果您有足够的内存,且数据库采用独占式部署,则可以关闭SWAP提高性能。

当您的节点用于部署Kubernetes时,应当禁用SWAP。

node_static_network

是否使用静态DNS服务器, 类型:bool,层级:C,默认值为:true,默认启用。

启用静态网络,意味着您的DNS Resolv配置不会因为机器重启与网卡变动被覆盖。建议启用。

node_disk_prefetch

是否启用磁盘预读, 类型:bool,层级:C,默认值为:false,默认不启用。

针对HDD部署的实例可以优化吞吐量,使用HDD时建议启用。

node_kernel_modules

启用的内核模块, 类型:string[],层级:C,默认值为:

由内核模块名称组成的数组,声明了需要在节点上安装的内核模块,Pigsty默认会启用以下内核模块:

node_kernel_modules: [ softdog, ip_vs, ip_vs_rr, ip_vs_rr, ip_vs_wrr, ip_vs_sh ]

node_tune

节点调优模式, 类型:enum,层级:C,默认值为:"tiny"

针对机器进行调优的预制方案,基于tuned服务。有四种预制模式:

  • tiny:微型虚拟机
  • oltp:常规OLTP模板,优化延迟
  • olap:常规OLAP模板,优化吞吐量
  • crit:核心金融业务模板,优化脏页数量

通常,数据库的调优模板 pg_conf应当与机器调优模板配套,详情请参考定制PGSQL模版

node_sysctl_params

操作系统内核参数, 类型:dict,层级:C,默认值为空字典。字典KV结构,Key为内核sysctl参数名,Value为参数值。


NODE_ADMIN

主机节点管理用户

node_data_dir

节点的数据盘挂载路径, 类型:path,层级:C,默认值为:/data

如果指定,则该路径将作为节点的主数据库盘,如果该目录不存在,则该目录会被创建并抛出提示信息。

默认情况下,该目录属主为root,模式为0777

node_admin_enabled

是否创建管理员用户, 类型:bool,层级:G,默认值为:true

是否在每个节点上创建管理员用户(免密sudo与ssh),默认会创建名为dba (uid=88)的管理用户,可以从元节点上通过SSH免密访问环境中的其他节点并执行免密sudo。

node_admin_uid

管理员用户UID, 类型:int,层级:G,默认值为:88,手工分配时请注意UID命名空间冲突。

node_admin_username

管理员用户名, 类型:string,层级:G,默认值为:"dba"

node_admin_ssh_exchange

在实例间交换节点管理员SSH密钥, 类型:bool,层级:C,默认值为:true

启用时,Pigsty会在执行剧本时,在成员间交换SSH公钥,允许管理员 node_admin_username 从不同节点上相互访问。

node_admin_pk_current

是否将当前节点&用户的公钥加入管理员账户, 类型:bool,层级:A,默认值为:true

启用时,将当前节点上,当前用户的SSH公钥(~/.ssh/id_rsa.pub)会被拷贝至目标节点管理员用户的authorized_keys中。

生产环境部署时,请务必注意此参数,此参数会将当前执行命令用户的默认公钥安装至所有机器的管理用户上。

node_admin_pk_list

可登陆管理员的公钥列表, 类型:key[],层级:C,默认值为空数组,Demo中有vagrant用户默认的公钥。

数组,每一个元素为字符串,内容为写入到管理员用户~/.ssh/authorized_keys中的密钥,持有对应私钥的用户可以以管理员身份登录。

生产环境部署时,请务必注意此参数,仅将信任的密钥加入此列表中。


NODE_TIME

节点时区与时间同步。

如果您的节点已经配置有NTP服务器,则可以配置 node_ntp_enabledfalse,跳过NTP服务的设置。

node_timezone

NTP时区设置, 类型:string,层级:C,默认值为空。

在Demo中,默认使用的时区为"Asia/Hong_Kong",请根据您的实际情况调整。(请不要使用Asia/Shanghai时区,该时区缩写 CST 会导致一系列日志时区解析问题)

如果选择 false,或者留空,则Pigsty不会修改该节点的时区配置。

node_ntp_enabled

是否配置NTP服务?, 类型:bool,层级:C,默认值为:true

为真时,Pigsty会覆盖节点的/etc/ntp.conf/etc/chrony.conf,填入 node_ntp_servers 指定的NTP服务器。

如果您的服务器节点已经配置好有NTP服务器,则建议关闭,使用原有NTP服务器。

node_ntp_service

NTP服务类型:ntpchrony, 类型:enum,层级:C,默认值为:"ntp"

指明系统使用的NTP服务类型,默认使用 ntp 作为时间服务:

  • ntp:传统NTP服务
  • chrony:CentOS 7/8默认使用的时间服务

只有当 node_ntp_enabled 为真时生效。

node_ntp_servers

NTP服务器列表, 类型:string[],层级:C,默认值为:

- pool cn.pool.ntp.org iburst
- pool pool.ntp.org iburst
- pool time.pool.aliyun.com iburst
- server 10.10.10.10 iburst

只有当 node_ntp_enabled 为真时生效。

node_crontab_overwrite

是否覆盖节点的Crontab, 类型:bool,层级:C/I,默认值为true

如果启用,node_crontab 中的记录会整体覆盖 /etc/crontab 而不是追加写入。

node_crontab

节点定时任务列表, 类型:string[],层级:C/I,默认值为空数组[]

在此列表的每的一个元素都是一条记录,写入 /etc/crontab中,例如:

00 01 * * * postgres /pg/bin/pg-backup 2>>/pg/log/backup.log

DOCKER

Pigsty默认在所有元节点上启用Docker,而普通节点不启用。

docker_enabled

是否在当前节点启用Docker?类型:bool,层级:C,默认值为false,但元节点默认为true

docker_cgroups_driver

Docker使用的CGroup驱动,类型:string,层级:C,默认为systemd

docker_registry_mirrors

Docker使用的镜像仓库地址,类型:string[],层级:C,默认为空,即直接使用 DockerHub。

docker_image_cache

本地的Docker镜像离线缓存包,类型:path,层级:C,默认为:/www/pigsty/docker.tar.lz4

如果存在时,配置Docker时会自动加载至本地Docker中。


NODE_EXPORTER

NodeExporter用于从主机上收集监控指标数据。

node_exporter_enabled

启用节点指标收集器, 类型:bool,层级:C,默认值为:true

node_exporter_port

节点指标暴露端口, 类型:int,层级:C,默认值为:9100

node_exporter_options

节点指标采集选项, 类型:string,层级:C/I,默认值为:"--no-collector.softnet --no-collector.nvme --collector.ntp --collector.tcpstat --collector.processes"

Pigsty默认会启用ntp, tcpstat, processes 三个额外的指标收集器,禁用 softnet, nvme 两个默认的指标收集器。


PROMTAIL

主机日志收集组件,与Loki基础设施配置配套使用。

promtail_enabled

是否启用Promtail日志收集服务, 类型:bool,层级:C,默认值为:true

布尔类型,是否在当前节点启用Promtail日志收集服务?默认启用。

启用 promtail 后,Pigsty会根据配置清单中的定义,生成Promtail的配置文件,抓取下列日志并发送至由loki_endpoint指定的Loki实例。

  • INFRA:基础设施日志,只在元节点上收集

    • nginx-access: /var/log/nginx/access.log
    • nginx-error: /var/log/nginx/error.log
    • grafana: /var/log/grafana/grafana.log
  • NODES: 主机节点日志,在所有节点上收集。

    • syslog: /var/log/messages
    • dmesg: /var/log/dmesg
    • cron: /var/log/cron
  • PGSQL: PostgreSQL日志,当节点定义有pg_cluster时收集。

    • postgres: /pg/data/log/*.csv
    • patroni: /pg/log/patroni.log
    • pgbouncer: /var/log/pgbouncer/pgbouncer.log
  • REDIS: Redis日志,当节点定义有redis_cluster时收集。

    • redis: /var/log/redis/*.log

promtail_clean

是否在安装promtail时移除已有状态信息, 类型:bool,层级:C/A,默认值为:false

默认不会清理,当您选择清理时,Pigsty会在部署Promtail时移除现有状态文件 promtail_positions,这意味着Promtail会重新收集当前节点上的所有日志并发送至Loki。

promtail_port

promtail使用的默认端口, 类型:int,层级:G,默认值为:9080

promtail_options

promtail命令行参数, 类型:string,层级:C/I,默认值为:"-config.file=/etc/promtail.yml -config.expand-env=true"

运行promtail二进制程序时传入的额外命令行参数,默认值为'-config.file=/etc/promtail.yml -config.expand-env=true'

已有参数用于指定配置文件路径,并在配置文件中展开环境变量,不建议修改。

promtail_positions

promtail状态文件路径, 类型:string,层级:C,默认值为:"/var/log/positions.yaml"

Promtail记录了所有日志的消费偏移量,定期写入promtail_positions 指定的文件中。

6.3 - NODES剧本

使用 NODES 系列剧本将更多节点纳入Pigsty管理,将节点调整至配置描述的状态。

当您使用 infra.yml 在元节点上完成Pigsty的完整安装后,您可以进一步使用 nodes.yml 将更多节点添加至Pigsty中,或者使用 nodes-remove.yml 将节点从环境中移除。

剧本 功能 链接
nodes 节点置备,将节点纳入Pigsty管理,可用于后续数据库部署 src
nodes-remove 节点移除,卸载节点DCS与监控,不再纳入Pigsty管理 src

nodes

nodes.yml 剧本将更多节点添加至Pigsty中。该剧本需要在 元节点 上发起,针对目标节点执行。

此剧本可以将目标机器节点调整至配置清单所描述的状态,安装Consul服务,并将其纳入Pigsty监控系统,并允许您在这些置备好的节点上进一步部署不同类型的数据库集群。

nodes.yml 剧本的行为由 节点配置 决定。在使用本地源的情况下,完整执行此剧本可能耗时1~3分钟,视机器配置而异。

./nodes.yml                      # 初始化所有清单中的节点(危险!)
./nodes.yml -l pg-test           # 初始化在 pg-test 分组下的机器(推荐!)
./nodes.yml -l pg-meta,pg-test   # 同时初始化pg-meta与pg-test两个集群中的节点
./nodes.yml -l 10.10.10.11       # 初始化10.10.10.11这台机器节点

此剧本包含的功能与任务如下:

  • 生成节点身份参数
  • 初始化节点
    • 配置节点名称
    • 配置节点静态DNS解析
    • 配置节点动态DNS解析服务器
    • 配置节点的Yum源
    • 安装指定的RPM软件包
    • 配置 numa/swap/firewall等特性
    • 配置节点tuned调优模板
    • 配置节点的快捷命令与环境变量
    • 创建节点管理员并配置SSH
    • 配置节点时区
    • 配置节点NTP服务
  • 在节点上初始化DCS服务:Consul 与 ETCD
    • 抹除现有Consul
    • 初始化当前节点的 Consul Agent或Server 服务
  • 初始化节点监控组件并纳入Pigsty
    • 在节点上安装 Node Exporter
    • 将 Node Exporter 注册至元节点上的 Prometheus 中。

对于已有数据库运行的节点执行该剧本需要谨慎,使用不当存在误触发短暂数据库不可用的风险,因为初始化节点会抹除DCS Agent

节点置备会配置节点的DCS服务(Consul Agent),因此在对运行有PostgreSQL数据库的节点运行此剧本时,请小心! dcs_clean 参数提供了避免误删的选项作为保险,允许以在初始化过程中,当检测到已有运行中DCS时自动中止或跳过高危操作,避免最坏情况发生。

尽管如此,在使用完整的nodes.yml剧本或其中关于dcs|consul的部分时,请再三检查--tags|-t--limit|-l 参数是否正确。确保自己在正确的目标上执行正确的任务。

保护机制

Pigsty提供保护机制,避免误删运行中的Consul实例,包括了两个相关参数:

  • dcs_safeguard:默认关闭,只要打开,在任意情况下该数据库实例不会被清理。
  • dcs_clean:默认关闭,当打开时,初始化节点/nodes.yml 会抹除掉现有Consul实例(有可能影响PG主库写入)

当遇到现存实例时,nodes.yml 剧本会有以下行为表现:

dcs_safeguard / pg_clean dcs_clean=true dcs_clean=false
dcs_safeguard=true 中止执行 中止执行
dcs_safeguard=false 抹除实例 中止执行

当遇到现存实例时, nodes-remove.yml剧本会有以下行为表现:

dcs_safeguard / pg_clean dcs_clean=true dcs_clean=false
dcs_safeguard=true 中止执行 中止执行
dcs_safeguard=false 抹除实例 抹除实例

选择性执行

用户可以通过ansible的标签机制,选择性执行本剧本的一个子集。例如,如果只想执行节点监控部署的任务,则可以通过以下命令:

./nodes.yml --tags=node-monitor

一些常用的任务子集包括:

# play
./nodes.yml --tags=node-id         # 打印节点身份参数:名称与集群
./nodes.yml --tags=node-init       # 初始化节点,完成配置
./nodes.yml --tags=dcs-init        # 在节点上初始化DCS服务:Consul
./nodes.yml --tags=node-monitor    # 初始化节点监控组件并纳入Pigsty

# tasks
./nodes.yml --tags=node_name       # 配置节点名称
./nodes.yml --tags=node_dns        # 配置节点静态DNS解析
./nodes.yml --tags=node_resolv     # 配置节点动态DNS解析服务器
./nodes.yml --tags=node_repo       # 配置节点的Yum源
./nodes.yml --tags=node_pkgs       # 安装指定的RPM软件包
./nodes.yml --tags=node_feature    # 配置 numa/swap/firewall等特性
./nodes.yml --tags=node_tuned      # 配置节点tuned调优模板
./nodes.yml --tags=node_profile    # 配置节点的快捷命令与环境变量
./nodes.yml --tags=node_admin      # 创建节点管理员并配置SSH
./nodes.yml --tags=node_timezone   # 配置节点时区
./nodes.yml --tags=node_ntp        # 配置节点NTP服务

./nodes.yml --tags=consul          # 在节点上配置consul agent/server
./nodes.yml --tags=consul -e dcs_clean=clean   # 在节点上强制抹除重新配置consul

./nodes.yml --tags=node_exporter   # 在节点上配置 node_exporter 并注册
./nodes.yml --tags=node_deregister # 将节点监控从元节点上取消注册
./nodes.yml --tags=node_register   # 将节点监控注册到元节点上

创建管理用户

管理用户是一个先有鸡还是先有蛋的问题。为了执行Ansible剧本,需要有一个管理用户。为了创建一个专用的管理用户,需要执行此Ansible剧本。

Pigsty推荐将管理用户的创建,权限配置与密钥分发放在虚拟机的Provisioning阶段完成,作为机器资源交付内容的一部分。对于生产环境来说,机器交付时应当已经配置有这样一个具有免密远程SSH登陆并执行免密sudo的用户。通常绝大多数云平台和运维体系都可以做到这一点。

如果您只能使用ssh密码和sudo密码,那么必须在所有剧本执行时添加额外的参数 --ask-pass|-k--ask-become-pass|-K,并在提示出现时输入ssh密码与sudo密码。您可以使用 nodes.yml 中创建管理员用户的功能,使用当前用户创建一个专用管理员用户,以下参数用于创建默认的管理员用户:

./nodes.yml -t node_admin -l <目标机器> --ask-pass --ask-become-pass

默认创建的管理员用户为 dba(uid=88),请不要使用 postgres{{ dbsu }} 作为管理用户,请尽量避免直接使用 root 作为管理用户。

在沙箱环境中的默认用户 vagrant 默认已经配置有免密登陆和免密sudo,您可以从宿主机或沙箱元节点使用vagrant登陆所有的数据库节点。

例如:

./nodes.yml --limit <target_hosts>  --tags node_admin  -e ansible_user=<another_admin> --ask-pass --ask-become-pass 

详情请参考:准备:管理用户置备


nodes-remove

nodes-remove.yml 剧本是 nodes剧本的反向操作,用于将节点从Pigsty中移除。

该剧本需要在 元节点 上发起,针对目标节点执行。

./nodes.yml                      # 移除所有节点(危险!)
./nodes.yml -l nodes-test        # 移除 nodes-test 分组下的机器
./nodes.yml -l 10.10.10.11       # 移除 10.10.10.11这台机器节点
./nodes.yml -l 10.10.10.10 -e rm_dcs_servers=true # 如果节点为DCS Server,需要额外参数移除。

任务子集

# play
./nodes-remove.yml --tags=register      # 移除节点注册信息
./nodes-remove.yml --tags=node-exporter # 移除节点指标收集器
./nodes-remove.yml --tags=promtail      # 移除Promtail日志收集组件
./nodes-remove.yml --tags=consul        # 移除Consul Agent服务
./nodes-remove.yml --tags=consul -e rm_dcs_servers=true # 移除Consul服务(包括Server!)

6.4 - NODES监控

Pigsty中关于主机节点的Grafana监控面板

6.4.1 - NODES Overview

提供主机节点全局监控指标概览

NODES Overview 展现所有环境中主机节点的汇总指标,集群之间的核心指标水平对比,并提供到实例与集群的快速导航

Live Demo地址:http://demo.pigsty.cc/d/nodes-overview

6.4.2 - NODES Alert

提供主机节点全局监控告警指标总览

NODES Alerts 展现所有与主机节点 NODES 模块有关的告警信息:活跃的告警,告警时间线,以及相关指标数据

Live Demo地址:http://demo.pigsty.cc/d/nodes-alert

6.4.3 - NODES Cluster

提供针对单个节点集群的指标洞察

NODES Cluster关注单个主机集群,提供集群级别的汇总指标展示,节点级别的指标水平对比,以及到所有集群成员的快速导航。

Live Demo地址:http://demo.pigsty.cc/d/nodes-cluster

6.4.4 - NODES Instance

提供针对单个节点的指标洞察

Nodes Instance关注单个主机节点的监控指标,使用频率非常高。

Live Demo地址:http://demo.pigsty.cc/d/nodes-instance

7 - 模块:PGSQL

置备高可用PostgreSQL数据库集群!

7.1 - 概念

关于Pigsty创建的PostgreSQL数据库,用户需要了解的概念。

7.1.1 - PostgreSQL 实体模型

Pigsty中关于PostgreSQL数据库的逻辑概念模型:ER实体关系模型。

在Pigsty中,PostgreSQL有四类核心实体:

实体模型

  • 集群(Cluster) 是基本自治单元,由用户指定唯一标识,表达业务含义,作为顶层命名空间。
  • 集群在硬件层面上包含一系列的节点(Node),即物理机,虚机(或Pod),可以通过IP唯一标识。
  • 集群在软件层面上包含一系列的实例(Instance),即软件服务器,可以通过IP:Port唯一标识。
  • 集群在服务层面上包含一系列的服务(Service),即可访问的域名与端点,可以通过域名唯一标识。

实体命名规则

  • 集群的命名可以使用任意满足DNS域名规范的名称,不能带点([a-zA-Z0-9-]+)。
  • 节点命名采用集群名称作为前缀,后接-,再接一个整数序号(建议从0开始分配,与k8s保持一致)
  • PGSQL采用独占式部署,节点与实例一一对应,因此实例命名可与节点命名一致,即${cluster}-${seq}的方式。
  • 服务命名亦采用集群名称作为前缀,后接-连接服务具体内容,如primary, replica,offline,standby等。

以沙箱环境的测试数据库集群 pg-test 为例:

  • 一个集群:用于测试的数据库集群名为“pg-test
  • 两种角色:primaryreplica,分别是集群主库与从库。
  • 三个实例:集群由三个数据库实例:pg-test-1, pg-test-2, pg-test-3组成
  • 三个节点:集群部署在三个节点上:10.10.10.11, 10.10.10.12, 10.10.10.13上。
  • 四个服务:

集群

**集群(Cluster)**是基本的自治业务单元,这意味着集群能够作为一个整体组织对外提供服务。类似于k8s中Deployment的概念。注意这里的集群是软件层面的概念,不要与PG Cluster(数据库集簇,即包含多个PG Database的单个PG实例的数据目录)或Node Cluster(机器集群)混淆。

集群是管理的基本单位之一,是用于统合各类资源的组织单位。例如一个PG集群可能包括:

  • 三个物理机器节点
  • 一个主库实例,对外提供数据库读写服务。
  • 两个从库实例,对外提供数据库只读副本服务。
  • 两个对外暴露的服务:读写服务,只读副本服务。