Postgres versiyasini yangilash: minor va major, pg_upgrade --link va Docker tuzog'i

Qisqacha: Minor yangilash (17.5 → 17.6) — faqat dasturni almashtirib qayta ishga tushirish, ma'lumot fayllari o'zgarmaydi. Major yangilash (17 → 18) — fayl formati boshqa, shuning uchun ikki yo'l bor: pg_dump / pg_restore (sekin, lekin ishonchli va har qanday versiyalar orasida) yoki pg_upgrade (tez, --link bilan fayllarni ko'chirmaydi ham). Ikki tuzoq: PG 18 initdb sukut bo'yicha data checksums yoqadi va eski klaster bilan mos kelmaydi; postgres:18 Docker image'i eski volume'ni ochishdan bosh tortadi.

Bu darsda

• Minor va major yangilash farqini va har birining xavfini tushuntirasiz.
• dump/restore va pg_upgrade ni tezlik, xavf va to'xtash vaqti bo'yicha taqqoslaysiz.
• pg_upgrade --check, copy va --link rejimlarini bilasiz.
• PG 18 dagi checksums va statistika o'zgarishlarini hisobga olasiz.
• Docker'da major versiyani almashtirishning to'g'ri yo'lini tanlaysiz.

Oldin bilishingiz kerak: Backup va restore, Postgres arxitekturasi va asosiy sozlamalar, Volume va bind mount, Extension'lar.

1. Nega bu kerak?

Har Postgres major versiyasi taxminan besh yil qo'llab-quvvatlanadi. Muddati tugagach, xavfsizlik tuzatishlari chiqmaydi. Bizning kanon PostgreSQL 18 da ishlaydi, lekin real loyihalarda hali 13, 14, 16 ham ko'p uchraydi — ularni kimdir, qachondir ko'tarishi kerak.

Yangilashning ikki xavfi bor. Birinchisi — ma'lumotni yo'qotish: noto'g'ri buyruq eski klasterni buzadi, yangisi esa ishga tushmaydi. Ikkinchisi — uzoq to'xtash: 200 GB lik bazani dump qilib qayta yuklash soatlab davom etadi, shu vaqt davomida sayt ishlamaydi.

O'xshatish: uyning elektr simlarini almashtirish. Lampochkani almashtirish (minor) — bir daqiqa, uyda hamma yashashda davom etadi. Butun simni yangisiga o'tkazish (major) — rejali ish: oldin tekshiruv, zaxira yo'l, va o'chirish vaqti oldindan e'lon qilinadi.

Diqqat: Raqamlar va xabarlar — kanon tajribasidan: postgres:17 17.11-bob dan postgres:18 18.6-bob ga, holat 11 sxemasi + 200 000 vazifa (122 MB), Docker'da, 2026-10-24. Logical replication orqali yangilash va Linux paket menejerlari (pg_upgradecluster) — sinalmagan, hujjat bo'yicha. Bizning o'z klasterimiz — PostgreSQL 17.6 (Windows).

2. Minor va major

2.1 Versiya raqami

PostgreSQL 10 dan beri versiya ikki qismdan iborat: 18.6 — 18 major, 6 minor.

Minor yangilashni kechiktirmang — u xavfsizlik teshiklarini yopadi. Backup va restore darsidagi \restrict himoyasi ham aynan minor relizlarda (17.6 va boshqalar) kelgan edi. Ba'zan minor reliz izohlarida "yangilagandan keyin falon indeksni qayta quring" degan qo'shimcha qadam bo'ladi — shuning uchun reliz izohini o'qish odati kerak.

2.2 Nega major oddiy almashtirish emas

Major versiyalar orasida tizim katalogi (pg_class, pg_attribute va boshqalar — "jadval qayerda, ustunlari qanday" degan ichki jadvallar) o'zgaradi. 18 versiyaning dasturi 17 ning ma'lumotlar papkasini o'qiy olmaydi va o'qishga urinmaydi ham — ishga tushishdan bosh tortadi. Shuning uchun ma'lumotni yangi formatga o'tkazish kerak.

Bizning klasterimizdagi versiya va holat — bitta so'rov bilan:

