PostgreSQL kurulumu, bir uygulamanın veri katmanını hazırlamak için iyi bir başlangıçtır. Fakat paketin kurulması; kullanıcı yetkilerinin doğru olduğu, bağlantıların güvenli gerçekleştiği veya verinin geri getirilebildiği anlamına gelmez. Veritabanını bir servis olarak düşünmek, kurulum ile sonraki işletim arasında kopukluk oluşmasını önler.
Bu rehber Ubuntu Server 24.04 LTS üzerinde dağıtımın APT paketini kullanarak yerel bağlantı için başlangıç kurulumu anlatır. Kurulacak ana sürüm, etkin paket kaynaklarına bağlıdır; komut çıktısıyla doğrulayın. Başka bir ana sürüme ihtiyaç varsa desteklenen resmî paket yaklaşımı ayrıca planlanmalıdır. Mevcut veritabanının ana sürüm yükseltmesi bu rehberin kapsamı değildir.
1. Disk, yedek ve kullanıcı ihtiyacını belirleyin
Veri hacminin bugün ne kadar olduğu kadar büyüme düzeni de önemlidir. Veritabanı dosyaları, loglar ve yedekler için kapasite planlayın. Aynı disk üzerindeki ikinci dosya tek başına felaket kurtarma kopyası değildir. Yedeklerin nerede tutulacağı ve kimlerin silebileceği kurulum tasarımında yer almalıdır.
Uygulama hangi veritabanına, hangi yetkiyle bağlanacak? Raporlama veya entegrasyon ayrı hesap gerektiriyor mu? Bu soruların cevabını yalnızca uygulama geliştiricisinin ilk bağlantı denemesine bırakmayın. Veritabanı yöneticisi hesabını bütün uygulamalara ortak vermek, sonradan erişimi ve değişiklikleri izlemeyi zorlaştırır.
2. Paketi kurun ve gerçek cluster durumunu inceleyin
Ubuntu PostgreSQL kurulum dokümanı, dağıtım paketini ve temel kimlik doğrulama düzenini açıklar. Aşağıdaki komutlar temiz bir laboratuvar içindir. Önceki kurulum veya farklı bir paket deposu varsa mevcut cluster'ları değiştirmeden inceleyin.
sudo apt update
sudo apt install postgresql postgresql-client
pg_lsclusters
sudo -u postgres psql -c "SELECT version();"
Ubuntu'da üst düzey hizmetin görünümüyle belirli cluster'ın durumu farklı olabilir. pg_lsclusters çıktısında sürüm, ad, port ve durum bilgisini kontrol edin. Çalışmayan cluster için yalnızca genel hizmeti tekrar başlatmak yerine ilgili günlük ve yapılandırma yolunu inceleyin.
3. Uygulamaya ayrı rol ve veritabanı oluşturun
Aşağıdaki akış önce postgres sistem hesabı üzerinden yönetim oturumu açar. SQL komutları bu oturumda yürütülür. Örnekte app_user ve appdb adları kullanılır; mevcut bir üretim hesabını değiştirmek amacıyla uygulanmaz.
sudo -u postgres psql
CREATE ROLE app_user LOGIN;
CREATE DATABASE appdb OWNER app_user;
psql içinde aşağıdaki meta komutla parolayı etkileşimli belirleyin. Gerçek parolayı kabuk geçmişine, örnek dosyaya veya destek kaydına açık metin eklemeyin. Ardından oturumdan çıkın.
\password app_user
\q
Uygulama hesabına superuser vermek yerine gerçekten gereken kapsamı tanımlayın. Şema sahipliği ve nesne yetkileri uygulamanın çalışma biçimine göre düzenlenebilir. Bir uygulamanın kendi veritabanında nesne oluşturmasıyla başka uygulamaların verilerine erişmesi aynı ihtiyaç değildir.
4. Önce yerel TCP bağlantısını test edin
Yerel sistem hesabıyla başarılı bağlantı, uygulamanın kendi kimliğiyle bağlanabildiğini kanıtlamaz. Uygulama hesabını hedef veritabanı ve bağlantı yöntemiyle sınayın. Parola gerekli olduğunda istemci etkileşimli olarak sorabilir.
psql -h 127.0.0.1 -U app_user -d appdb -W
Test oturumunda mevcut kullanıcı ve veritabanı bilgisini kontrol edin. Gerekirse izin verilen test nesnesi üzerinde okuma-yazma davranışını sınayın. Başarısız bağlantıda hata mesajının kimlik doğrulama, ağ erişimi veya veritabanı adıyla mı ilgili olduğunu ayırın. Her hata için daha geniş yetki vermek çözüm değildir.
5. Uzak erişimi ayrı bir değişiklik olarak ele alın
Bu başlangıç örneği veritabanını internete açmaz. Uygulama başka sunucuda çalışacaksa listen_addresses, pg_hba.conf, ağ erişimi ve TLS birlikte yapılandırılmalıdır. Yalnızca belirlenen uygulama kaynağı ve gerekli veritabanı kullanıcısı için erişim tasarlayın. Genel ağ aralıklarını geçici kolaylık amacıyla ekleyip unutmayın.
Yapılandırma dosyalarının yolunu tahmin etmek yerine çalışan cluster üzerinden doğrulayabilirsiniz. PostgreSQL'de SHOW config_file ve SHOW hba_file komutları ilgili dosyaları gösterir. Bazı ayarlar yeniden yükleme, bazıları yeniden başlatma gerektirir; değişiklik penceresini buna göre planlayın. Test sertifikasıyla üretim güveni aynı konu değildir.
6. Yedek almayı ve geri yüklemeyi birlikte öğrenin
Küçük bir laboratuvar veritabanında mantıksal yedek akışı örneği aşağıdadır. Dosya yolu, izinler ve kapasiteyi önceden hazırlayın. Bu komut tek başına bütün kurum için yeterli yedek mimarisi önermez.
pg_dump -h 127.0.0.1 -U app_user -d appdb -Fc -f appdb-lab.dump
Yedeğin okunabildiğini ve ayrı bir test veritabanına geri yüklenebildiğini doğrulayın. Gerçek kurtarma hedefleri daha kısa veri kaybı veya daha hızlı dönüş gerektiriyorsa farklı yedek ve arşivleme yaklaşımları değerlendirilir. Yalnızca dosyanın oluşması kabul testi değildir.
Teslim dosyasında sürüm, cluster, uygulama rolleri, bağlantı kapsamı, yedek yeri ve bakım sorumlusu bulunsun. CieloSync ile veri katmanınızı ve uygulama altyapınızı birlikte değerlendirebilirsiniz.
