PostgreSQL’de Veritabanlarını Listeleme ve Aralarında Geçiş Yapma: Eksiksiz Teknik Kılavuz

PostgreSQL, her biri kendi şeması, rolleri ve ayrıcalıklarına sahip olan birden fazla izole veritabanını tek bir sunucu örneği içinde yönetir. Tüm veritabanlarını listelemek için l komutunu psql içinde çalıştırın ya da herhangi bir oturumdan SELECT datname FROM pg_catalog.pg_database; sorgusunu kullanın. Veritabanları arasında geçiş yapmak için yeni bir bağlantı açmanız gerekir — PostgreSQL, oturum içinde USE komutuna eşdeğer bir yapı olmaksızın katı oturum-veritabanı bağlamasını zorunlu kılar.

Bu kılavuz, ham psql komutları ve sistem katalog sorgularından bağlantı dizelerine, pg_hba.conf değerlendirmelerine ve üretim ortamlarında kullanılan çok veritabanlı iş akışı kalıplarına kadar PostgreSQL veritabanlarını listeleme ve bunlara bağlanmak için mevcut her yöntemi kapsamaktadır.

PostgreSQL Veritabanı Geçişinin Neden Farklı Çalıştığı

MySQL’den gelen çoğu geliştirici bir USE database_name; komutu bekler. PostgreSQL bunu kasıtlı olarak içermez. Her PostgreSQL oturumu, bağlantı kurulduğu anda tam olarak bir veritabanına bağlanır ve bu bağlama, oturumun ömrü boyunca değiştirilemez. Bu, PostgreSQL’in süreç modelinde köklü bir mimari karardır: arka uç süreç (postgres), başlangıçta veritabanının sistem kataloğunu paylaşılan belleğe yükler ve oturum ortasında katalog değiştirmek zaten tam bir süreç yeniden başlatması gerektirir.

Bu kısıtlamayı baştan anlamak, saatlerce süren hata ayıklamayı önler ve çok veritabanlı araçlar, bağlantı havuzları ve uygulama yapılandırmalarını nasıl tasarlayacağınızı şekillendirir.

PostgreSQL’de Tüm Veritabanlarını Listeleme

Yöntem 1: psql’de l Meta-Komutu

Veritabanlarını listelemenin en hızlı yolu, etkileşimli bir psql oturumu içindeki l meta-komutudur (takma adı: list).

psql -U postgres

Bağlandıktan sonra:

l

Bu, aşağıdakine benzer biçimlendirilmiş bir tablo üretir:

                                  List of databases
   Name    |  Owner   | Encoding |   Collate   |    Ctype    |   Access privileges
-----------+----------+----------+-------------+-------------+-----------------------
 myapp_db  | appuser  | UTF8     | en_US.UTF-8 | en_US.UTF-8 |
 analytics | analyst  | UTF8     | en_US.UTF-8 | en_US.UTF-8 | analyst=CTc/analyst
 postgres  | postgres | UTF8     | en_US.UTF-8 | en_US.UTF-8 |
 template0 | postgres | UTF8     | en_US.UTF-8 | en_US.UTF-8 | =c/postgres          +
           |          |          |             |             | postgres=CTc/postgres
 template1 | postgres | UTF8     | en_US.UTF-8 | en_US.UTF-8 |

Sütunlar yalnızca isimlerden fazlasını ortaya koyar: Encoding, sunucular arasında veri taşırken önemlidir; Collate, sıralama düzenini ve dizin davranışını etkiler; Access privileges ise PostgreSQL’in ACL gösterimini kullanır (C = CONNECT, T = TEMPORARY, c = CREATE).

Tablo alanı ve bağlantı sınırları dahil genişletilmiş ayrıntılar almak için şunu kullanın:

l+

Yöntem 2: pg_database Sistem Kataloğunu Sorgulama

Betik yazma, izleme veya uygulama düzeyinde iç gözlem için pg_catalog.pg_database görünümünü doğrudan sorgulayın. Sistem katalogları küresel olarak görünür olduğundan bu, kümedeki herhangi bir veritabanından çalışır.

