FibaCloud
İçeriğe geç
Soru sor

Kapatmak için ESC tuşuna basın

Ubuntu 24.04: PostgreSQL 16 Kurulumu ve Optimizasyonu

Bu rehber, yeni bir Ubuntu 24.04 LTS sunucusunda PostgreSQL 16 kurulumunu ve aynı sunucuda çalışan bir uygulamanın bağlantısını ele alır. Uygulama için sınırlı bir hesap oluşturur, yanlış parola ve yetkisiz işlem denemelerini kontrol eder, ardından yedeği ayrı bir veritabanına geri yükleriz. Son bölümde performans ayarlarını ölçerek değiştirme yöntemi vardır.

Mevcut veritabanını yükseltme, CentOS/RHEL kurulumu, yüksek erişilebilirlik ve başka sunuculardan bağlantı bu rehberin kapsamı dışındadır. Bu durumlarda mevcut veriye dokunmadan ürünün ilgili sürüm belgelerini ve bir geçiş planını kullanın.

Doğrulama — 20 Eylül 2026: Ubuntu 24.04 ortamında PostgreSQL 16.15 ile SQL adımları, TCP üzerinden SCRAM parola kontrolü, yetki retleri, yedek geri yükleme ve pg_ctlcluster ile yeniden başlatma denendi. İzole ortamda systemctl ve AppArmor entegrasyonu uçtan uca sınanmadığından, servis ve işletim sistemi güvenlik kontrollerini hedef sunucunuzda ayrıca yapın.

1. Ön koşullar ve sürüm kontrolü

Sudo yetkili bir Linux hesabı, yeterli disk alanı ve güncel Ubuntu paket kaynakları gerekir. Komutlar tek bir PostgreSQL 16 main kümesini ve 5432 numaralı yerel portu varsayar. Mevcut servis bulunan bir sunucuda önce veri yedeğini ve geri yükleme planını doğrulayın; farklı küme veya sürüm varsa aşağıdaki adımları doğrudan uygulamayın.

cat /etc/os-release
df -h /var/lib

Disk kontrolü varsayılan veri dizininin yerleşeceği /var/lib dosya sistemini gösterir. İşletim sistemi Ubuntu 24.04 olmalıdır. Dağıtımın PostgreSQL 16 paketini açık sürüm adıyla kurun; bu işlem büyük sürüm yükseltmesi yapma talimatı değildir.

sudo apt update
apt-cache policy postgresql-16
sudo apt install postgresql-16 postgresql-client-16
pg_lsclusters

Ubuntu paketleri normal yeni kurulumda 16 main kümesini oluşturur. Çıktıda bu kümenin veri dizinini, portunu ve durumunu kontrol edin. Küme yoksa veya başka sürüm/port görünüyorsa durun ve paket kurulum günlüğünü inceleyin. Var olan veri dizininde initdb çalıştırmayın ve kümeyi silip yeniden oluşturmayın.

sudo systemctl start postgresql@16-main
sudo systemctl is-active postgresql@16-main
sudo -u postgres psql -X -p 5432 -d postgres -c 'SELECT version();'

is-active çıktısı active, sunucu sürümü 16.x olmalıdır. postgresql.service üst birimi tek başına gerçek kümenin sağlıklı olduğunu kanıtlamaz; SQL bağlantısını da doğrulayın. Paket depolarının sunduğu güncel 16.x güvenlik düzeltmelerini bakım politikanıza göre uygulayın.

2. Yerel erişimi ve kimlik doğrulamayı kontrol edin

PostgreSQL yöneticisi olarak yerel Unix soketinden bağlanın. Bu bağlantı için Linux postgres hesabının peer kimlik doğrulaması kullanılır; uygulamaya bu hesabı vermeyeceğiz.

sudo -u postgres psql -X -p 5432 -d postgres
SHOW listen_addresses;
SHOW port;
SHOW password_encryption;
SHOW config_file;
SHOW hba_file;
SELECT line_number, type, database, user_name, address, auth_method, error
FROM pg_hba_file_rules
ORDER BY line_number;

