Veritabanı Yedekleme Mimarileri ve Çözümleri

Merhabalar, bu yazımda biraz daha farklı bir konsept üzerine yoğunlaşmak istedim. Veritabanı performansı elbette önemli stabilizasyon elbette önemli ancak teslim edilmesi gerek en temel hizmetlerden birisi olan “yedekleme” çözümünü de unutmamak gerek.

Yedekleme çözümü, veri tutan her platformda mevcuttur. Biz veritabanı yöneticileri de bu çözümleri optimize ederek sistemlerimize uygularız. Ancak her platformun yedekleme mimarisi farklı şekilde çalışabilir. Hatta aynı platforma ait birden fazla farklı yedekleme mimarisi uygulanabilir 🙂 Bu yazıda, PostgreSQL-Couchbase-SQL Server-Cassandra veritabanlarına ait yedekleme mimarilerini çalışacağız ve bu yedekleme çözümlerini sistemlere uygulayıp başarılı şekilde yedeklerin alındığından emin olacağız.

PostgreSQL Yedekleme Çözümü

PostgreSQL açık kaynak bir veritabanıdır ve yedekleme çözümleri de açık kaynaktır. Burada barman, pg_dump ya da pgBackRest gibi çözümleri kullanabiliriz. Biz PostgreSQL ortamlarında pgBackRest tercih ediyoruz. Temelde bunu tercih etme sebeplerimiz;

  • Yönetilebilir ve temiz konfigürasyon
  • Paralel olarak yedekleme işlevi
  • “Async” olarak arşivleme yeteneği

PostgreSQL üzerinde pgBackRest mimarisi aşağıdaki gibidir. pgBackRest “agent” mantığı ile çalışır. Yani bir yedek sunucusu mevcuttur bir de veritabanı sunucusu mevcuttur. Her iki sunucuda da pgBackRest hizmetleri çalışmaktadır ve her iki sunucuda da pgBackRest konfigürasyonları bulunur. Yedek sunucuda veritabanı için, veritabanı sunucusunda yedek sunucu için konfigürasyonlar bulunmaktadır.

PostgreSQL pgBackRest yapılandırmak için aşağıdaki adımlar sırası ile izlenir.

  • Yedek sunucusuna ve veritabanı sunucusuna aynı versiyona sahip pgBackRest paketleri yüklenmelidir.

yum install pgbackrest -y

  • Yedek sunucu ve veritabanı sunucusuna PostgreSQL paketleri yüklenmelidir.

yum install https://download.postgresql.org/pub/repos/yum/11/redhat/rhel-7-x86_64/pgdg-centos11-11-2.noarch.rpm -y

  • Yedek sunucu ve veritabanı sunucusu arasında “postgres” kullanıcılarının ssh anahtarlarının tanıtılması gerekmektedir.

ssh-keygen -t rsa : SSH Key üreten komut

cat .ssh/id_rsa.pub : Buradaki anahtar karşıdaki sunucuya kopyalanır.

vi .ssh/authorized_keys : Karşıdaki sunucuya girilecek anahtarın dizini.

  • Yedek sunucuda /etc/pgbackrest.conf dosyasına aşağıdaki formatta konfigürasyon girilir.

[mantıksal_stanza_ismi]
pg1-host=veritabanı_sunucu_ip_yada_hostname
pg1-host-user=postgres
pg1-path=veritabanı_data_path
pg1-port=postgresql_port
compress=y
repo1-retention-full=1
start-fast=y
stop-auto=y

  • Veritabanı sunucusunda yine aynı /etc/pgbackrest.conf dosyasına aşağıdaki formatta konfigürasyonlar kaydedilir.

[global]
repo1-host=pgbackrest_sunucu_ip_yada_hostname
repo1-host-user=postgres
log-level-console=info
log-level-file=detail
compress=n

[global:archive-push]
process-max=4
archive-async=y
log-level-console=info
log-level-stderr=info

[mantıksal_stanza_ismi]
pg1-path=postgresql_data_dizini
#pg1-socket-path=/tmp
pg1-port=postgresql_port

  • pgBackRest sunucusunda mantıksal stanza ismi birlikte stanza oluşturulur.

pgbackrest — stanza=mantıksal_stanza_ismi stanza-create

  • pgBackRest ve veritabanı sunucusunda stanzalar üzerinde check komutu çalıştırılır.