SELECT
    datname        AS database_name,
    pg_catalog.pg_get_userbyid(datdba) AS owner,
    pg_encoding_to_char(encoding) AS encoding,
    datcollate     AS collation,
    datctype       AS ctype,
    datconnlimit   AS connection_limit,
    pg_catalog.pg_size_pretty(pg_catalog.pg_database_size(datname)) AS size
FROM pg_catalog.pg_database
WHERE datistemplate = false
ORDER BY datname;

datistemplate = false filtrelemesi, sonuçlardan template0 ve template1‘yi hariç tutar — bunlar işletimsel veritabanları değil, sistem şablonlarıdır. datconnlimit sütunu paylaşılan ortamlarda kritik öneme sahiptir: -1 değeri sınırsız anlamına gelirken, herhangi bir pozitif tam sayı o veritabanına eş zamanlı bağlantıları sınırlandırır.
Üretim ipucu: İzleme sorgularınıza pg_database_size() ekleyin. Tablo alanı kapasitesini sessizce aşan bir veritabanı, gerçekleştikten sonra teşhis edilmesi güç yazma hatalarının yaygın bir nedenidir.
Yöntem 3: psql’e Girmeden Veritabanlarını Listeleme
Kabuk betikleri ve otomasyon ardışık düzenleri için, etkileşimli bir oturuma girmeden veritabanı listesini alabilirsiniz:
psql -U postgres -c "l"
Ya da temiz, betikle ayrıştırılabilir çıktı için:
psql -U postgres -t -c "SELECT datname FROM pg_database WHERE datistemplate = false;"
-t bayrağı sütun başlıklarını ve satır sayılarını gizler, yalnızca ham değerleri döndürür — grep, awk veya Bash dizilerine aktarmak için idealdir.
Listeyi bir dosyaya aktarmak için:
psql -U postgres -t -A -c "SELECT datname FROM pg_database WHERE datistemplate = false;" > db_list.txt
-A sütun hizalamasını devre dışı bırakır ve her satırda bir veritabanı adı üretir.
PostgreSQL’de Veritabanları Arasında Geçiş Yapma
Canlı bir oturum içinde veritabanı değiştiremediğinizden, doğru yaklaşım mevcut bağlantıyı sonlandırmak ve istenen veritabanını hedefleyen yeni bir bağlantı kurmaktır. Bunu verimli şekilde yapmanın birkaç yolu vardır.
Yöntem 1: Kabuktan Çıkıp Yeniden Bağlanma
psql içinde mevcut oturumdan çıkın:
q
Ardından hedef veritabanına bağlanın:
psql -U postgres -d target_database
Yöntem 2: psql İçinde c (Connect) Kullanma
Bu, etkileşimli çalışma için en pratik yöntemdir. c meta-komutu, mevcut bağlantıyı kapatır ve aynı terminal oturumu içinde belirtilen veritabanına yeni bir bağlantı açar.
c target_database
Aynı anda kullanıcı ve ana bilgisayar da değiştirebilirsiniz:
c target_database admin_user localhost 5432
Sözdizimi: c [database [username [host [port]]]]

c komutunu çalıştırdığınızda, psql bir onay mesajı gösterir:

You are now connected to database "target_database" as user "postgres".

Önemli uç durum: Hedef veritabanı mevcut değilse veya mevcut kullanıcının CONNECT ayrıcalığı yoksa, c başarısız olur ve sizi önceki bağlantıya geri döndürür. Bu, kulağa geldiğinden daha güvenlidir — bağlantısız kalmazsınız, ancak betiklerde çıkış durumunu kontrol ederek bunu ele almanız gerekir.

Yöntem 3: Farklı Bir Kullanıcı Olarak Bağlanma

Belirli bir rol altında bir veritabanına bağlanmak için:

psql -d myapp_db -U appuser -h localhost -p 5432

Ya da mevcut bir oturum içinde c kısayolunu kullanarak:

c myapp_db appuser

Bu, satır düzeyinde güvenlik (RLS) politikalarını test ederken veya uygulama kullanıcılarının kendi şemaları dışındaki tablolara erişemediğini doğrularken özellikle kullanışlıdır.

Yöntem 4: Bağlantı Dizeleri Kullanma (URI Formatı)