Yeni Ubuntu kurulumunda beklenen değerler localhost, 5432 ve scram-sha-256 şeklindedir. Kurallarda error alanı boş olmalı; yerel yönetim için peer, loopback TCP bağlantıları için scram-sha-256 kullanılmalıdır. pg_hba.conf ilk eşleşen kuralı uygular: daha önceki bir trust satırını gözden kaçırmayın.

Aşağıdaki satırlar beklenen kural türlerini gösterir; tüm dosyanın yerine yapıştırılacak bir yapılandırma değildir.

local   all   postgres                         peer
host    all   all       127.0.0.1/32            scram-sha-256
host    all   all       ::1/128                 scram-sha-256

Değerler farklıysa yeni hesap oluşturmadan önce nedenini belirleyin. Bu yerel kurulum için listen_addresses='*', herkese açık 5432 veya trust kimlik doğrulaması gerekmez. Dosya değişikliği gerekiyorsa önce mevcut dosyanın izinlerini koruyan bir yedeğini alın; yalnız gerekli satırları düzenleyin ve sözdizimini tekrar kontrol edin. HBA değişiklikleri reload, listen_addresses değişikliği servis restart gerektirir. Uzaktan erişim gerekiyorsa özel ağ, dar kaynak IP kuralları ve doğrulanmış TLS içeren ayrı bir tasarım kullanın.

Sahiplik ile uygulama erişimini ayırın
Sahiplik ile uygulama erişimini ayırın Veritabanı sahibi ile çalışma hesabı farklı roller üstlenir. SCRAM kimlik doğrulaması yetki sınırının yerine geçmez; ağ erişimi, rol izinleri ve geri yükleme testi ayrıca doğrulanır.
Görselin adım adım açıklaması
  1. Ayır: Sahiplik ve çalışma rollerini ayır.
  2. Doğrula: SCRAM ile kimlik doğrulamayı yapılandır.
  3. Sınırla: Ağ ve nesne izinlerini birlikte denetle.
  4. Geri yükle: Yedeği ayrı veritabanında test et.

3. Uygulama hesabını veri sahibi rolünden ayırın

Aşağıdaki adlar örnektir ve yeni kurulumda henüz bulunmamalıdır: fc_app_owner, fc_app, fc_appdb. Hata çıkarsa komutları tekrar tekrar çalıştırmayın; çakışan mevcut nesneyi inceleyin. ON_ERROR_STOP hata halinde kalan betiğin sürmesini önler.

Yönetici psql oturumunda çalıştırın. \password parolayı görünmeden sorar; güçlü ve benzersiz bir parola üretin. Parolayı SQL metnine veya kabuk komut satırına yazmayın.

\set ON_ERROR_STOP on
CREATE ROLE fc_app_owner NOLOGIN;
CREATE ROLE fc_app LOGIN NOSUPERUSER NOCREATEDB NOCREATEROLE NOREPLICATION;
\password fc_app
CREATE DATABASE fc_appdb OWNER fc_app_owner;
\connect fc_appdb
REVOKE ALL ON DATABASE fc_appdb FROM PUBLIC;
GRANT CONNECT ON DATABASE fc_appdb TO fc_app;
REVOKE CREATE ON SCHEMA public FROM PUBLIC;
SET ROLE fc_app_owner;
CREATE SCHEMA app AUTHORIZATION fc_app_owner;
CREATE TABLE app.healthcheck (
    id bigint GENERATED ALWAYS AS IDENTITY PRIMARY KEY,
    message text NOT NULL
);
INSERT INTO app.healthcheck (message) VALUES ('ilk kontrol');
GRANT USAGE ON SCHEMA app TO fc_app;
GRANT SELECT, INSERT, UPDATE, DELETE ON ALL TABLES IN SCHEMA app TO fc_app;
GRANT USAGE, SELECT ON ALL SEQUENCES IN SCHEMA app TO fc_app;
ALTER DEFAULT PRIVILEGES FOR ROLE fc_app_owner IN SCHEMA app
    GRANT SELECT, INSERT, UPDATE, DELETE ON TABLES TO fc_app;
ALTER DEFAULT PRIVILEGES FOR ROLE fc_app_owner IN SCHEMA app
    GRANT USAGE, SELECT ON SEQUENCES TO fc_app;
