Anolis SkillHub Picks: Deploy and Manage a PG Cluster in One Sentence

This article introduces the pg-create-cluster AI Skill, which simplifies deploying PostgreSQL streaming replication clusters through conversational prompts.

By digoal

On June 25, OpenAnolis community has officially launched SkillHub — an AI Agent Skill platform built for the Infra layer, where low-level know-how in system operations, security hardening, and performance tuning gets captured as reusable, shareable AI Skills. That same month, the community teamed up with AMD to launch "Skill Creation Camp" — Open Call for Longene SkillHub Skills and Best Practices, a call for outstanding Skills and hands-on experience drawn from real-world scenarios, open to developers and frontline engineers alike.

The response has been strong. Anolis SkillHub now hosts more than 100 Skills spanning security, system operations, AI inference, databases, and more — an Infra-focused AI Skill ecosystem taking shape fast. The Skill Creator Camp call for submissions is still open, and we warmly invite every developer to submit a Skill along with the Best Practices behind it.

To help more good Skills get seen and reused, the OpenAnolis community is launching the Anolis Skill Picks series: we highlight standout Skills and walk through them in concrete scenarios, so you can take "one Skill" and apply it to "a whole class of problems."

This pick: build a PG streaming replication cluster (1 primary + N standbys) on hosts you already have online. The goal of the pg-create-cluster skill fits in one sentence: let Claude Code stand up a PostgreSQL streaming replication cluster for you, conversationally. The following is republished from the digoal WeChat account:

The old way: to build a PG cluster with 1 primary and 2 standbys, you page through 30 pages of documentation, memorize a pile of parameters, run hosts to probe machines, run vips to pick an available VIP, run binpaths to see which version is actually installed — and then carefully hand-assemble a create command. Get any one detail wrong and initdb throws an error, the port collides, or the VIP is already taken, and you start over.

The core idea behind the pg-create-cluster skill isn't to bundle those commands into a script. It's to put Claude Code beside you and have it ask you one thing at a time, like a conversation. You answer, it generates the next command; you hesitate, it asks again.

Let's take this apart.

What's really going on: the tool grows a voice

For the past decade, DBA tooling has been subtracting — squeezing 30 pages of documentation into 5 parameters, then 5 parameters into 1 command.

pg-create-cluster takes a different route: instead of only emitting commands, the tool starts asking you questions. It does three things:

First, it's conversational — one question per turn, and it never re-asks what you've already settled.

Second, it's pick-from-a-list — it runs hosts / vips / binpaths, puts the real machines, VIPs, and versions in front of you, and lets you choose, instead of handing you a blank field.

Third, it lands in the shell — at the end it generates the actual script command and runs it.

Put together, this skill solves a classic problem: it takes DBA cluster provisioning from "page through the documentation and hand-assemble commands" down to "chat with an AI assistant."

Three things you must confirm first

Three things have to be settled before you use this skill. Miss one and nothing works.

First: CLup has to be up. Local CLup defaults to port 8090 on 127.0.0.1; a remote CLup needs --url, and don't append /api after the port. There's an important engineering principle here: step one of cluster provisioning is always to ask whether the user means local or remote — connection settings come before credentials. Which machine you connect to decides whether every later command carries --url.

Second: the Python interpreter is fixed. You must use /opt/csu_pyenv/bin/python. That interpreter ships with the pycryptodome library, which the script needs for password AES encryption. Any other Python interpreter and the run errors out immediately.

Third: the PG binaries must match the OS. This one is easy to miss — if the PG on the machine was built for EL8 but you're running Rocky9, initdb will be missing .so files such as libicui18n.so.60 and libssl.so.1.1, and it dies on the spot. The fix: either install a PG built for your OS, or move to a host where PG was compiled correctly.

"Feels like a chat, not a form" is the soul of this skill

The three principles look simple, but fewer than 10% of skills actually get them right.

First: one question at a time. Never write it as a checklist — "please provide: cluster name, primary IP, standby IP, PG version…" Each turn, scan the conversation history first and never re-ask what's already settled. Sounds trivial, but this is exactly where 90% of AI tools fall down: they throw a form at the user up front, and the user has no idea which blank to fill first.

Second: choose from real data. Run hosts / vips/ binpaths –host first, put the real machines, VIPs, and versions in front of the user to pick from, instead of handing over a blank field.