SHOW data_checksums;

Natija (PostgreSQL 17.6, sukut initdb):

 data_checksums
----------------
 off
(1 row)

Bu qator keyinroq muhim bo'ladi.

3. 1-yo'l: dump va restore

3.1 Qanday

Eng sodda va ishonchli yo'l — Backup va restore darsidagi mantiqiy zaxira:

1. Yangi (18) server alohida ishga tushiriladi.
2. Eski (17) serverdan yangi versiyaning pg_dump i bilan dump olinadi.
3. Yangi serverga pg_restore -j N bilan tiklanadi.
4. Ilova yangi serverga yo'naltiriladi.

Nega yangi versiyaning pg_dump i? pg_dump o'zidan eski serverlarni o'qiy oladi va yangi versiya sintaksisida yozadi. Teskarisi — eski pg_dump bilan yangi serverni — hujjat qo'llamaydi.

3.2 Kanon o'lchovi

Kanon 18 ning pg_dump ini tarmoq orqali 17 serverga ulab ishlatdi:

122 MB lik baza uchun 10 soniyadan kam. Lekin vaqt baza hajmiga chiziqli bog'liq: 100 GB baza uchun bu soatlar. Va dump boshlangandan keyin eski bazaga yozilgan narsa yangisiga tushmaydi — shuning uchun butun jarayon davomida ilova to'xtatiladi (yoki faqat o'qish rejimiga o'tkaziladi).

4. 2-yo'l: pg_upgrade

4.1 G'oya

Ma'lumot fayllarining o'zi (jadval sahifalari) major versiyalar orasida odatda o'zgarmaydi — o'zgaradigani tizim katalogi. pg_upgrade shundan foydalanadi: faqat sxemani (katalogni) dump/restore qiladi, jadval fayllarini esa shunchaki nusxalaydi yoki bog'laydi.

flowchart LR
  O[(eski klaster 17)] -->|sxema: dump/restore| N[(yangi klaster 18)]
  O -->|fayllar: copy| N
  O -.->|fayllar: --link| N

Diagrammada ikki yo'l: sxema har doim qayta yaratiladi; ma'lumot fayllari esa yo nusxalanadi (copy), yo hard link qilinadi (--link) — yangi klaster o'sha fayllarni ko'rsatadi, diskda nusxa paydo bo'lmaydi.

4.2 Tartib

pg_upgrade uchun ikkala versiyaning binarlari bir mashinada bo'lishi kerak. Kanon postgres:18 konteyneriga apt bilan postgresql-17 paketini qo'shib, quyidagi tartibda ishladi:

1. Eski klaster to'xtatiladi.
2. Yangi klaster initdb bilan yaratiladi (bo'sh).
3. pg_upgrade --check — faqat tekshiruv, hech narsa o'zgarmaydi.
4. pg_upgrade (yoki --link) — haqiqiy o'tkazish.
5. Yangi klaster ishga tushiriladi, statistika yig'iladi.
6. Hammasi yaxshi bo'lsa — eski klaster o'chiriladi.

Buyruq ko'rinishi (yo'llar Debian paketlaridagidek):

B=/usr/lib/postgresql
pg_upgrade --check \
  -b $B/17/bin -B $B/18/bin \
  -d /up/17 -D /up/18

-b/-B — eski va yangi binarlar papkasi, -d/-D — eski va yangi ma'lumotlar papkasi.

4.3 Birinchi urinish: checksums

Kanonning birinchi --check urinishi shunday tugadi:

Checking cluster versions                                     ok
old cluster does not use data checksums but the new one does
Failure, exiting

"Eski klaster data checksums ishlatmaydi, yangisi esa ishlatadi. Muvaffaqiyatsiz, chiqilmoqda". Sababi — PG 18 dagi o'zgarish: initdb endi sukut bo'yicha data checksums yoqadi. Checksums — har ma'lumot sahifasining nazorat yig'indisi: disk jim buzilsa, Postgres buni o'qishda sezadi. Foydali narsa, lekin pg_upgrade ikki klasterda bir xil bo'lishini talab qiladi. 17 ning initdb i esa ularni yoqmagan — biz yuqorida off ni ko'rdik.