RESET ROLE;
\quit

fc_app uygulamanın veri okuma/yazma hesabıdır; superuser değildir, rol veya veritabanı oluşturamaz ve tablo sahibi değildir. Şema değişiklikleri ayrı yetkili bakım oturumunda fc_app_owner rolüyle yapılır. Varsayılan yetkiler yalnız bu rolün app şemasında daha sonra oluşturacağı nesnelere uygulanır; farklı bir sahip rolüyle oluşturulan tabloları otomatik kapsamaz.

4. Başarılı ve reddedilmesi gereken bağlantıları deneyin

Normal Linux hesabınızdan TCP loopback bağlantısı açın. -W parolayı etkileşimli sorar; -h 127.0.0.1 sayesinde peer yerine parola doğrulamasını denemiş oluruz.

psql -X -h 127.0.0.1 -p 5432 -U fc_app -d fc_appdb -W
SELECT current_user, current_database();
SELECT * FROM app.healthcheck ORDER BY id;
INSERT INTO app.healthcheck (message) VALUES ('uygulama bağlantısı başarılı');
SELECT * FROM app.healthcheck ORDER BY id;

Kullanıcı fc_app, veritabanı fc_appdb ve iki satır beklenir. Ardından aşağıdaki iki komutu ayrı ayrı deneyin. İkisi de yetki hatası vermelidir; başarılı olursa kurulumu tamamlanmış saymayın.

CREATE TABLE app.must_not_exist (id integer);
CREATE ROLE fc_must_not_exist;

Oturumdan \quit ile çıkın. Aynı bağlantıyı tekrar açıp bilerek yanlış parola girin: password authentication failed beklenir. Bu testin başarısız olması, doğru parolanın başarısı kadar önemlidir. Uygulamanızın bağlantı ayarlarında kendi hesabını kullanın; postgres parolasını uygulamaya taşımayın.

5. Yedeği alın ve ayrı veritabanına geri yükleyin

Yedeğin alınmış olması geri yüklenebildiğini kanıtlamaz. Aşağıdaki örnek, veri kaynağını değiştirmeden yeni fc_restore_check veritabanına dönüşü sınar. Bu adlar ve yedek dosyaları önceden bulunuyorsa farklı, açıkça belirlenmiş bir test adı seçin.

sudo install -d -o postgres -g postgres -m 700 /var/lib/postgresql/fc-backups
sudo -u postgres sh -c 'umask 077; test ! -e /var/lib/postgresql/fc-backups/fc_appdb.dump && pg_dump -p 5432 -Fc -f /var/lib/postgresql/fc-backups/fc_appdb.dump fc_appdb'
sudo -u postgres pg_restore --list /var/lib/postgresql/fc-backups/fc_appdb.dump
sudo -u postgres createdb -p 5432 -T template0 -O fc_app_owner fc_restore_check
sudo -u postgres pg_restore -p 5432 --exit-on-error --single-transaction -d fc_restore_check /var/lib/postgresql/fc-backups/fc_appdb.dump
sudo -u postgres psql -X -p 5432 -d fc_restore_check -c 'SELECT * FROM app.healthcheck ORDER BY id;'

Komutlar hatasız tamamlanmalı ve geri yüklenen tabloda önceki iki satır görünmelidir. --single-transaction ile geri yüklemedeki hata yarım veri bırakmadan işlemi geri alır. Var olan uygulama veritabanına --clean ile yazarak test yapmayın. Örnekte aynı kümedeki roller zaten vardır; başka sunucuya dönüşte sahip ve yetki rollerini önceden güvenle oluşturmak gerekir.

pg_dump tek veritabanını yedekler; küme rollerini ve yapılandırma dosyalarını içermez. Roller için ayrıca korumalı bir çıktı alın:

sudo -u postgres sh -c 'umask 077; test ! -e /var/lib/postgresql/fc-backups/globals.sql && pg_dumpall -p 5432 --globals-only -f /var/lib/postgresql/fc-backups/globals.sql'