pgbackrest — stanza=mantıksal_stanza_ismi check

  • pgBackRest ile full yedek alınır ve periyodik görev kayıt edilir.

pgbackrest — stanza=mantıksal_stanza_ismi — type=full backup

pgBackRest ile daha detaylı bilgiye bu linklerden ulaşabilirsiniz. pgBackRest tamamiyle açık kaynak bir yedekleme çözümüdür.

https://pgbackrest.org/

https://github.com/pgbackrest/pgbackrest

Couchbase Yedekleme Çözümü

Couchbase üzerinde iki farklı yedekleme çözümü kullanılabilir. Bunlar, cbbackup ve cbbckmanager olarak adlandırılır. cbbackup açık kaynak bir çözümdür ancak cbbackpmanager bunun enterprise seviyedeki çözümüdür. cbbackupmanager’ın sahip olduğu yetenekler bizim ihtiyaçlarımızı tam anlamıyla karşıladığı için onu tercih ettik.

Couchbase backup mimarimizde ise, repository mantığı ile ilerliyoruz. Her Couchbase cluster’ını mantıksal bir repository ile etiketleyip o repository’e özel konfigürasyonlar yapıyoruz. Sonrasında da periyodik görevler ile yedekleme işlemlerimizi yapıyoruz. Yine PostgreSQL’de olduğu gibi burada da yedek sunucusu ve veritabanı sunucusu ayrı olarak bulunmaktadır. Repository konfigürasyonlarını yedek sunucumuzda yapıyoruz.

Couchbase backup manager ile yedekleme çözümünü uygulamak için sırası ile aşağıdaki işlemleri tamamlamamız gerekmektedir.

  • Couchbase yedek sunucusunda repository ayarlarını yapmalıyız. Couchbase binary dizininde cbbckmgr binary dosyası ile bunu yapabiliriz.

cbbackupmgr config — archive /couchbase_yedek_dosya_yolu/mantıksal_repo_ismi — repo mantıksal_repo_ismi

  • Couchbase yedek sunucusunda, backup alacak ve bunların retentionlarına göre temizlik yapacak script’imizi ilgili repository özelinde yazarak periyodik olarak bu script’i çalıştıracak duruma getirilir. Script örneğini aşağıda bulabilirsiniz.

(NOT: Bu script’in farklı versiyonunu github üzerinden buldum bir kısmını değiştirdim ancak kaynağını koyamıyorum sayfayı kaybettiğim için. Yinede bu script’in farklı versiyonu github’da var alıntı yapıldı burada diye belirtelim )

#!/bin/bash

ARCHIVE=/couchbase_yedek_dosya_yolu/mantıksal_repo_ismi
REPO=mantıksal_repo_ismi
HOST=XDCR_sunucu_ip
USERNAME=kullanıcı_adı
PASSWORD=kullanıcı_şifresi
THREADS=4
RESTOREPOINTS=3

CBBACKUPMGR=/opt/couchbase/bin/cbbackupmgr
BACKUPREGEX=”[0–9]{4}-[0–9]{2}-[0–9]{2}T[0–9]{2}_[0–9]{2}_[0–9]{2}.[0–9]{9}”

# Running backup
CMD=”${CBBACKUPMGR} backup — archive ${ARCHIVE} — repo ${REPO} — host couchbase://${HOST} — username ${USERNAME} — password ${PASSWORD} — threads ${THREADS}”
echo -e “Running backup…\nCommand: ${CMD}”
$CMD

# Compacting the backup
BACKUPLIST=$(${CBBACKUPMGR} list — archive ${ARCHIVE} — repo ${REPO} | awk ‘{print $NF}’ | grep -E ${BACKUPREGEX})
LASTBACKUP=$(echo “${BACKUPLIST}” | sed ‘$!d’)
echo $LASTBACKUP
CMD=”${CBBACKUPMGR} compact — archive ${ARCHIVE} — repo ${REPO} — backup ${LASTBACKUP}”
echo -e “Compacting the backup…\nCommand: ${CMD}”
$CMD

# Merging old backups
COUNT=$(echo “${BACKUPLIST}” | wc -l)

if [ “$COUNT” -gt “$RESTOREPOINTS” ]; then
START=$(echo “${BACKUPLIST}” | sed -n 1p)
END=$(echo “${BACKUPLIST}” | sed -n $((1+COUNT-RESTOREPOINTS))p)
CMD=”${CBBACKUPMGR} merge — archive ${ARCHIVE} — repo ${REPO} — start ${START} — end ${END}”
echo -e “Merging old backups…\nCommand: ${CMD}”
$CMD
fi