Ikki yechim:

Kanon birinchisini tanladi. pg_checksums --enable katta bazada barcha fayllarni o'qib-yozadi va vaqt oladi — uni yangilashdan oldin, alohida oynada qilish ma'qul.

4.4 --check o'tdi

Yangi klaster --no-data-checksums bilan qayta yaratilgach (kanon chiqishidan qisqartirilgan):

Checking for prepared transactions                            ok
Checking data type usage                                      ok
Checking for objects affected by Unicode update               ok
Checking for presence of required libraries                   ok
Checking database user is the install user                    ok
*Clusters are compatible*

--check o'nlab tekshiruv qiladi: kerakli kutubxonalar (extension'lar) yangi versiyada bormi, eskirgan ma'lumot turlari ishlatilganmi, Unicode yangilanishi ta'sir qiladigan obyektlar bormi. "Klasterlar mos" — o'tkazish mumkin.

Tekshirib ko'ring: --check hech narsani o'zgartirmaydi. Unda nega uni alohida ishga tushirish kerak, to'g'ridan pg_upgrade emas?

5. Copy va --link

5.1 O'lchov

Kichik bazada farq deyarli yo'q: vaqtning ko'pi sxemani dump/restore qilishga ketdi. Katta bazada esa farq keskin: copy 500 GB ni nusxalaydi (soatlar), --link esa hajmdan qat'i nazar daqiqalarda tugaydi — fayllar ko'chirilmaydi, faqat yangi nom bilan bog'lanadi.

5.2 --link ning narxi

Hard link — bitta fayl, ikki nom. Yangi klaster ishga tushib, faylga yozishi bilan eski klaster uchun ham fayl o'zgaradi — eski klaster endi yaroqsiz. Shuning uchun:

• --link dan keyin eski klasterni ishga tushirmang (hujjat buni alohida ogohlantiradi).
• Orqaga qaytish yo'li — faqat zaxira. Demak --link dan oldin to'liq zaxira majburiy.
• Ikkala papka bitta fayl tizimida bo'lishi kerak (hard link boshqa diskka o'tmaydi).