Bu dosya parola özetleri ve yetkiler içerebilir. Yedekleri şifreli biçimde sunucu dışına kopyalayın; erişim, saklama süresi ve düzenli geri yükleme denemesini planlayın. Yapılandırma dosyalarını da izinlerini koruyarak ayrı yedekleyin. Aynı diskteki örnek dosyalar disk kaybına karşı koruma sağlamaz. Sürekli arşivleme/PITR ve kesinti hedefleri için PostgreSQL’in WAL yedekleme belgelerini izleyin. Kaynağı güvenilmeyen SQL veya dump dosyasını yönetici olarak geri yüklemeyin.

Test veritabanını kaldırmak isterseniz önce adını ve içeriğini tekrar doğrulayın; uygulama veritabanına yönelik silme komutu bu rehberde yoktur.

6. Performansı ölçerek iyileştirin

Her sunucuya aynı shared_buffers, work_mem veya max_connections değerini vermek doğru değildir. Önce normal yük altında gecikme, aktif bağlantı, RAM ve disk kullanımını kaydedin. Mevcut ayarları görmek için yönetici oturumunda:

SELECT name, setting, unit, context, pending_restart
FROM pg_settings
WHERE name IN ('shared_buffers', 'work_mem', 'maintenance_work_mem',
               'effective_cache_size', 'max_connections', 'autovacuum')
ORDER BY name;
SELECT datname, numbackends, xact_commit, xact_rollback, deadlocks
FROM pg_stat_database
WHERE datname = 'fc_appdb';
  • Yavaş sorgunun planını önce EXPLAIN ile inceleyin; EXPLAIN ANALYZE sorguyu gerçekten çalıştırır. Veri değiştiren sorgularda üretim üzerinde deneme yapmayın.
  • İndeksleri gerçek filtre ve sıralama ihtiyacına göre ekleyin. Yazma maliyeti ve disk kullanımını da ölçün; her sütuna indeks eklemek çözüm değildir.
  • work_mem tüm sunucu için tek bellek havuzu değildir: aynı anda birçok sorgu ve işlem düğümü bu belleği kullanabilir. Artışı eşzamanlı yükle sınayın.
  • max_connections değerini yükseltmeden önce bağlantı havuzu ve uygulamanın bağlantıları kapatmasını inceleyin.
  • Autovacuum’u açık tutun. Disk doluluğu, uzun işlemler ve eski satır birikimi için izleme kurun; fsync veya full_page_writes kapatarak hız elde etmeye çalışmayın.

Tek seferde tek değişiklik yapın; eski değeri ve dosya yedeğini kaydedin. context ve pending_restart alanlarına göre reload veya planlı restart uygulayın. Sonra aynı yükü tekrar ölçün. Gecikme, hata veya bellek kullanımı kötüleşirse önceki ayara dönün. Bu rehber belirli bir donanım için performans artışı garantisi vermez.

7. Hata giderme ve tamamlanma kontrolü

pg_lsclusters
sudo journalctl -u postgresql@16-main --since '15 minutes ago' --no-pager
sudo -u postgres psql -X -p 5432 -d postgres -c 'SELECT pg_is_in_recovery();'

Yeni bağımsız sunucuda pg_is_in_recovery() değeri false olmalıdır. Servis başlamıyorsa yanlış sürüm, port çakışması, izin, disk veya yapılandırma hatasını günlüklerden belirleyin; veri dizinini silmek hata giderme adımı değildir. HBA değişikliğinden sonra bağlantı kesildiyse açık yerel yönetim oturumundan önceki dosyayı geri getirin ve reload edin. Parola hatasını trust açarak çözmeyin.

Bakım penceresinde kontrollü bir küme restart’ından sonra doğru/yanlış parola, uygulama okuma/yazma ve sınırlı yetki kontrollerini tekrarlayın. Kurulumu; yerel dinleme, SCRAM doğrulaması, sınırlı uygulama hesabı, hatasız geri yükleme ve izleme birlikte doğrulandığında tamamlanmış kabul edin.

Resmî kaynaklar

Bir yanıt yazın

E-posta adresiniz yayınlanmayacak. Gerekli alanlar * ile işaretlenmişlerdir