Günce Sarıkaya

PostgreSQL versiyon upgrade'leri için en sık kullanılan yöntemlerden biri olan Logical Replication ile upgrade işlemleri oldukça basit bir kaç adımla tamamlanabilir.  Bu işlemi yapmak için wal_level=logical olması gerekmektedir. Eğer bu parametre değeri replica veya minimal ise postgresql.conf içinde wal_level değiştirilmeli ve postgresql servisi restart edilmelidir. Eğer zaten wal_level=logical olarak kullanıyorsanız yapılacak upgrade işlemi için servis restart etmek zorunda kalmazsınız.  Online olarak upgrade işlemini gerçekleştirebilmek için primary node'dan trafiği secondary ortama yönlendirebileceğiniz HAProxy vb. bir ara katman olmalıdır.  Ubuntu 16.04.7 LTS ortamına PostgreSQL 12 ve 13 kurulumu gerçekleştirilecek. Gerekli kurulum adımlarına buradan ulaşabilirsiniz.  Primary ve secondary sunucularımız olacak. Primary sunucuda PostgreSQL 12, secondary sunucuda 13 kurulumunu gerçekleştireceğiz.  Primary Node'a PostgreSQL 12 Kurulumu sudo sh -c 'echo "deb h

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, PostgreSQL'de veritabanı üzerinden mail atmak için bir kaç yol bulunuyor. Bu yollar açık kaynak kodlu araçları kullanmaktan geçiyor örneğin pgMail ya da bir fonksiyon içindeki bir python koduyla da yapabilirsiniz. Bunlar, kullanabileceğiniz yöntemlerden sadece ikisi. Veritabanı üzerinden sadece SQL scripti kullanarak mail atılması için bir script hazırladım. Bu yazıda farklı bir araç tanıtmayacağım. Postgres'in kendi özelliğini kullanarak bu işlemi gerçekleştirmek için aşağıdaki adımları kullanmanız yeterli olacaktır. (Linux tarafında mail atılması için gereken kurulumlarınız hazırsa tabi) Maili Postgres'in in-core özelliği olan COPY ifadesini kullanarak atacağız. COPY ifadesini kullanarak farklı kaynaklardaki verileri Postgres veritanabındaki tablolara yazabileceğimiz gibi, Postgres veritabanındaki bir tabloyu da sunucu üzerinde, postgres kullanıcısnın yetkisi dahilindeki dizinlere aktarmamız mümkün. COPY ile ilgili daha fazla bilgiye bu linkten ulaşabili

Merhaba, Array veri tipi bir yada daha çok boyutlu olabilir. Bir alana aynı veri tipinde birden fazla değer girilmesini sağlar diyebiliriz. Bir array’in hangi veritipine ait verileri barındıracağını belirleyebiliriz. Örneğin text veri tipinde bir array kullanabiliriz. Basit bir array örneği yapalım. Aşağıdaki örnekte tek bir satır ve sütun göreceksiniz. Array içinde kullanılan her iki değer text veri tipinde. [gunce] # SELECT array['aa','bb'];  array   --------- {aa,bb} (1 row) Bu ARRAY henüz bir tablonun sütunu olmadığı için deneme yapalım ve yukarıdaki array içine bir alan daha ekleyelim text veri tipinde olmayan. Böyle bir durumda hata verecektir çünkü ilk değer ne ise onunla aynı veri tipine sahip bir değer görmek isteyecektir. [gunce] # SELECT array['aa','bb', 11]; ERROR:  22P02: invalid input syntax for integer: "aa" Ürünlerin içeriklerini saklayan bir tablomuz olsun. [gunce] # CREATE TABLE urunler(isim

Merhaba, Range veri tipleri, verilerin belirli aralıkta olmasıyla ilgilidir. Örneğin otel rezervasyon uygulamasında bir odanın hangi saatler arasında boş veya dolu olduğunu tstzrange(timestamp with time zone) veri tipini kullanarak saklayabilirsiniz veritabanınızda. Postgres’de bahsedilen bu örnekteki gibi farklı veri tiplerine de uygun range veri tipleri bulunmaktadır. Timestamp’in yanında bir de numeric, date, int veri tiplerine de uygun farklı range veri tipleri bulunmaktadır. Postgres’de mevcut range veri tipleri aşağıdaki gibidir. int4range — Range of integer int8range — Range of bigint numrange — Range of numeric tsrange — Range of timestamp without time zone tstzrange — Range of timestamp with time zone daterange — Range of date Aralıkların Belirlenmesi İçi boş olmayan aralığın düşük ve yüksek olmak üzere iki adet sınırı bulunur. Bu iki sınır arasındaki tüm değerler bizim veri tipimize uygun bu aralık içinde yer alır. Düşük sınırın aralığa dahil olması için ‘[‘ işaret