Hujjatda uchinchi rejim ham bor — --clone (fayl tizimi qo'llasa, "copy-on-write" nusxa: tez va eski klaster ham saqlanadi) — kanonda sinalmagan.

5.3 Oxirida nima qoladi

pg_upgrade tugaganda shunday maslahat beradi:

Some statistics are not transferred by pg_upgrade.
Once you start the new server, consider running these two commands:
    /usr/lib/postgresql/18/bin/vacuumdb --all --analyze-in-stages --missing-stats-only
    /usr/lib/postgresql/18/bin/vacuumdb --all --analyze-only
Running this script will delete the old cluster's data files:
    ./delete_old_cluster.sh

Bu yerda PG 18 ning yana bir yangiligi bor. Oldingi versiyalarda pg_upgrade planner statistikasini (Statistika va planner) umuman ko'chirmas edi: yangilangan baza birinchi daqiqalarda "ko'r" ishlardi — reja noto'g'ri, so'rovlar sekin. PG 18 da statistika ko'chiriladi: kanon yangilangan bazada pg_stats da darhol 15 qatorni ko'rdi (vazifalar jadvali uchun). "Some statistics" — kengaytirilgan statistika kabi qismlar ko'chmaydi, shuning uchun --missing-stats-only faqat yo'qlarini yig'adi.

delete_old_cluster.sh — eski papkani o'chiradigan skript. Uni yangi klaster bir necha kun muammosiz ishlagandan keyin ishga tushiring.

5.4 Extension'lar

pg_upgrade extension'larni yangi versiyaga ko'chiradi, lekin ularning kutubxonalari yangi binarlar yonida bo'lishi kerak (--check dagi "required libraries" tekshiruvi). Kanonda pg_trgm 1.6, unaccent 1.1 va o'zbekcha qidiruv (Postgres'da full-text search) yangilangandan keyin ham ishladi (qidiruv ishlaydi: 200000).

Bizning klasterdagi ro'yxat — yangilashdan oldin shuni yozib qo'yish kerak:

SELECT extname, extversion
FROM pg_extension
ORDER BY extname;

Natija:

 extname  | extversion
----------+------------
 pg_trgm  | 1.6
 plpgsql  | 1.0
 unaccent | 1.1
(3 rows)

PostGIS kabi alohida o'rnatiladigan extension'lar bo'lsa (PostGIS va geo so'rovlar), ularning yangi Postgres versiyasi uchun paketi oldindan o'rnatilgan bo'lishi shart. Yangilangandan keyin extension versiyasini ko'tarish — ALTER EXTENSION … UPDATE.

6. Docker tuzog'i

6.1 Image tegini almashtirish — yangilash emas

Docker'da Postgres'ni ishlatganlar ko'pincha shunday qiladi: docker-compose.yml da postgres:17 ni postgres:18 ga o'zgartiradi va qayta ishga tushiradi. Bu major yangilash emas — 18 ning dasturi 17 ning fayllarini o'qiy olmaydi.

Kanon 17 ning volume'ini postgres:18 ga ulab ko'rdi. Avval 17 qo'llanmalaridagi yo'l bilan (-v …:/var/lib/postgresql/data):

Error: in 18+, these Docker images are configured to store database data in a
       format which is compatible with "pg_ctlcluster" (specifically, using
       major-version-specific directory names).  This better reflects how
       PostgreSQL itself works, and how upgrades are to be performed.
       See also https://github.com/docker-library/postgres/pull/1259
       Counter to that, there appears to be PostgreSQL data in:
         /var/lib/postgresql/data

Mazmuni: "18 dan boshlab bu image'lar ma'lumotni major versiya nomli papkada saqlaydi (/var/lib/postgresql/18/docker). Lekin /var/lib/postgresql/data da allaqachon PostgreSQL ma'lumoti bor ko'rinadi". Konteyner 1 kodi bilan to'xtadi. 18 yo'li bilan (-v …:/var/lib/postgresql) ulanganda ham xuddi shu xato chiqdi. Yaxshi tomoni: image jim bo'sh baza ochib, "ma'lumotlar yo'qoldi" degan vahima qo'zg'atmadi.

Bir chalg'ituvchi detal: parolsiz (trust sozlamasiz) urinishda xato boshqacha chiqdi — Database is uninitialized and superuser password is not specified. Bu xabar "baza bo'sh" degandek ko'rinadi, aslida esa muammo boshqa joyda. Birinchi chiqqan xatoga emas, to'liq log'ga qarang.

6.2 Docker'da to'g'ri yo'l

1. Eski konteyner ishlab turganda: pg_dumpall --globals-only va pg_dump -Fc (yoki 18 ning pg_dump i tarmoq orqali).
2. Yangi volume bilan postgres:18 konteyner (eski volume'ga tegmaymiz).
3. Rollar, keyin pg_restore -j N.
4. Tekshiruv, ilovani yangi konteynerga ulash.
5. Bir necha kundan keyin eski konteyner va volume'ni o'chirish.

Docker'da pg_upgrade ham mumkin (kanon shunday qildi), lekin bitta konteynerda ikki versiya binarlari kerak — bu qo'shimcha image yoki paket o'rnatish. Kichik va o'rta bazalar uchun dump/restore oddiyroq.

Volume va bind mount darsida ko'rgan buyruqdagi -v nom:/var/lib/postgresql aynan 18 image'larining yangi yo'li — kanon va kurs shuning uchun shu yo'lni ishlatadi.

7. 3-yo'l: logical replication (hujjat bo'yicha)

Juda katta va to'xtashga chidamaydigan bazalar uchun uchinchi yo'l bor — logical replication (mantiqiy replikatsiya): yangi 18 server eski 17 serverning o'zgarishlarini real vaqtda qabul qilib turadi. Ikkalasi sinxron bo'lgach, ilova bir necha soniyada yangisiga o'tkaziladi.

Narxi — murakkablik: sxema o'zgarishlari (DDL) replikatsiya qilinmaydi, sequence qiymatlari alohida ko'chiriladi, UPDATE va DELETE ko'chishi uchun har jadvalda birlamchi kalit (yoki REPLICA IDENTITY) kerak. Bu yo'l kanonda sinalmagan; mavzu 31-qismdagi Replikatsiya va read replica'lar darsida batafsil.

Uch yo'ldan qaysi birini tanlash — qisqacha:

flowchart TD
  S{"Boshqa mashina<br/>yoki OS?"} -->|ha| D["dump/restore"]
  S -->|yo'q| H{"Baza katta,<br/>to'xtash qisqa?"}
  H -->|yo'q| D
  H -->|ha| R{"Daqiqalar<br/>ham ko'pmi?"}
  R -->|yo'q| U["pg_upgrade --link<br/>+ zaxira"]
  R -->|ha| L["logical replication"]

8. Yangilash rejasi

Reliz izohlari muhim: masalan PG 18 da checksums sukut va pg_upgrade statistikasi o'zgardi — ikkalasi ham shu darsda bizga ta'sir qildi.

9. Ko'p uchraydigan xatolar

10. Mashqlar

Mashqlar kurs/mashqlar/27/17-yangilash/ da. 2-mashq holat 11 bazasida (biz ishga tushirdik, PostgreSQL 17.6), 3-mashq Node 24 da tekshirilgan.

1-mashq (oson): qaysi yo'l

• 17.5 → 17.6: yangilash, binarlarni almashtirish
• 16 → 18, boshqa serverga ko'chish bilan birga:
• 17 → 18, 2 TB baza, to'xtash 10 daqiqadan oshmasin: pg_upgrade --
• O'zgarishsiz faqat tekshirish: pg_upgrade --
• Eski klasterdagi checksums'ni yoqish: pg_ --enable

2-mashq (o'rta): statistikani tekshirish

Yangilangan (yoki tiklangan) bazada planner statistikasi bormi? vazifalar jadvali uchun pg_stats qatorlarini sanang, keyin ANALYZE vazifalar qiling va yana sanang. Nechta qator chiqdi va nega aynan shuncha?

ANALYZE vazifalar;
SELECT count(*) AS ustunlar
FROM pg_stats
WHERE schemaname = 'public' AND tablename = 'vazifalar';

ANALYZE
 ustunlar
----------
       15
(1 row)

3-mashq (qiyin): yangilash turi

yangilashTuri(eski, yangi) funksiyasini yozing. Kirish — SELECT version() matnining boshi, masalan "PostgreSQL 17.6 on x86_64-windows". Natija: "minor", "major", "bir xil" yoki "pastga" (eski versiyaga qaytish — Postgres buni yangilash vositalari bilan qo'llamaydi).

Ishora: versiyani /PostgreSQL (\d+)\.(\d+)/ muntazam ifodasi bilan ajrating (RegExp asoslari va metodlari) va Number ga aylantiring.

function versiya(matn) {
  const m = matn.match(/PostgreSQL (\d+)\.(\d+)/);
  if (m === null) throw new Error(`versiya topilmadi: ${matn}`);
  return { major: Number(m[1]), minor: Number(m[2]) };
}

function yangilashTuri(eski, yangi) {
  const a = versiya(eski);
  const b = versiya(yangi);
  if (b.major !== a.major) {
    return b.major > a.major ? "major" : "pastga";
  }
  if (b.minor === a.minor) return "bir xil";
  return b.minor > a.minor ? "minor" : "pastga";
}

console.log(yangilashTuri("PostgreSQL 17.6 on x86_64-windows",
  "PostgreSQL 18.6 (Debian 18.6-1.pgdg13+2)"));
console.log(yangilashTuri("PostgreSQL 17.5", "PostgreSQL 17.6"));
console.log(yangilashTuri("PostgreSQL 18.6", "PostgreSQL 17.11"));
console.log(yangilashTuri("PostgreSQL 9.6", "PostgreSQL 10.0"));

major
minor
pastga
major

11. Loyiha qadami: kanon tajribasi

Bu darsda vazifalar-api kodi o'zgarmaydi va commit yo'q. Ilova Postgres versiyasini bilmaydi: u faqat SQL yuboradi va DATABASE_URL ga ulanadi — shuning uchun yangilashdan keyin yagona tekshiruv ilova testlarini yangi serverda ishga tushirish. Kanon loyihasi boshidan PostgreSQL 18 da (postgres:18, 26-qism), testlari TEST_DATABASE_URL bilan istalgan serverda ishlaydi.

O'zingiz takrorlang (dump/restore yo'li, Docker'da, 17 → 18):

docker run -d --name sinov17 -e POSTGRES_HOST_AUTH_METHOD=trust \
  -v sinov17:/var/lib/postgresql/data postgres:17
docker exec sinov17 createdb -U postgres sinov
docker exec sinov17 psql -U postgres -d sinov \
  -c "CREATE TABLE t AS SELECT generate_series(1, 1000) AS n"
docker exec sinov17 pg_dump -U postgres -Fc -f /tmp/s.dump sinov
docker cp sinov17:/tmp/s.dump s.dump

Keyin kanon27-pg ga (18): docker cp s.dump kanon27-pg:/tmp/, createdb sinov, pg_restore -d sinov /tmp/s.dump va SELECT count(*) FROM t — 1 000. Oxirida docker rm -f sinov17 va docker volume rm sinov17. Bu yerda 17 ning pg_dump i ishlatildi — u 17 serverdan olingan dump; 18 ning pg_restore i uni o'qiy oladi (yangi versiya eski arxivni o'qiydi).

12. Real ishda

• Managed xizmatlarda (RDS, Neon) major yangilash — panelda bitta tugma, lekin ichida xuddi shu pg_upgrade yoki replikatsiya; to'xtash vaqti va extension mosligi baribir sizning tekshiruvingiz.
• Ko'p jamoalar har kuzgi major relizdan keyin bir-ikki minor versiyani kutib, keyin yangilaydi — birinchi chiqqan xatolar tuzatilsin.
• Intervyuda: "Postgres'ni major versiyaga qanday ko'tarasiz?", "pg_upgrade --link ning xavfi nima?", "Docker'da image tegini o'zgartirish yetarlimi?"

Xulosa

• Minor — binar almashtirish, kechiktirmang; major — fayl formatini o'tkazish.
• dump/restore — sekin, ishonchli, har qanday versiya va mashina; to'xtash hajmga bog'liq.
• pg_upgrade: avval --check; --link hajmdan qat'i nazar tez, lekin eski klaster yaroqsiz bo'ladi — zaxira majburiy.
• PG 18: initdb checksums yoqadi (mos kelmasa — --no-data-checksums), statistika ko'chiriladi.
• Docker'da teg almashtirish yangilash emas — yangi volume'ga dump/restore.

Keyingi dars: Managed va serverless Postgres — o'zingiz boshqarasizmi yoki xizmatga topshirasiz: narx, limitlar, zaxira kafolatlari va vendor lock-in.

Manbalar

• PostgreSQL 18 hujjati — Upgrading a PostgreSQL Cluster: https://www.postgresql.org/docs/18/upgrading.html
• pg_upgrade (--check, --link, --clone, statistika): https://www.postgresql.org/docs/18/pgupgrade.html
• initdb (--no-data-checksums), pg_checksums: https://www.postgresql.org/docs/18/app-initdb.html, https://www.postgresql.org/docs/18/app-pgchecksums.html
• PostgreSQL 18 reliz izohlari (checksums sukut, statistika ko'chirish): https://www.postgresql.org/docs/18/release-18.html
• Versiyalash siyosati (major/minor, qo'llab-quvvatlash muddati): https://www.postgresql.org/support/versioning/
• Docker Official Image o'zgarishi (PGDATA yo'li): https://github.com/docker-library/postgres/pull/1259
• O'qilgan sana — 2026-10-25. Kanon o'lchovi (IlmHamroh, 2026-10): image xatosi, dump/restore, --check, checksums, copy va --link, statistika, extension'lar; PostgreSQL 17.11 → 18.6. Biz ishga tushirdik (PostgreSQL 17.6, holat 11): data_checksums, extension ro'yxati, 2–3-mashqlar. Loyiha qadamidagi sinov17 buyruqlari — Docker'ni yoqmaganimiz uchun biz tomondan sinalmagan; kanondagi xuddi shunday ketma-ketlik o'tgan.