Re: Yedekleme Scripti

Yüksel Bey,

O durumda bir risk oluşturacağını düşünmüyorum; zaten Devrim Bey risk değil; performans sıkıntısından bahsetmişti. Bu performans sıkıntısı hem backup anında, hem de sonrasında etkili olabilecek bir durum.

Ben kişisel pg_dump'i kullandım; veri kaybı olarak bir sorunla karşılaşmadım; ancak sorunları su şekilde özetleyebilirim.

pg_dump oldukça ağır bir işlem. Diğer yöntemlerde en başta bir temel yedekleme yapılıyor (base backup), sonrasında temel teknik, farkların WAL logları olarak diğer tarafa aktarılması şeklinde.

Bunu kabaca şöyle anlatabiliriz:

Veri, postgres'e geldiğinde, postgres bunu öncelikle bir log'a koyuyor, bu log'a Write Ahead Log, yani Yazım Öncesi Log deniyor. Burada yapılması gereken işlemle ilgili bir reçete olarak bulunuyor. Dolayısıyla bu log dosyasını ikinci bir sisteme gönderirseniz, o sistem de bunu kendisi bağımsız bir şekilde uygulayabilir.

Bunu kabaca git'e benzetebiliriz. Her git pull yaptığınızda, git sizdeki verilerle karşı taraftaki veriler arasında bir fark alıp sadece onu transfer eder.

Anladığım kadarıyla pg_dump esnasında ana kayıt alanının tümünü dondurması gerekiyor Postgres'in. Çünkü kayıt başladığı andan kayıt sonlanana kadar, başlangıç anında olan hiçbir veri silinmemeli. Bu nedenle temizlik (VACUUM) işlemleri durduruluyor. Vacuum'u da bir nevi garbage collection'a benzetebiliriz. Postgres, sildiği ya da güncellediği satırları aslında gerçekte silmiyor.

Mesela,

"İsim, Soyisim, Numara" sütunlarından oluşan bir tablo için "Üstün, Özgür, 123" diye bir kayıt varsa ve numara 124 olarak UPDATE ile güncellenirse aslında Postgres, "Üstün, Özgür, 124" şeklinde bir İNSERT yapıyor.

Dolayısıyla o an için sistemde

Üstün, Özgür, 123
Üstün, Özgür, 124

şeklinde iki kayıt oluyor.

Peki Postgres bu ikisinden hangisini güncel olduğunu nereden biliyor? Gizli bir "geçerli mi?" sütunuyla.

Yani, aslında tablo "İsim, Soyisim, Numara, Geçerli mi?" şeklinde 4 sütundan oluşuyor.

Üstün, Özgür, 123, Hayır
Üstün, Özgür, 124, Evet

Bu şekilde Postgres'e Üstün Özgür'ün numarası kaç diye sorduğumuzda yanıt olarak 124 verebiliyor, çünkü 123'lü veri hala silinmemiş olsa da artık geçersiz.

Bir süre sonra da Postgres, geçersiz olan verileri sistemden siliyor.

Son durumda veri olarak

Üstün, Özgür, 124

kalıyor.

Şimdi, pg_dump örneğine dönelim:

Diyelim, saat 12:00'da pg_dump'i başlattınız. O esnada numara 123. Sonra, update yapıldı, numara 124 oldu. İşlem, 12:15'te bitti.

pg_dump doğası gereği, size sistemin 12:00'da olduğu halini vermek zorunda. Bu 15 dakika boyunca yapılan değişikleri bildiremez. Kusurlarından biri bu.

İkincisi, bu 15 dakika boyunca, hala 15 dakika önceki herhangi bir veriye de ihtiyaç duyabilir, o yüzden her türlü temizlik, yani VACUUM işlemini de engelliyor.

Vacuum işlemleri zamanında yapılamazsa tablo sisiyor, hatta bir noktada hiç yapılamaz hale geliyor.

Tabii bunları kabaca anlattım, hatalarım olabilir, ama benim anladığım şekliyle sistem bu şekilde çalışıyor.

Backup konusu ile replication konusu birbiriyle çok ilgili iki konu, bu konuda "PostgreSQL Replication" kitabını tavsiye ederim.

https://www.packtpub.com/mapt/book/All%20Books/9781849516723

Altta yatan veri kaydı konusu için şu yazıya göz atabilirsiniz: https://eng.uber.com/mysql-migration/

Bu makale, biraz Postgres karşıtı olsa da ilk kısımda çok güzel bir şekilde çalışma mimarisini anlatmış.