PostgreSQL, tüm bağlantı parametrelerini tek bir dizeye kapsayan libpq bağlantı URI formatını destekler. Bu, uygulama yapılandırması, CI/CD ardışık düzenleri ve altyapı-kod araçları için tercih edilen yöntemdir.

psql "postgresql://appuser:password@localhost:5432/myapp_db"

Ya da postgres:// şemasını kullanarak (her ikisi de geçerlidir):

psql "postgres://appuser:password@db.example.com:5432/analytics?sslmode=require"

?sslmode=require parametresi bağlantıda TLS şifrelemesini zorunlu kılar — localhost dışına açık herhangi bir veritabanı için vazgeçilmez bir gerekliliktir. PostgreSQL’i bir VPS veya dedicated sunucu üzerinde barındırıyorsanız, bağlantı dizelerini her zaman sslmode=require veya sslmode=verify-full ile ve geçerli bir SSL sertifikası ile eşleştirin.

Dikkat edilmesi gereken bağlantı URI parametreleri:

Yöntem 5: Ortam Değişkenleriyle psql Kullanma

Aynı kümeye tekrarlanan bağlantılar için, kimlik bilgilerini defalarca yazmaktan kaçınmak amacıyla ortam değişkenlerini ayarlayın:

export PGHOST=localhost
export PGPORT=5432
export PGUSER=postgres
export PGPASSWORD=secret   # Use .pgpass file in production instead
export PGDATABASE=myapp_db

psql

Üretimde, kimlik bilgilerini kabuk geçmişinde veya süreç listelerinde açığa çıkarmamak için PGPASSWORD yerine bir .pgpass dosyası kullanın:

# ~/.pgpass format: hostname:port:database:username:password
localhost:5432:myapp_db:appuser:strongpassword

İzinleri doğru ayarlayın, aksi takdirde PostgreSQL dosyayı yok sayar:

chmod 600 ~/.pgpass

Karşılaştırma: Veritabanı Geçiş Yöntemleri

Birden Fazla Veritabanı Bağlantısını Verimli Şekilde Yönetme

GUI Tabanlı Gezinme için pgAdmin Kullanma

pgAdmin, sol taraftaki nesne ağacında kayıtlı her sunucu altındaki tüm veritabanlarını listeler. Bir veritabanına tıklayıp Sorgu Aracı’nı açmak, tüm sorguları otomatik olarak o veritabanına kapsar. Bu, keşif çalışmaları için kullanışlıdır ancak otomasyon için uygun değildir.

Tuzak: pgAdmin, veritabanı başına ayrı bağlantı yuvaları tutar. PostgreSQL sunucunuzun düşük bir max_connections ayarı varsa (varsayılan 100’dür), pgAdmin’de çok sayıda veritabanı açmak, uygulamanız başlamadan önce bağlantı havuzunu tüketebilir.

Bağlantı Havuzlama için PgBouncer Kullanma

Sık veritabanı geçişi yapılan üretim ortamlarında, PgBouncer gibi bir bağlantı havuzlayıcı yükü önemli ölçüde azaltır. PgBouncer üç modda çalışır:

• Oturum modu: İstemci oturumu başına bir sunucu bağlantısı. İşlevsel olarak doğrudan bağlantılara eşdeğerdir.
• İşlem modu: Sunucu bağlantısı yalnızca bir işlem süresince tutulur. OLTP iş yükleri için en verimli seçenektir.
• Deyim modu: Her deyimden sonra bağlantı serbest bırakılır. Çok deyimli işlemlerle uyumsuzdur.

Tek bir PostgreSQL örneği üzerinde birden fazla uygulama veritabanı çalıştırırken — VPS hosting veya cPanel’li VPS üzerinde yaygın bir kalıp — işlem modundaki PgBouncer, aktif arka uç süreçlerini büyük ölçüde azaltabilir.

dblink ve postgres_fdw ile Çapraz Veritabanı Sorguları

Oturumlar veritabanı kapsamlı olduğundan, veritabanları arasında veri sorgulamak bir uzantı gerektirir. PostgreSQL iki seçenek sunar:

dblink — eski, prosedürel yaklaşım:

SELECT * FROM dblink(
    'dbname=analytics user=analyst host=localhost',
    'SELECT user_id, event_count FROM events WHERE date = current_date'
) AS remote(user_id INT, event_count BIGINT);

postgres_fdw — modern, standartlara uygun Yabancı Veri Sarmalayıcısı:

CREATE EXTENSION postgres_fdw;

CREATE SERVER analytics_server
    FOREIGN DATA WRAPPER postgres_fdw
    OPTIONS (host 'localhost', dbname 'analytics', port '5432');

CREATE USER MAPPING FOR appuser
    SERVER analytics_server
    OPTIONS (user 'analyst', password 'secret');

CREATE FOREIGN TABLE remote_events (
    user_id INT,
    event_count BIGINT
)
SERVER analytics_server
OPTIONS (schema_name 'public', table_name 'events');

Kurulumdan sonra remote_events, yerel bir tablo gibi davranır. postgres_fdw, yüklem aktarımını destekler; yani WHERE yan tümceleri yerel olarak değil, uzak sunucuda yürütülür — bu, büyük veri kümeleri için kritik bir performans farkıdır.

Sistem Veritabanları: Dokunmamanız Gerekenler

PostgreSQL, her yeni kümede dört veritabanıyla birlikte gelir:

template1, şablon belirtmeden CREATE DATABASE çalıştırdığınızda kopyalanır. template1‘e uzantı yükler veya şema oluşturursanız, her yeni veritabanı bunları devralır. Bu, ortamları standartlaştırmak için kullanışlıdır ancak yanlışlıkla yapılırsa tehlikelidir.

template0, bozulmamış bir yedek olarak mevcuttur. Farklı bir kodlama veya yerel ayarla bir pg_dump arşivi geri yüklerken kullanılabilecek tek şablondur; çünkü çakışabilecek kullanıcı tarafından oluşturulmuş nesneler içermez.

Ayrıcalıklar, pg_hba.conf ve Bağlantı Hataları

Veritabanları arasında geçiş yaparken yaygın bir karışıklık kaynağı, PostgreSQL rol düzeyindeki ayrıcalıklar ile pg_hba.conf kimlik doğrulama kuralları arasındaki farktır. Her ikisinin de bağlantıya bağımsız olarak izin vermesi gerekir.

Rol düzeyinde kontrol: Rolün hedef veritabanında CONNECT ayrıcalığına sahip olması gerekir:

GRANT CONNECT ON DATABASE target_database TO appuser;

pg_hba.conf kontrolü: Ana bilgisayar tabanlı kimlik doğrulama dosyası (Debian/Ubuntu’da /etc/postgresql/15/main/pg_hba.conf), kullanıcı, veritabanı ve kaynak adres için eşleşen bir kural içermelidir. Tipik bir giriş:

# TYPE  DATABASE        USER            ADDRESS                 METHOD
host    myapp_db        appuser         10.0.0.0/8              scram-sha-256

pg_hba.conf dosyasını düzenledikten sonra, sunucuyu yeniden başlatmadan yapılandırmayı yeniden yükleyin:

sudo systemctl reload postgresql

Ya da psql içinden:

SELECT pg_reload_conf();

Yaygın hata kalıbı: Bir kullanıcının SQL düzeyinde CONNECT ayrıcalığı vardır ancak pg_hba.conf dosyasında eşleşen bir kural yoktur. Hata mesajı (FATAL: no pg_hba.conf entry for host) açıktır, ancak geliştiriciler genellikle veritabanı izinlerinin yalnızca SQL aracılığıyla yönetilmesini beklediklerinden dosyayı tamamen gözden kaçırır.

Pratik Karar Matrisi

Senaryonuz için doğru bağlantı yaklaşımını seçmek amacıyla bu kontrol listesini kullanın:

