之前幫一個(gè)監(jiān)控平臺(tái)搭時(shí)序存儲(chǔ)單節(jié)點(diǎn)TimescaleDB跑得挺好查詢響應(yīng)都在毫秒級?？僧?dāng)業(yè)務(wù)提出要加一套只讀副本做實(shí)時(shí)看板、同時(shí)防止宿主機(jī)宕機(jī)導(dǎo)致數(shù)據(jù)不可用時(shí)我就意識到不能再靠單庫硬扛了。TimescaleDB雖然強(qiáng)在時(shí)序壓縮和超表能力但它底子還是PostgreSQL要做副本、做容災(zāi)走的還是PostgreSQL流復(fù)制Streaming Replication這條路。但很多人對流復(fù)制的經(jīng)驗(yàn)停留在裸機(jī)手工部署換到docker-compose之后配置文件、權(quán)限、初始化順序到處是坑一個(gè)不小心從庫就起不來。這篇文章把我實(shí)際跑通的TimescaleDB(PostgreSQL)流復(fù)制集群容器化部署方案完整拆一遍從WAL同步原理、主從配置、pg_basebackup初始化到故障切換和踩坑細(xì)節(jié)都會(huì)講到。適合已經(jīng)在用TimescaleDB但沒有HA經(jīng)驗(yàn)、或者想用docker-compose快速搭一套本地時(shí)序集群的團(tuán)隊(duì)參考。方案不追求復(fù)雜架構(gòu)一主一從最常規(guī)跑通之后再加只讀節(jié)點(diǎn)、做讀寫分離都很容易。1. 時(shí)序數(shù)據(jù)場景下為什么我不建議繼續(xù)用單機(jī)TimescaleDB1.1 單機(jī)在監(jiān)控?cái)?shù)據(jù)面前的兩個(gè)真實(shí)瓶頸很多團(tuán)隊(duì)最開始用TimescaleDB都是看中它的超表Hypertable能力。一張表按時(shí)間自動(dòng)分chunk冷熱數(shù)據(jù)自動(dòng)管理時(shí)序聚合查詢比原生PostgreSQL順手很多。單節(jié)點(diǎn)在數(shù)據(jù)量幾千萬、上億的時(shí)候依然能跑這也是TimescaleDB的賣點(diǎn)。但單節(jié)點(diǎn)的瓶頸不只在數(shù)據(jù)量而在“可用性”和“業(yè)務(wù)架構(gòu)”兩個(gè)層面。第一宿主機(jī)一掛整個(gè)監(jiān)控大盤就沒數(shù)據(jù)了對線上業(yè)務(wù)來說這是不可接受的第二業(yè)務(wù)想看板、要做報(bào)表、要做一些偏重的分析查詢這些查詢會(huì)和寫入搶CPU、搶IO單庫扛不住。流復(fù)制集群解決不了性能橫向擴(kuò)展的全部問題但能解決“只讀流量分離”和“故障時(shí)快速切換”這兩個(gè)最剛需的問題。所以我的建議很清楚TimescaleDB做主寫節(jié)點(diǎn)一臺(tái)從庫專門扛讀查詢和看板日常還能拿從庫做數(shù)據(jù)分析這是一套性價(jià)比很高的架構(gòu)。1.2 流復(fù)制解決的是可用性問題不是性能擴(kuò)展這里必須把預(yù)期放正。很多文章會(huì)把流復(fù)制描述成“集群”實(shí)際上它本質(zhì)上是“主庫持續(xù)把WAL日志送到備庫并重放”的數(shù)據(jù)保護(hù)機(jī)制。從庫不是負(fù)載均衡集群里的worker而是一份完整的數(shù)據(jù)副本。所以它解決的是主庫宕機(jī)后數(shù)據(jù)不丟、業(yè)務(wù)能切到從庫繼續(xù)跑讀請求可以從從庫走減輕主庫壓力。如果你的目標(biāo)是寫性能水平擴(kuò)展那需要的是讀寫中間件分片或TimescaleDB分布式版而不是流復(fù)制。這個(gè)邊界搞清楚后面遇到問題才不會(huì)慌。1.3 為什么復(fù)制節(jié)點(diǎn)也必須加載TimescaleDB擴(kuò)展這是大家最容易忽略的點(diǎn)。TimescaleDB不只是幾張表它通過shared_preload_libraries在PostgreSQL啟動(dòng)時(shí)加載鉤子函數(shù)在后臺(tái)維護(hù)chunk、壓縮、連續(xù)聚合等一系列邏輯。從庫通過WAL重放拿到的是物理數(shù)據(jù)塊不是邏輯SQL。也就是說從庫如果沒加載TimescaleDB擴(kuò)展數(shù)據(jù)文件雖然都在但查詢超表時(shí)數(shù)據(jù)庫根本不知道這張表是超表也無法正確路由到對應(yīng)chunk。我見過有人從庫配好后SELECT * FROM sensor_data直接報(bào)錯(cuò)或者查不到數(shù)據(jù)最后發(fā)現(xiàn)就是擴(kuò)展沒加載。2. 流復(fù)制鏈路里WAL是怎么從主庫“流”到從庫的2.1 從walsender到walreceiver的完整鏈路理解流復(fù)制不需要把源碼讀完但幾個(gè)關(guān)鍵角色必須知道。主庫側(cè)有一個(gè)walsender進(jìn)程負(fù)責(zé)把WAL數(shù)據(jù)通過網(wǎng)絡(luò)傳給備庫。備庫側(cè)有兩個(gè)關(guān)鍵進(jìn)程walreceiver負(fù)責(zé)接收WAL流startup進(jìn)程負(fù)責(zé)把收到的WAL重放到數(shù)據(jù)文件里。整個(gè)鏈路是異步的備庫時(shí)刻追著主庫的WAL末尾跑。PostgreSQL 15之后流復(fù)制相關(guān)的函數(shù)和視圖名字有些變化。比如pg_stat_wal_receiver是備庫視角查的是接收狀態(tài)pg_stat_replication是主庫視角查的是每個(gè)walsender連接的復(fù)制狀態(tài)。部署完成后我習(xí)慣在主庫和備庫各查一次這兩個(gè)視圖能快速判斷鏈路是否正常。2.2 復(fù)制槽不是可有可無的復(fù)制槽Replication Slot是流復(fù)制里的一個(gè)關(guān)鍵設(shè)計(jì)。主庫的WAL文件是循環(huán)使用的如果備庫斷了一會(huì)兒主庫可能已經(jīng)把備庫還沒拿走的WAL覆蓋了那備庫重新連上時(shí)就沒法繼續(xù)同步只能重新全量初始化。復(fù)制槽會(huì)讓主庫保留從庫還沒消費(fèi)的WAL保護(hù)備庫追上來。代價(jià)是如果備庫掛了很久沒消費(fèi)主庫的WAL會(huì)一直累積磁盤會(huì)被撐爆。所以復(fù)制槽設(shè)計(jì)是個(gè)雙刃劍要么做好監(jiān)控要么用wal_keep_size加物理保留策略配合使用。在pg_basebackup初始化從庫時(shí)指定一個(gè)永久復(fù)制槽是最穩(wěn)妥的這也是我下面腳本里的做法。2.3 同步提交與異步復(fù)制的選擇流復(fù)制默認(rèn)是異步的主庫提交事務(wù)后不需要等備庫確認(rèn)性能損耗極小。異步復(fù)制的風(fēng)險(xiǎn)是主庫宕機(jī)瞬間最后少量已提交事務(wù)可能還沒到備庫切換后會(huì)有數(shù)據(jù)丟失。PostgreSQL的同步復(fù)制通過synchronous_commit控制備庫確認(rèn)方式可以是remote_write、remote_apply等。同步復(fù)制能保證主備數(shù)據(jù)一致但每次寫入都要等網(wǎng)絡(luò)往返寫入性能明顯下降。時(shí)序場景寫入頻繁一審量級的數(shù)據(jù)同步流量非常大我日常部署默認(rèn)用異步業(yè)務(wù)方如果明確要求RPO0再單獨(dú)討論同步方案。這里給一個(gè)經(jīng)驗(yàn)值單機(jī)寫入10000條/秒左右的監(jiān)控?cái)?shù)據(jù)內(nèi)網(wǎng)環(huán)境下異步流復(fù)制的延遲通常在幾十毫秒以內(nèi)肉眼幾乎看不出差異。3. 部署前必須定下的版本、目錄和網(wǎng)絡(luò)規(guī)劃3.1 鏡像版本如何鎖TimescaleDB tag與PG主版本的綁定關(guān)系TimescaleDB鏡像的tag很有講究它是和PostgreSQL主版本綁定的。比如timescale/timescaledb:latest-pg16最后的pg16表示基礎(chǔ)鏡像的PostgreSQL大版本。你不能只看TimescaleDB版本而忽略PG版本因?yàn)閮蓚€(gè)節(jié)點(diǎn)如果PG主版本不一致pg_basebackup拉過來的數(shù)據(jù)目錄根本沒法啟動(dòng)。我的建議是開發(fā)環(huán)境可以用latest-pg16圖省事生產(chǎn)環(huán)境一定要鎖具體版本。比如timescale/timescaledb:2.17.2-pg16這樣鏡像拉取、重建、回滾都可控。鏡像tag一變一旦TimescaleDB做了兼容性調(diào)整主從兩個(gè)節(jié)點(diǎn)版本不一致重放WAL時(shí)很容易報(bào)FATAL: could not start WAL stream。為了統(tǒng)一管理版本我用一個(gè).env文件放在項(xiàng)目根目錄POSTGRES_MAJOR16 TIMESCALEDB_TAG2.17.2-pg16 POSTGRES_USERpostgres POSTGRES_PASSWORDpostgres123 REPLICATION_USERreplicator REPLICATION_PASSWORDreplicator123 REPLICATION_SLOTreplica_slot3.2 目錄結(jié)構(gòu)與配置掛載方案整個(gè)項(xiàng)目目錄我習(xí)慣這樣組織timescaledb-cluster/ ├── .env ├── docker-compose.yml ├── master/ │ ├── postgresql.conf │ ├── pg_hba.conf │ └── init/ │ └── 01-create-replication-user.sql ├── replica/ │ ├── postgresql.conf │ ├── pg_hba.conf │ └── init-replica.sh └── data/ ├── master/ └── replica/主庫和從庫的配置文件一定要分開不要共用一份。原因有兩個(gè)第一從庫的primary_conninfo、primary_slot_name這些連接主庫的參數(shù)主庫配置里不該有第二主庫和從庫雖然大部分參數(shù)一致但將來你很可能需要給從庫調(diào)不同的work_mem、max_connections共用一份文件會(huì)讓兩個(gè)節(jié)點(diǎn)互相污染。數(shù)據(jù)目錄用bind mount掛到宿主機(jī)data/下方便排查問題。但要注意權(quán)限容器內(nèi)postgres用戶默認(rèn)uid是999掛載目錄后宿主機(jī)目錄歸屬如果不是999容器啟動(dòng)時(shí)會(huì)遇到權(quán)限拒絕。一個(gè)簡單的辦法是創(chuàng)建目錄后執(zhí)行mkdir -p data/master data/replica chown -R 999:999 data3.3 自定義網(wǎng)絡(luò)與固定IPdocker-compose默認(rèn)會(huì)創(chuàng)建一個(gè)網(wǎng)絡(luò)但容器重啟后IP可能變化。流復(fù)制場景下primary_conninfo里寫的主庫host建議用服務(wù)名timescaledb-masterdocker內(nèi)部DNS會(huì)自動(dòng)解析IP變不變其實(shí)問題不大。但我還是習(xí)慣給集群指定一個(gè)獨(dú)立網(wǎng)段和固定IP理由有兩點(diǎn)一是pg_hba.conf里如果要按IP限制訪問固定IP可以精確控制二是后續(xù)如果有其他中間件容器要接入這個(gè)集群固定IP比容器名更好排查網(wǎng)絡(luò)鏈路。網(wǎng)絡(luò)規(guī)劃如下networks: cluster: driver: bridge ipam: config: - subnet: 172.28.0.0/24主庫分配172.28.0.10從庫分配172.28.0.11端口映射上主庫映射宿主機(jī)5432從庫映射5433這樣宿主機(jī)上兩個(gè)庫都能訪問只讀流量走5433寫流量走5432。4. 主庫配置和初始化復(fù)制用戶、hba與復(fù)制槽4.1 主庫postgresql.conf的關(guān)鍵參數(shù)主庫的postgresql.conf不需要面面俱到但和流復(fù)制相關(guān)的參數(shù)必須正確。下面是完整配置listen_addresses * hba_file /etc/postgresql/pg_hba.conf wal_level replica max_wal_senders 4 max_replication_slots 4 wal_keep_size 512MB shared_preload_libraries timescaledb synchronous_commit off wal_log_hints on逐個(gè)說明一下。wal_level replica是流復(fù)制的最低要求它保證WAL里包含足夠的信息供備庫重放。max_wal_senders和max_replication_slots決定了最多能連接幾個(gè)備庫一主一從設(shè)4足夠如果你以后想加到3個(gè)從庫也能扛住。wal_keep_size 512MB是PG15之后的參數(shù)相當(dāng)于給主庫額外保留512MB的WAL防止備庫短暫斷開后因?yàn)閺?fù)制槽沒建好導(dǎo)致追不上。wal_log_hints on是為將來可能用pg_rewind做時(shí)間線回退準(zhǔn)備的現(xiàn)在不開啟以后想開還需要重啟。最后一行shared_preload_libraries timescaledb是整個(gè)方案的核心。主庫靠它加載TimescaleDB從庫的配置文件里也必須有一模一樣的配置。4.2 pg_hba.conf里replication條目為什么單獨(dú)寫pg_hba.conf是很多人的盲區(qū)。流復(fù)制連接走的是replication偽數(shù)據(jù)庫它在pg_hba.conf里不是普通數(shù)據(jù)庫條目必須單獨(dú)寫。我的配置如下local all all trust host all all 0.0.0.0/0 md5 local replication all trust host replication replicator 0.0.0.0/0 md5注意最后一行我限定只有replicator用戶允許從任意IP發(fā)起復(fù)制連接而且只能用md5密碼認(rèn)證。不要用trust去放行replication否則任何能連通5432端口的人都能拖走你全庫數(shù)據(jù)。這里如果配置漏了從庫pg_basebackup時(shí)會(huì)直接報(bào)FATAL: no pg_hba.conf entry for replication connection from host。4.3 復(fù)制用戶與物理復(fù)制槽的創(chuàng)建主庫第一次啟動(dòng)時(shí)官方鏡像會(huì)執(zhí)行/docker-entrypoint-initdb.d/目錄下的所有.sql和.sh腳本。我利用這個(gè)機(jī)制創(chuàng)建復(fù)制用戶-- master/init/01-create-replication-user.sql CREATE ROLE replicator WITH REPLICATION LOGIN PASSWORD replicator123;這里給replicator角色加了REPLICATION權(quán)限這是它執(zhí)行pg_basebackup和建立復(fù)制流的必要條件。物理復(fù)制槽我選擇放在從庫初始化腳本里動(dòng)態(tài)創(chuàng)建而不是寫死在主庫的init目錄。原因很直接如果從庫數(shù)據(jù)卷被我清掉重新初始化腳本可以在不手動(dòng)登錄主庫的情況下自動(dòng)補(bǔ)建slot省去一次人工操作。主庫的init目錄只需要保證復(fù)制用戶存在slot由從庫腳本用SQL檢查后再創(chuàng)建。5. 從庫初始化腳本pg_basebackup拉取與自動(dòng)拉起5.1 官方entrypoint沒法直接干這件事docker官方postgres鏡像有一個(gè)特點(diǎn)如果容器啟動(dòng)命令不是postgres它不會(huì)自動(dòng)執(zhí)行initdb。這個(gè)特性正好可以被我們用來做自定義從庫初始化但也意味著我們需要自己處理數(shù)據(jù)目錄的創(chuàng)建、權(quán)限、初始化這三件事。很多人一開始的思路是給從庫也掛docker-entrypoint-initdb.d指望鏡像幫你把pg_basebackup跑了。這個(gè)思路有一個(gè)致命問題官方entrypoint在跑initdb.d腳本之前已經(jīng)執(zhí)行了initdb數(shù)據(jù)目錄里已經(jīng)生成了一套完整數(shù)據(jù)這時(shí)候你再pg_basebackup去覆蓋它容易留下臟文件而且腳本執(zhí)行環(huán)境也別扭。我的做法更干凈從庫啟動(dòng)命令直接指向一個(gè)自定義腳本數(shù)據(jù)目錄為空時(shí)跑pg_basebackup非空時(shí)直接正常啟動(dòng)。5.2 init-replica.sh完整腳本拆解先看完整腳本再逐步解釋#!/bin/bash set -e MASTER_HOSTtimescaledb-master MASTER_PORT5432 REPLICATION_USER${REPLICATION_USER:-replicator} REPLICATION_PASSWORD${REPLICATION_PASSWORD:-replicator123} REPLICATION_SLOT${REPLICATION_SLOT:-replica_slot} export PGPASSWORD${POSTGRES_PASSWORD} # 1. 等待主庫復(fù)制用戶創(chuàng)建完成 echo [replica] waiting for master replication user... until psql -h $MASTER_HOST -p $MASTER_PORT -U $POSTGRES_USER -d postgres -tAc \ SELECT 1 FROM pg_roles WHERE rolname${REPLICATION_USER} 2/dev/null | grep -q 1; do sleep 2 done echo [replica] creating replication slot if not exists psql -h $MASTER_HOST -p $MASTER_PORT -U $POSTGRES_USER -d postgres -tAc \ SELECT 1 FROM pg_replication_slots WHERE slot_name${REPLICATION_SLOT} | grep -q 1 || \ psql -h $MASTER_HOST -p $MASTER_PORT -U $POSTGRES_USER -d postgres -c \ SELECT pg_create_physical_replication_slot(${REPLICATION_SLOT}); # 2. 準(zhǔn)備數(shù)據(jù)目錄 mkdir -p $PGDATA chown postgres:postgres $PGDATA chmod 700 $PGDATA # 3. 寫.pgpass供后續(xù)流復(fù)制連接認(rèn)證使用 cat /var/lib/postgresql/.pgpass EOF ${MASTER_HOST}:${MASTER_PORT}:replication:${REPLICATION_USER}:${REPLICATION_PASSWORD} EOF chown postgres:postgres /var/lib/postgresql/.pgpass chmod 600 /var/lib/postgresql/.pgpass # 4. 如果數(shù)據(jù)目錄還沒有PG_VERSION就全量拉取主庫數(shù)據(jù) if [ ! -s $PGDATA/PG_VERSION ]; then echo [replica] running pg_basebackup from master... export PGPASSWORD${REPLICATION_PASSWORD} gosu postgres pg_basebackup -h $MASTER_HOST -p $MASTER_PORT -U $REPLICATION_USER \ -D $PGDATA -R -X stream -S $REPLICATION_SLOT -P -v rm -f $PGDATA/postmaster.pid echo [replica] basebackup done else echo [replica] data directory already exists, skip basebackup fi # 5. 進(jìn)入正常啟動(dòng)流程 exec docker-entrypoint.sh postgres -c config_file/etc/postgresql/postgresql.conf幾個(gè)關(guān)鍵點(diǎn)展開說。等待循環(huán)為什么不用pg_isready而用psql查角色表因?yàn)閜g_isready只能判斷端口通沒通而主庫容器首次啟動(dòng)時(shí)會(huì)先跑一個(gè)臨時(shí)postgres執(zhí)行initdb.d腳本這時(shí)候端口已經(jīng)通了但復(fù)制用戶還沒創(chuàng)建完。如果從庫在這個(gè)時(shí)候發(fā)起pg_basebackup會(huì)因角色不存在失敗。所以必須等到pg_roles里能查到replicator。.pgpass是libpq的密碼文件。pg_basebackup用-R參數(shù)生成postgresql.auto.conf時(shí)不會(huì)把密碼明文寫進(jìn)去而是記錄passfile/var/lib/postgresql/.pgpass。如果不提前創(chuàng)建這個(gè)文件從庫容器重啟后流復(fù)制連接會(huì)因?yàn)槟貌坏矫艽a而反復(fù)失敗主庫pg_stat_replication里能看到state一直是startup。很多從庫“莫名其妙連不上”的問題根子都在這里。-X stream表示W(wǎng)AL通過復(fù)制流直接傳輸-S指定復(fù)制槽-R會(huì)生成從庫所需的postgresql.auto.conf里面自動(dòng)寫好primary_conninfo和primary_slot_name。整個(gè)腳本是冪等的。數(shù)據(jù)目錄已經(jīng)有PG_VERSION時(shí)它跳過basebackup直接啟動(dòng)postgres所以從庫容器重啟不會(huì)重復(fù)初始化。5.3 postgresql.auto.conf里的連接信息與同步參數(shù)pg_basebackup執(zhí)行完后從庫數(shù)據(jù)目錄下會(huì)生成一個(gè)postgresql.auto.conf內(nèi)容類似primary_conninfo userreplicator passfile/var/lib/postgresql/.pgpass channel_bindingprefer hosttimescaledb-master port5432 sslmodeprefer sslcompression0 sslcertmodeallow sslsni1 ssl_min_protocol_versionTLSv1.2 gssencmodeprefer krbsrvnamepostgres target_session_attrsany primary_slot_name replica_slot這里要提醒一句primary_conninfo不要手工寫進(jìn)從庫的postgresql.conf因?yàn)閜ostgresql.auto.conf的優(yōu)先級更高你寫半天最后會(huì)被auto.conf覆蓋容易產(chǎn)生“我明明改了為什么沒生效”的困惑。連接信息全權(quán)交給-R生成的auto.conf即可。如果你要啟用同步復(fù)制需要確保primary_conninfo里有application_name并且和主庫配置的synchronous_standby_names對應(yīng)。auto.conf默認(rèn)不帶application_name你可以在pg_basebackup完成后追加一行覆蓋或者在從庫啟動(dòng)前改掉auto.conf里的內(nèi)容。6. docker-compose.yml完整編排與健康檢查設(shè)計(jì)6.1 兩個(gè)service的配置要點(diǎn)docker-compose.yml是全流程的樞紐完整內(nèi)容如下version: 3.9 services: master: image: timescale/timescaledb:${TIMESCALEDB_TAG} container_name: timescaledb-master environment: POSTGRES_USER: ${POSTGRES_USER} POSTGRES_PASSWORD: ${POSTGRES_PASSWORD} PGDATA: /var/lib/postgresql/data volumes: - ./data/master:/var/lib/postgresql/data - ./master/postgresql.conf:/etc/postgresql/postgresql.conf:ro - ./master/pg_hba.conf:/etc/postgresql/pg_hba.conf:ro - ./master/init:/docker-entrypoint-initdb.d:ro command: [postgres, -c, config_file/etc/postgresql/postgresql.conf] healthcheck: test: [CMD-SHELL, pg_isready -U ${POSTGRES_USER} -d postgres] interval: 5s timeout: 3s retries: 20 start_period: 10s networks: cluster: ipv4_address: 172.28.0.10 ports: - 5432:5432 replica: image: timescale/timescaledb:${TIMESCALEDB_TAG} container_name: timescaledb-replica environment: POSTGRES_USER: ${POSTGRES_USER} POSTGRES_PASSWORD: ${POSTGRES_PASSWORD} REPLICATION_USER: ${REPLICATION_USER} REPLICATION_PASSWORD: ${REPLICATION_PASSWORD} REPLICATION_SLOT: ${REPLICATION_SLOT} PGDATA: /var/lib/postgresql/data volumes: - ./data/replica:/var/lib/postgresql/data - ./replica/postgresql.conf:/etc/postgresql/postgresql.conf:ro - ./replica/pg_hba.conf:/etc/postgresql/pg_hba.conf:ro - ./replica/init-replica.sh:/init-replica.sh:ro command: [bash, /init-replica.sh] depends_on: master: condition: service_healthy networks: cluster: ipv4_address: 172.28.0.11 ports: - 5433:5432 healthcheck: test: [CMD-SHELL, pg_isready -U ${POSTGRES_USER} -d postgres] interval: 5s timeout: 3s retries: 20 start_period: 20s networks: cluster: driver: bridge ipam: config: - subnet: 172.28.0.0/24主庫的command用-c config_file/etc/postgresql/postgresql.conf指定我們掛載的配置文件避免用到數(shù)據(jù)目錄里的默認(rèn)配置。從庫因?yàn)橐茏远x初始化腳本command直接指向bash /init-replica.sh。腳本最后會(huì)調(diào)用docker-entrypoint.sh postgres -c config_file...進(jìn)入正常啟動(dòng)流程。6.2 depends_on為什么不夠healthcheck才是關(guān)鍵docker-compose里depends_on默認(rèn)只控制容器啟動(dòng)順序不等應(yīng)用就緒。也就是說從庫容器啟動(dòng)時(shí)主庫可能還在跑initdb復(fù)制用戶都還沒創(chuàng)建。depends_on加condition: service_healthy之后compose會(huì)等主庫healthcheck通過才啟動(dòng)從庫。主庫的healthcheck用了pg_isready這是在dokcer層面做的一次“端口可用性”檢查。但如前面說的主庫臨時(shí)postgres階段端口也是通的所以從庫腳本內(nèi)部還做了一層角色等待。這兩層配合才能保證從庫初始化時(shí)主庫真正可服務(wù)。6.3 啟動(dòng)順序與冪等性設(shè)計(jì)整個(gè)編排有一個(gè)隱藏優(yōu)點(diǎn)從庫腳本天然冪等。docker compose down之后再up從庫數(shù)據(jù)目錄已經(jīng)有了PG_VERSION腳本會(huì)跳過pg_basebackup直接啟動(dòng)從庫復(fù)制鏈路自動(dòng)恢復(fù)。真正需要警惕的是如果你手動(dòng)清掉了從庫數(shù)據(jù)目錄腳本會(huì)重新全量拉數(shù)據(jù)。拉數(shù)據(jù)期間主庫的WAL必須保留足夠多否則pg_basebackup會(huì)報(bào)requested WAL segment has already been removed。復(fù)制槽就是用來解決這個(gè)問題的所以腳本里先確保slot存在再執(zhí)行basebackup是有講究的。7. 部署后的驗(yàn)證復(fù)制狀態(tài)、超表查詢與延遲觀測7.1 復(fù)制狀態(tài)SQL判讀部署完成后第一步不是急著造數(shù)據(jù)而是確認(rèn)復(fù)制鏈路狀態(tài)。在主庫執(zhí)行SELECT pid, application_name, state, sync_state, replay_lag FROM pg_stat_replication;能看到一行記錄state為streamingsync_state為async因?yàn)槲覀儧]開同步復(fù)制說明從庫已經(jīng)追著主庫走了。如果state一直是startup或catchup說明從庫還在初始化或追趕中。從庫上執(zhí)行SELECT pg_is_in_recovery();返回t說明當(dāng)前是備庫處于只讀熱備狀態(tài)。再查SELECT pg_last_wal_receive_lsn(), pg_last_wal_replay_lsn();兩個(gè)值應(yīng)該非常接近甚至完全相等。receive_lsn是從庫已經(jīng)接收到的WAL位置replay_lsn是已經(jīng)重放的位置如果差距持續(xù)增大說明從庫重放速度跟不上寫入速度。7.2 在主庫建超表并寫入從庫同步查詢驗(yàn)證復(fù)制鏈路只是第一步還要驗(yàn)證TimescaleDB擴(kuò)展在主從兩個(gè)節(jié)點(diǎn)都正常工作。在主庫執(zhí)行CREATE TABLE sensor_data ( time TIMESTAMPTZ NOT NULL, device_id INTEGER, temperature DOUBLE PRECISION ); SELECT create_hypertable(sensor_data, time);然后寫入一批測試數(shù)據(jù)INSERT INTO sensor_data SELECT now() - (i || minutes)::interval, i % 10, random() * 30 15 FROM generate_series(1, 10000) i;到從庫上執(zhí)行SELECT time_bucket(1 minute, time) AS bucket, avg(temperature) FROM sensor_data GROUP BY bucket ORDER BY bucket LIMIT 10;能正常返回結(jié)果且數(shù)據(jù)量和主庫一致說明從庫已經(jīng)成功加載TimescaleDB擴(kuò)展WAL重放也正常。如果從庫沒加載擴(kuò)展這一步大概率會(huì)報(bào)錯(cuò)或者只能查到部分?jǐn)?shù)據(jù)這時(shí)回到配置文件檢查shared_preload_libraries。7.3 replay_lag觀測與從庫只讀約束從庫畢竟是只讀節(jié)點(diǎn)如果業(yè)務(wù)誤把寫請求發(fā)到5433端口會(huì)收到明確的報(bào)錯(cuò)ERROR: cannot execute INSERT in a read-only transaction這是預(yù)期行為不用慌。但如果你的應(yīng)用需要從庫提供強(qiáng)一致的讀要注意從庫默認(rèn)存在復(fù)制延遲。時(shí)序場景一般幾毫秒到幾十毫秒可接受。如果延遲突然飆升優(yōu)先看主庫的WAL生成量和從庫的磁盤IO大概率是從庫重放瓶頸。8. 故障切換實(shí)驗(yàn)與把原主庫拉回新從庫8.1 手動(dòng)提升從庫的操作與驗(yàn)證流復(fù)制本身沒有自動(dòng)故障轉(zhuǎn)移能力這一點(diǎn)必須提前跟團(tuán)隊(duì)講清楚。但人工切換很簡單模擬主庫宕機(jī)docker stop timescaledb-master然后進(jìn)入從庫容器提升它docker exec -it timescaledb-replica psql -U postgres -c SELECT pg_promote();再驗(yàn)證SELECT pg_is_in_recovery();返回f從庫已經(jīng)變成新的主庫可以正常接收寫入了。此時(shí)應(yīng)用連接需要切到5433端口也就是從庫映射出來的端口。如果有負(fù)載均衡器把后端摘掉故障主庫即可。8.2 原主庫恢復(fù)為從庫的完整步驟原主庫因?yàn)橹笆侵鲙鞌?shù)據(jù)已經(jīng)和新的主庫分叉了直接啟動(dòng)繼續(xù)跑流復(fù)制是行不通的?；謴?fù)思路只有一個(gè)把它當(dāng)作一個(gè)全新的從庫重新初始化。具體操作是清空原主庫數(shù)據(jù)目錄讓init-replica.sh邏輯重新在新主庫上做一次pg_basebackup。這里有個(gè)細(xì)節(jié)原主庫容器還掛著master/init目錄第一次啟動(dòng)時(shí)會(huì)重復(fù)執(zhí)行01-create-replication-user.sql這會(huì)導(dǎo)致創(chuàng)建角色報(bào)錯(cuò)“already exists”。我在實(shí)際恢復(fù)時(shí)會(huì)把master目錄臨時(shí)改一個(gè)名字或者把它從docker-compose的正常啟動(dòng)流程里摘出來用一個(gè)一次性的初始化容器執(zhí)行從庫腳本再改回配置正常啟動(dòng)。如果你不想動(dòng)目錄結(jié)構(gòu)也可以用另一個(gè)更簡單的思路保留init-replica.sh腳本修改MASTER_HOST為新主庫然后把原主庫的volumes臨時(shí)改成從庫數(shù)據(jù)卷讓它按從庫方式初始化一次再改回來?？傊诵氖恰叭恐亟ā辈灰竿鲙炷茉貜?fù)活成從庫。8.3 自動(dòng)故障切換的邊界如果業(yè)務(wù)要求“主庫掛了自動(dòng)切換應(yīng)用無感知”那需要引入Patroni、repmgr或pg_auto_failover這類外部工具。TimescaleDB和PostgreSQL在這件事上一樣流復(fù)制只負(fù)責(zé)數(shù)據(jù)同步不負(fù)責(zé)選主、不負(fù)責(zé)VIP漂移、不負(fù)責(zé)應(yīng)用端連接切換。docker-compose方案最適合的場景是開發(fā)環(huán)境、預(yù)發(fā)環(huán)境、或者人力可以7x24響應(yīng)的小規(guī)模生產(chǎn)環(huán)境。真要做自動(dòng)HA建議在流復(fù)制基礎(chǔ)上疊加Patroni那是另一個(gè)更復(fù)雜的架構(gòu)話題本篇不再展開。9. 實(shí)際運(yùn)維中容易翻車的四個(gè)細(xì)節(jié)9.1 復(fù)制槽殘留導(dǎo)致主庫WAL膨脹這是流復(fù)制集群最高頻的故障。從庫如果被刪除或者長時(shí)間離線主庫上的物理復(fù)制槽還掛著WAL就一直累積不清理最后磁盤寫滿主庫直接宕機(jī)。對策是定期監(jiān)控SELECT slot_name, active, pg_size_pretty(pg_wal_lsn_diff(pg_current_wal_lsn(), restart_lsn)) AS lag_bytes FROM pg_replication_slots;如果發(fā)現(xiàn)某個(gè)slot已經(jīng)不active了確認(rèn)對應(yīng)從庫不會(huì)回來后第一時(shí)間手動(dòng)刪除SELECT pg_drop_replication_slot(replica_slot);這個(gè)操作要謹(jǐn)慎刪早了從庫會(huì)失去WAL保護(hù)。我的習(xí)慣是先看從庫的pg_stat_wal_receiver狀態(tài)確定它真的失聯(lián)了再刪。9.2 同步復(fù)制的APPLICATION_NAME必須匹配如果你啟用了同步復(fù)制主庫參數(shù)變成synchronous_standby_names replica1 synchronous_commit remote_apply那從庫的primary_conninfo里必須帶application_namereplica1。如果名字對不上主庫沒有可用的同步備庫事務(wù)提交會(huì)一直等待你看到的現(xiàn)象就是“寫入hang住”但日志里沒有任何明顯報(bào)錯(cuò)。排查這類問題看pg_stat_replication里的application_name和synchronous_standby_names是否匹配就行。9.3 腳本CRLF和權(quán)限問題從庫初始化腳本是在宿主機(jī)上編輯再掛載進(jìn)Linux容器的。如果你在Windows上編輯過腳本會(huì)帶CRLF換行容器里執(zhí)行會(huì)報(bào)/bin/bash^M: bad interpreter。解決方式很簡單sed -i s/\r$// replica/init-replica.sh另外腳本掛載進(jìn)容器后需要可執(zhí)行權(quán)限在宿主機(jī)上執(zhí)行chmod x replica/init-replica.sh即使compose里的command是bash /init-replica.sh沒有執(zhí)行權(quán)限也能跑但如果有人在容器里想直接執(zhí)行腳本就會(huì)卡住。權(quán)限問題不是大坑但很煩人。9.4 流復(fù)制副本不等于備份最后說一個(gè)很多人容易混淆的概念從庫是實(shí)時(shí)副本但它不是備份。如果主庫上有人執(zhí)行了誤刪除操作這個(gè)刪除會(huì)瞬間同步到從庫兩份數(shù)據(jù)一起丟。流復(fù)制解決的是硬件故障不是邏輯錯(cuò)誤。我現(xiàn)在的習(xí)慣是在流復(fù)制集群之外再定期用pg_dump做邏輯備份或者引入pgBackRest做物理備份。docker-compose方案里可以加一個(gè)定時(shí)任務(wù)容器每天凌晨從從庫那邊做全量備份既不影響主庫業(yè)務(wù)又能在邏輯誤刪時(shí)派上用場。我自己在實(shí)際操作中還有一個(gè)小偏好所有配置文件盡量用LF換行、盡量用latest-pg16跑通后再鎖版本。這套集群我已經(jīng)在不同環(huán)境重復(fù)部署過多次每次踩坑基本都集中在復(fù)制槽殘留、.pgpass文件和healthcheck等待這三個(gè)點(diǎn)上。如果按照上面的步驟從零走一遍大概率能一次跑通。后續(xù)如果你想在這個(gè)基礎(chǔ)上加只讀節(jié)點(diǎn)把replica服務(wù)復(fù)制一份改容器名、IP、端口和slot名就行原理完全一樣。