İnsanların neden altenatif yöntemleri kullanmadığına gelince, birincisi, bunları bilmek belli bir deneyim gerektiriyor. Devrim Bey'in dediği gibi yazılımcıdan çok veritabanı uzmanının bileceği konular. İkincisi de birkaç yıl öncesine kadar bu araçlar çok gelişmemişti, örneğin replication konusu postgres'te oldukça zahmetliydi, ki gönderdiğim kitabı okursanız onun da birçok farklı çeşidi var: senkron/asenkron; mantıksal/fiziksel, ama bugün itibariyle bu sorun çözülmüş gibi duruyor.
Üstün

--
Ustun Ozgur

Founder, Ustun Ozgur Software

http://ustunozgur.com
https://twitter.com/UstunOzgur
https://tr.linkedin.com/in/ustunozgur
Tel: 0533 326 24 25

Skype: ustunozgur

> On Dec 8, 2016, at 4:45 PM, Yüksel ÖZCAN <yuksel(at)balkanlar(dot)net> wrote:
>
> Selamlar,
>
> Devrim bey, pg_dump ile yedek almak neden riskli? Büyük boyutlu ve
> yoğun çalışan yerlerde mi riskli? küçük, 3-5 kişinin bağlandığı
> durumlarda da risk oluşturuyor mu? biraz daha ayrıntı ve pg_dump
> kullanımında tavsiye/tecrübelerinizi paylaşabilirmisiniz?
>
> Şimdiden teşekkürler,
>
> 8 Aralık 2016 16:44 tarihinde Yüksel ÖZCAN <balkanlar(dot)net(at)gmail(dot)com> yazdı:
>> Selamlar,
>>
>> Devrim bey, pg_dump ile yedek almak neden riskli? Büyük boyutlu ve
>> yoğun çalışan yerlerde mi riskli? küçük, 3-5 kişinin bağlandığı
>> durumlarda da risk oluşturuyor mu? biraz daha ayrıntı ve pg_dump
>> kullanımında tavsiye/tecrübelerinizi paylaşabilirmisiniz?
>>
>> Şimdiden teşekkürler,
>>
>> 7 Aralık 2016 13:35 tarihinde Zafer Çelenk <zafercelenk(at)gmail(dot)com> yazdı:
>>> Aslında sitesindeki yönergeleri takip edince kurulum çok zor değil. Ubuntu
>>> kurulu bir sanal makine üzerinde PostgreSQL ve pgBackRest kurulumu yaptım.
>>> Yedekleme ve geri yükleme işlemlerini başarılı bir şekilde gerçekleştirdim.
>>> Ancak sizin bahsettiğiniz sürekli yedekleme sistemini bulamadım. Yani manuel
>>> olarak backup alabiliyorum ama sürekli backup işlemi nasıl otomatik hale
>>> getirilir bulamadım. Yardımlarınız için teşekkürler.
>>>
>>> Mevcut sistemde PostgreSQL, CentOS7 üzerinde çalışıyor. Ancak deneme sistemi
>>> için Ubuntu kurmuştum. Doğrusu Ubuntu üzerinde yönetim bana çok daha kolay
>>> ve pratik geldi. PostgresSQL için Ubuntu veya CentOS sisteminin büyük bir
>>> farkı var mı?
>>>
>>> Zafer.
>>>
>>>
>>> On Wed, Dec 7, 2016 at 12:36 PM, Devrim Gündüz <devrim(at)gunduz(dot)org> wrote:
>>>
>>> Merhabalar, On Mon, 2016-11-21 at 15:29 +0300, Zafer Çelenk wrote:
>>>
>>> Peki, pg_dump kullanmaktan vazgeçtim. Siz haklısınız bu noktada var olan
>>> daha iyi alternatiflere yönelmeye karar verdim. pgBackRest kullanımı
>>> hakkında sizin bilgdiğniz Türkçe bir kaynak var mı? Ben nette bir şey
>>> bulamadım.
>>>
>>> Yok bildiğim kadarıyla. Saygılar,
>>> --
>>> Devrim GÜNDÜZ EnterpriseDB: http://www.enterprisedb.com PostgreSQL
>>> Danışmanı/Consultant, Red Hat Certified Engineer Twitter: @DevrimGunduz ,
>>> @DevrimGunduzTR
>
>
> ---------------------------(end of broadcast)---------------------------
> TIP 6: Have you searched our list archives?
>
> http://archives.postgresql.org

---------------------------(end of broadcast)---------------------------
TIP 4: Don't 'kill -9' the postmaster