The reason is blunt: when users fill in blanks, they get it wrong 90% of the time (typo'd IPs, wrong version); when they pick from a list, they get it wrong less than 5% of the time. That's skill design respecting how human cognition actually works.

Third: connection before credentials. The first question has to be "local CLup or remote this time?" — don't open by asking for a password. Why:

• The connection URL decides whether every later command needs --url, so the order can't be shuffled.

• Ask for a password up front and the user's instincts kick in — you haven't even said what you're doing, so why hand over a password?

The user only decides 6 things

The parameter philosophy of pg-create-cluster: the user decides 6 things, and everything else takes the default.

#	Parameter	Source
1	Cluster name	From the user
2	Primary IP	Pick an agent-reachable one from `hosts`
3	Standby IP	The remaining online hosts; multiple allowed, but no host can be both primary and standby
4	Full PG version	`binpaths --host <primary_ip>` shows what's actually installed (e.g. 16.10)
5	VIP + pool ID	`vips`already excludes taken VIPs and host IPs
6	repl (streaming replication) password	Default `repl_user=db_user` / `repl_pass=db_pass`

The admin account, port, os_user, os_uid, and probe settings default to the template (template). The system automatically fetches setting_list from get_init_db_conf based on the PG version, including key settings such as listen_addresses='*' — don't ask the user. At least 2 machines (1 primary + 1 standby), 3 recommended (1 primary + 2 standbys).

The main path is just these 4 commands

3 to probe, 1 to create. Done.

# 1. Probe online hosts
/opt/csu_pyenv/bin/python create_pg_sr_cluster.py \
--user <u> --pass <p> hosts

# 2. Probe available VIPs (recommended VIPs are printed at the end)
/opt/csu_pyenv/bin/python create_pg_sr_cluster.py \
--user <u> --pass <p> vips

# 3. Probe the actual PG version
/opt/csu_pyenv/bin/python create_pg_sr_cluster.py \
--user <u> --pass <p> binpaths --host <primary_ip>

# 4. Create + poll the task
/opt/csu_pyenv/bin/python create_pg_sr_cluster.py \
--user <u> --pass <p> create \
--cluster-name <name> --primary <primary_ip> --standby <standby_ip1,standby_ip2> \
--version <full_version> --vip <VIP> --pool-id <pool_id> \
--repl-pass <password> --wait

On success it prints SUCCESS: cluster created (task N).

Under the hood, the script logs in → matches pg_bin_path node by node → fetches setting_list (including listen_addresses='*') → runs preflight checks (empty directory / port / VIP) → assembles the body (encrypting the password) → submits → polls the task (state=1 success, -1 failure).

Potholes the author already hit for you

Skip this section and you'll be looking up the documentation after you've already fallen in.

Pitfall 1 · Password mix-up

When authenticating the connection you get password authentication failed for user "postgres". Many DBAs first reach for the CREATE BODY, find the db_pass field printed at the top level, and log in with that value — instant error.

The reason: that db_pass is the to_db_text AES-encrypted string, not plaintext. The instance's real password is the template default plaintext postgres.

The right way:

PGPASSWORD=postgres /usr/pgsql-14/bin/psql -h <VIP or primary_ip> -U postgres

Pitfall 2 · database not connected

If cluster creation reports create_replication_user ... database not connected!, 99% of the time it's setting_list — no listen_addresses, so the new PG listens only on localhost and the CLup server can't reach it.

This skill already pulls setting_list from get_init_db_conf automatically, so it shouldn't recur. If it does come back after you've edited the script, check whether listen_addresses='*' is in setting_list.

Pitfall 3 · state=0 is not a fault

In the CLup version running in production, clup_cluster.state=0 means normal (every healthy cluster in the database is 0). The 1=Normal written in CLAUDE.md refers to the logical HA state, not a column in this table.

To judge health, look at:

• clup_db.db_state=0 (Running)
• The primary and standby roles are correct
• pg_stat_replication is streaming (state=streaming and replay_lsn=sent_lsn)

The v1 scope — stated plainly, no hedging

Supported in v1	Not supported in v1
Hosts already online	Creating new VMs first, then the cluster (`create_vm_sr_cluster` deferred to v2)
Explicit primary/standby (`--primary` / `--standby`)	Forcing it through when there aren't enough hosts
At least 1 primary + 1 standby; 1 primary + 2 standbys recommended	—

One separate note on credential security: a password passed via --pass shows up in the process command line (ps aux will reveal it), so prefer the environment variables CLUP_USER / CLUP_PASS (they're read first by default, and the flag is used only if they're not set).

Finally

The most instructive thing about the pg-create-cluster skill isn't its commands or its script — it's how it respects the way human cognition works:

• One question at a time
• Choose from real data
• Connection before credentials

Get these three right, and an AI assistant really does go from "tool" to "partner."

For the past decade, ops tooling has been subtracting — fewer commands, fewer parameters, thinner documentation. Over the next decade, ops tooling will start adding — tools that ask you questions and take the cognitive load off your hands.

pg-create-cluster is the most underrated step in that shift. It looks like just a skill, but the subtext is: DBA tools have finally grown a voice.

If this trend holds, then in the next decade a DBA's core skill won't be "how many commands you remember," but "how to ask the right question and get an AI assistant to run the commands well for you."

📌 If building a PG streaming replication cluster still gives you a headache today, set up Claude Code + the pg-create-cluster Skill right now, then tell Claude Code: "build me a PG 16.10 cluster with 1 primary and 2 standbys," and let it run the whole flow for you.

Skill link:
https://skillhub.openanolis.cn/skill/pg-create-cluster
Skillhub website link:
https://skillhub.openanolis.cn

Community

Anolis SkillHub Picks: Deploy and Manage a PG Cluster in One Sentence

What's really going on: the tool grows a voice

Three things you must confirm first

"Feels like a chat, not a form" is the soul of this skill

The user only decides 6 things

The main path is just these 4 commands

Potholes the author already hit for you

Pitfall 1 · Password mix-up

Pitfall 2 · database not connected

Pitfall 3 · state=0 is not a fault

The v1 scope — stated plainly, no hedging

Finally

Read previous post:

OpenAnolis

You may also like

Comments

OpenAnolis

Related Products

QwenWork

PolarDB for PostgreSQL

Token Plan

DeepSeek