Günce Sarıkaya

PostgreSQL major versiyonunu birden farklı şekilde upgrade edebilirsiniz. Bunlardan en çok bilineni pg_upgrade adı verilen PostgreSQL toolunu kullanmaktır. Bunun dışında Logical replication yapısı kullanılarak veya dump-restore işlemi ile major versiyon upgrade'i yapılabilir.  Üç yöntemin artıları ve eksikleri bulunmaktadır. Upgrade konusunda en doğrusu hangisidir diye bir durum söz konusu değildir. Mevcut sisteminize uygun olan yapıyı kullanmak en doğrusu olacaktır. pg_upgrade Kullanımı Upgrade için en sık kullanılan yöntemlerdendir. PostgreSQL servisini kapatmak, dolayısıyla kesinti alınması gerekmektedir. Upgrade işlemi ile mevcut data dizini kullanımı sonlanacağından, bu kesinti süresi data dizininin taşınması için gereken süreye eş değerdir. pg_upgrade komutu ile bu süreyi kısaltmanın bir yolu dosyaların taşınması yerine linkleme seçeneğinin kullanılmasından geçer.  Upgrade işlemi öncesi veritabanınızı mutlaka yedeklemenizi öneririm. Bunu storage bazında data directory'nin

Patroni ile PostgreSQL entegrasyonuna ait yazı serisinin dördüncüsünde, mevcut PostgreSQL veritabanının Patroni tarafına nasıl geçirilebileceği ile ilgili bir şeyler paylaşmak isterim. Üç node'lu PostgreSQL cluster'imiz var, tüm Postgres servisleri ayakta ve replikasyonda da sorun yok diyelim. Bu aşamada bizim Postgres sunucularını Patroni geçişine hazırlamamız gerekir. Üç node'lu ETCD Cluster'ini kurduğumuzu ve PostgreSQL'in Patroni ile bootstap edilmesine kadar tüm aşamalara geldiğimizi varsayalım. Artık PostgreSQL instance'inin başlatılmasına gelsin iş. Patroni ile Postgres'in bootstrap edilmesinden önce Patroni konfigürasyonundaki değişkenlerin yeni sunucu için de geçerli olmasına dikkat etmeliyiz. Örneğin replikasyon için replicator kullanıcısının parolası. Bunu ya Postgres servisini kapatmadan doğru kullanıcıları postgresql.yml içindeki parolayla ve doğru yetkilerle oluşturarak verebiliriz ya da eğer böyle bir kullanıcı varsa da postgresql.yml

Patroni kurulumuyla ilgili oldukça fazla kaynak bulunmakta fakat kurulum ve yönetimini beraber barındıran kaynağa denk gelmedim. Bu yazıda hem Patroni kurulumu hem de kurulum sonrası yönetimiyle alakalı detaylara ulaşabilirsiniz. PostgreSQL cluster'larının yönetimi için kullanılan Patroni ile ilgili temel bilgilerin yer aldığı Autofailover üzerine hazırladığım yazı serisine aşağıdaki linklerden erişebilirsiniz. PostgreSQL ve Autofailover PostgreSQL'de Autofailover ve Patroni 1 (Giriş) PostgreSQL'de Autofailover ve Patroni 2 (Kurulum, Konfigürasyon ve Yönetim) PostgreSQL'de Autofailover ve Patroni 3 (Mevcut PostgreSQL Cluster'inin Patroni'ye Geçirilmesi) Patroni, PostgreSQL veritabanlarının kurulumundan ve konfigürasyonundan sorumludur. Yani Patroni'yi kurduğumuz sunucular aynı zamanda Patroni ile kurulmuş PostgreSQL'leri barındıracak. Üç node'lu PostgreSQL ve üç node'lu ETCD cluster'larını oluşturacağım. Kuruluma önce üç no

Patroni, PostgreSQL HA (High Availability) Cluster yapısının kurulması ve yönetimi için kullanılan open source bir araçtır. Patroni, PostgreSQL Cluster’inin kurulumu (bootstrap), replikasyonunun kurulumu, PostgreSQL otomatik failover yapılması amacıyla kullanılır. Python ile yazılmıştır. Bir önceki yazıda PostgreSQL'de Autofailover araçlarının ne olduğu ve neden Autofailover'a gereksinim duyulduğu konusunda yazı paylaşmıştım. Yazıya buradan ulaşabilirsiniz. Patroni Kurulumu İçin Gereksinimler nedir? Patroni’nin tek başına kurulumu autofailover yapısını yapılandırmak için yeterli değildir. Patroni ile Autofailover yapısının kurulması için DCS (Distributed Configuration Store) araçlarından birine ihtiyaç vardır. Bunlardan bazıları; ETCD, Consul, ZooKeeper, Kubernetes. PostgreSQL üzerinde Autofailover araçlarından Patroni entegre edecekseniz DCS araçlarından birini kullanmanız gerekecek. DCS dediğimiz şey aslında Service Discovery araçlarından biri olduğundan bu iki tan

Bir veritabanının düzenli olarak yedeğinin alınması ve sağlıklı replikasyonun mevcut olması kadar olabilecek herhangi felaket senaryosunda veritabanının devamlılığı da oldukça önemlidir. Gelen taleplerin primary veritabanına ulaşılamama durumunda (sunucunun kapanması veya Postgres servisinin kapanması gibi) okuma ve daha da önemlisi yazma işlemlerinin standby node'lar üzerindeki veritabanından devam etmesi yani read-only olan bir node'un writable olması bir veritabanı yöneticisinin yapması gereken öncelikli işlerden biridir. Bahsettiğim bu yapı Autofailover yapısının mevcut olmasıyla mümkündür. PostgreSQL veritabanıyla bir Autofailover yapısının kurulmasının birden fazla yolu vardır. Temel olarak Autofailover için aşağıdaki araçlar kullanılabilir. Patroni (By Zalando)  Repmgr (Replication Manager)  PAF (PostgreSQL Automatic Failover)  Pg_auto_failover (By Citus)  Yukarıda belirtilen araçların her birini Autofailover yapısını PostgreSQL üzerine entegre etmek için ücr

Merhaba, Bu yılın sonuna doğru PostgreSQL 12'nin yayınlanması bekleniyor. Yeni özelliklerin eklenmesi yanı sıra, mevcut özellikler üzerinde değişiklikler de yapıldı. Yeni gelen özelliklerden biri "Generated Columns" yapısı. PostgreSQL 12 ile gelen yeniliklerden bahsettiğim sunumuma buradan ulaşabilirsiniz. Generated Columns, tabloda yer alan diğer sütunların kullanılmasıyla meydana gelen sütunlardır. Bunun iki çeşidi vardır: Stored ve Virtual. Stored olan sütunun yeni değerini hesaplar ve tabloya yeni veriyi yazar. Virtual is bir view gibi davranır. ilgili sütun her kullanıldığında değeri yeniden hesaplanır. Postgres bunlardan Stored olanını kullanır.  Dikkat edilmesi gereken bir kaç konu var: INSERT/UPDATE komutları Generated Column için kullanılamaz. Generated Column Partition Key olamaz. Generated Column başka bir Generated Column kullanılarak oluşturulamaz. Standart SQL ve PostgreSQL'de olduğu gibi sıradan bir tablo oluşturalım.  test=# CREATE TABLE