• Yerel geliştirme makinesinde etkileşimli keşif: psql içinde c dbname kullanın. Hızlı, yeni süreç gerektirmez.
• Birden fazla veritabanı üzerinde yineleme yapan kabuk betiği: Temiz çıktı için -t -A ile bir döngüde psql -U postgres -d $dbname -c "..." kullanın.
• Tek bir veritabanına bağlanan uygulama: sslmode=require ile bir bağlantı URI’si ve bir bağlantı havuzu (PgBouncer veya yerleşik sürücü havuzlama) kullanın.
• İki veritabanından veri gerektiren uygulama: Uygulama kodunda iki ayrı bağlantı havuzu yönetmek yerine birincil veritabanında postgres_fdw uygulayın.
• RLS veya ayrıcalık izolasyonunu doğrulama: psql‘dan çıkmadan hedef rolü taklit etmek için c dbname role_name kullanın.
• Otomatik sağlama / altyapı-kod: Bir hizmet hesabıyla ortam değişkenleri veya .pgpass kullanın; betiklere asla kimlik bilgilerini sabit kodlamayın.
• Yüksek eş zamanlılıklı üretim iş yükü: Uygulama ile PostgreSQL arasına işlem modunda PgBouncer dağıtın. Bir dedicated sunucu üzerinde, donanımınızın bellek kapasitesine uyacak şekilde postgresql.conf içindeki max_connections‘yi ayarlayın (her arka uç yaklaşık 5–10 MB RAM kullanır).
• Kiracı başına veritabanı kullanan çok kiracılı SaaS: Bağlantı havuzu parçalanmasını önlemek ve yedekleme stratejilerini basitleştirmek için kiracı başına veritabanı yerine tek bir veritabanı içinde şema tabanlı çok kiracılılığı değerlendirin.

PostgreSQL’i web uygulamalarıyla birlikte çalıştıran ekipler için, veritabanı sunucusunu düzgün yapılandırılmış bir paylaşımlı hosting veya VPS ortamı ve uygulama katmanı için kayıtlı bir alan adı ile eşleştirmek standart üretim yığınını tamamlar.

SSS

psql oturumumu kapatmadan veritabanı değiştirebilir miyim?

Evet. psql içinde c target_database meta-komutunu kullanın. Mevcut arka uç bağlantısını kapatır ve aynı terminal oturumu içinde belirtilen veritabanına yeni bir bağlantı açar. Aynı komutta isteğe bağlı olarak farklı bir kullanıcı, ana bilgisayar ve port belirtebilirsiniz.

PostgreSQL neden MySQL gibi bir USE komutuna sahip değil?

PostgreSQL’in mimarisi, bir arka uç sürecini başlangıçta tek bir veritabanına bağlar. Veritabanının sistem kataloğu, o süreç için paylaşılan belleğe yüklenir ve oturum ortasında katalog değiştirmek mimari olarak yeni bir süreç başlatmaya eşdeğerdir. psql‘deki c komutu pratik eşdeğeridir — yalnızca süreç yeniden başlatmayı kullanıcı için şeffaf hale getirir.

İki farklı PostgreSQL veritabanından aynı anda veri nasıl sorgularım?

Uzak veritabanına eşlenen bir yabancı sunucu ve yabancı tablolar oluşturmak için postgres_fdw uzantısını kullanın. Kurulumdan sonra yerel ve uzak tabloları tek bir sorguda JOIN ile birleştirebilirsiniz. Tek seferlik sorgular için dblink daha basittir ancak daha az performanslıdır ve bakımı daha zordur.

template1‘e bağlanıp değiştirirsem ne olur?

template1‘de oluşturduğunuz nesneler — tablolar, uzantılar, şemalar — CREATE DATABASE ile oluşturulan her yeni veritabanına kopyalanır (TEMPLATE template0 açıkça belirtilmediği sürece). Bu bazen kasıtlıdır (örneğin, uuid-ossp veya pgcrypto‘yi önceden yüklemek), ancak yanlışlıkla yapılan değişiklikler sonradan oluşturulan tüm veritabanlarını bozabilir.

Mevcut psql oturumunun hangi veritabanına bağlı olduğunu nasıl öğrenirim?

psql içinde şunu çalıştırın:

SELECT current_database();

Ya da psql istemine bakın — varsayılan olarak dbname=# (süper kullanıcı) veya dbname=> (normal kullanıcı) şeklinde görüntülenir; burada dbname aktif veritabanıdır.