Yukarıdaki script’te threads değişkeni işlemin kaç paralel olarak çalışacağı belirlenebilir. Bizim örneğimizde 4 paralel çalışacak şekilde ayarlandı. Diğer değişken restorepoint’tir. Bu değişken kaç adet yedek tutacağımızı belirler. Yani son 3 adet yedek tutacağız ve 3’den fazla yedek olunca “merge” işlemi devreye girmektedir.

  • Couchbase sunucularının yedeğini almak için aşağıdaki komut çalıştırılabilir ve bu komut işletim sistemi üzerindeki cron’a kayıt edilebilir.

0 * * * * /couchbase_yedek_script_yolu/backup_scripts/mantıksal_repo_ismi_backup.sh

SQL Server Yedekleme Çözümü

SQL Server tarafında ise, bu iki platformdan çok başka bir mimari mevcut. Burada, yedekler küme içerisinde bulunan herhangi bir sunucuda saklanabilir. Aslında başka yerlere de saklanabilir (NFS… etc.)

Yedekleme işlemleri için geleneksel SQL Server bakım planları yerine Powershell kullanabiliriz. Bunu tercih etme sebeplerimiz ise aşağıdaki gibidir;

  • Yaptığımız işleri “… as code” felsefesine göre inşaa edebiliyoruz.
  • Yönetilebilir ve geliştirilebilir bir yapıya sahip oluyoruz.
  • Geleneksel yöntemlere göre yedekleme süreçlerinin yönetimi için daha esnek opsiyonlar mevcut.
  • Geleneksel yöntemlere göre yedekleme çözümü daha basitleşti.

SQL Server’da yedekleme işlemleriniz için açık kaynak olarak geliştirilmekte olan dbatools modülü kullanılabilir. Aşağıdaki linkten dbatools’u da inceleyebilirsiniz.dbatoolsthe community’s sql powershell moduledbatools.io

SQL Server’da iki farklı yedekleme türü mevcuttur temelde. Bunlardan ilki full yedektir (full backup) ikincisi ise transaction log yedeklemesidir (log backup). Powershell ile iki yedekleme tipini de yapabiliriz.

Genel olarak, production sistemlerde full backup için günlük-haftalık-aylık zaman dilimlerinden birisi seçilir ve PITR özelliği için yine saatlik-günlük-haftalık-aylık olarak “log backup” alınır. Bununla birlikte eski yedeklerin de son kullanma tarihi konularak temizlenmesi gerekmektedir. Bu konular yedekleme politikasına girdiği için, diğer yazılarda bahsetmek daha sağlıklı olacaktır.

SQL Server’da yedek almak için iki farklı komut kullanılabilir. İlk komut full yedek alınmasını işlemini yapar. İkinci komut ise, “log backup” alınması işlemini yapar. Aşağıda görüleceği üzere, yedek alma komutuna

Backup-DbaDatabase -SqlInstance veritabanı_sunucu_ismi -Database veritabanı_ismi -BackupDirectory Disk_harfi:\yedek_klasör_ismi -CompressBackup -Checksum -CopyOnly -Type Full

Backup-DbaDatabase -SqlInstance veritabanı_sunucu_ismi -Database veritabanı_ismi -BackupDirectory Disk_harfi:\yedek_klasör_ismi -Type Log

Serinin sonraki yazısında, yedekleme politikaları ve bu yedeklerin felaket anında ya da başka bir ihtiyaçtan ötürü geri yüklenmesi işlemlerini yapacağız. Yedekleme politikaları için tek bir doğru cevap olmasada,production sistemler için takip edilebilecek ya da referans olabilecek politikaları inceleyeceğiz. Tabiki de bu politikaların bize sağladığı “point in time recovery” özelliğini tartışacağız. Çünkü her yedekleme politikası ve yedekleme çözümünün PITR konusunda sağladığı esneklik farklı olabiliyor…

Yedekleme çözümleri konusunda, “nasıl yapılır ? “ konusunda sorularınız ve düşünceleriniz doğrudan iletişime geçebilirsiniz 🙂

Sevgilerle,

Demir.

Leave a Reply

Your email address will not be published. Required fields are marked *