Onlarca yıldır mysqldump, MySQL veritabanı yedeklemeleri için tartışmasız bir İsviçre çakısı olmuştur. Her yerde bulunur, basittir ve her MySQL ve MariaDB dağıtımıyla birlikte önceden yüklenmiş olarak gelir. Küçük ve orta ölçekli veritabanları için oldukça başarılı bir performans sergiler.
Ancak, organizasyonlar büyüdükçe ve veri setleri 100GB, 500GB veya çoklu terabayt eşiklerini aştıkça, mysqldump‘a güvenmek en iyi uygulamadan kritik bir mimari zafiyete dönüşür. Büyük ölçekli üretim veritabanlarını yöneten bir DBA veya DevOps mühendisiyseniz, muhtemelen mantıksal dökümlerle (logical dumps) ilişkili sessiz hataları, üretim performans düşüşlerini ve kabul edilemez Kurtarma Süresi Hedeflerini (RTO) deneyimlemişsinizdir.
Bu makalede, mysqldump‘ın mimari sınırlamalarını inceleyecek, neden ölçekte başarısız olduğunu keşfedecek ve görev açısından kritik verilerinizi korumak için kurumsal düzeyde fiziksel yedekleme stratejilerini nasıl uygulayacağınızı detaylandıracağız.
mysqldump’ın Mimari Sınırlamaları
mysqldump‘ın neden ölçekte başarısız olduğunu anlamak için perde arkasında nasıl çalıştığını incelememiz gerekir. mysqldump mantıksal yedeklemeler gerçekleştirir. Veritabanı motorunu sorgular, verileri okur ve bunları bir dizi SQL ifadesine (öncelikle CREATE TABLE ve INSERT INTO) dönüştürür.
Bu, oldukça taşınabilir ve insan tarafından okunabilir bir dosya oluştursa da, yüksek iş hacmine sahip ortamlarda ciddi darboğazlara neden olur.
1. Tek İş Parçacıklı (Single-Threaded) Darboğaz
Tasarımı gereği mysqldump tek iş parçacıklı bir işlemdir. Her seferinde bir tabloyu, satır satır işler. Modern donanımlar düzinelerce CPU çekirdeğine ve saniyede gigabaytlarca iş hacmi kapasitesine sahip NVMe depolamaya sahip olsa da, mysqldump bu kaynakların sadece bir kısmını kullanır.
InnoDB tabloları için standart bayrakları kullanırken bile:
mysqldump -u root -p --single-transaction --routines --triggers --events --quick production_db > backup.sql
--quick bayrağı, mysqldump‘ı tüm tabloyu belleğe almak yerine satırları tek tek almaya zorlar, bu da istemci tarafında Bellek Yetersizliği (OOM) hatalarını önler. Ancak, tek iş parçacıklı doğası gereği 500GB’lık bir veritabanının dökümünü almak 10 ila 15 saat sürebilir ve bu da Kurtarma Noktası Hedefinizi (RPO) ciddi şekilde etkiler.
2. InnoDB Tampon Havuzu (Buffer Pool) Kirliliği
mysqldump her tablonun her satırını okuduğunda, MySQL motorunu bu verileri diskten InnoDB tampon havuzuna yüklemeye zorlar. Bir üretim ortamında, tampon havuzunuz “sıcak” çalışma veri setinizle dikkatlice doldurulmuştur.
Büyük bir mantıksal döküm, tampon havuzunu süpürerek, yedeklenen soğuk verilere yer açmak için sık erişilen dizinleri ve veri sayfalarını dışarı atar. Bu, üretim sorguları diskten okumaya zorlandığı için disk G/Ç’sinde ani ve büyük bir artışa neden olur ve bu da ciddi uygulama gecikmelerine yol açar.
3. Meta Veri Kilitleri ve DDL Çakışmaları
Tutarlılığı korumak için DBA’ler, işlem yalıtım seviyesini REPEATABLE READ olarak ayarlayan ve verileri dökmeden önce bir işlem başlatan --single-transaction bayrağına güvenirler.
Bu, tablo düzeyinde okuma kilitlerini (FLUSH TABLES WITH READ LOCK) önlese de, Veri Tanımlama Dili (DDL) değişikliklerine karşı koruma sağlamaz. mysqldump çalışırken bir tablo üzerinde ALTER TABLE, DROP TABLE veya TRUNCATE TABLE komutu yürütülürse, yedekleme table definition has changed, please retry transaction hatasıyla çöker. Sık şema geçişlerinin olduğu CI/CD ortamlarında bu durum sürekli yedekleme hatalarına neden olur.
4. RTO Kabusu: Geri Yükleme Süreleri
mysqldump‘ın en felaket başarısızlığı yedekleme sırasında değil, geri yükleme sırasında gerçekleşir.
Mantıksal bir dökümü geri yüklemek, MySQL motorunun milyonlarca INSERT ifadesini ayrıştırmasını ve yürütmesini gerektirir. Eklenen her satır için MySQL şunları yapmalıdır:
* Kısıtlamaları kontrol et (Yabancı Anahtarlar, Benzersiz Anahtarlar).
* İkincil dizinleri anında yeniden oluştur.
* InnoDB redo günlüğüne yaz.
* Binlog’a boşalt (etkinse).
1TB’lık bir veritabanını mantıksal bir dökümden geri yüklemek birkaç gün sürebilir. İşletmenizin 4 saatlik bir RTO’su varsa, mysqldump Hizmet Seviyesi Anlaşmanızı (SLA) ihlal edeceğinizi garanti eder.
Kurumsal Düzeyde Alternatifler: Fiziksel Yedeklemelere Geçiş
Büyük veri setleri için hızlı yedekleme ve geri yükleme elde etmek istiyorsanız, mantıksal yedeklemeleri terk edip fiziksel yedeklemelere geçmelisiniz.
Fiziksel yedeklemeler, MySQL SQL yürütme motorunu tamamen atlar. Bunun yerine, temel ikili veri dosyalarını (.ibd dosyaları, redo günlükleri ve undo günlükleri) doğrudan dosya sisteminden kopyalarlar. Sadece dosya kopyaladıkları için, depolama donanımınızın maksimum sıralı okuma/yazma hızında çalışabilirler ve yoğun bir şekilde paralelleştirilebilirler.
Percona XtraBackup: Endüstri Standardı
InnoDB ve XtraDB motorları için Percona XtraBackup, önde gelen açık kaynaklı fiziksel yedekleme aracıdır. MySQL veritabanlarının sıcak, engelleyici olmayan yedeklemelerini gerçekleştirir.
XtraBackup Nasıl Çalışır?
- Veri Kopyalama: XtraBackup, InnoDB veri dosyalarını (
.ibd) kopyalamaya başlar. - Günlük Takibi: Veritabanı canlı olduğu için, dosyalar kopyalanırken veriler değişecektir. XtraBackup, yedekleme penceresi sırasında gerçekleşen tüm işlemler için InnoDB redo günlüğünü (
ib_logfile0, vb.) izleyen ve kopyalayan bir arka plan iş parçacığı oluşturur. - Hazırlık (Çökme Kurtarma): Yedeklemeden sonra, kopyalanan veri dosyaları tutarsız bir durumdadır. XtraBackup, kopyalanan redo günlüklerini veri dosyalarına uygular (MySQL’in başlangıçta çökme kurtarma işlemini gerçekleştirmesine benzer şekilde), bu da yedeklemenin bittiği anda veritabanının mükemmel derecede tutarlı bir anlık görüntüsüyle sonuçlanır.
Fiziksel Yedekleme Stratejisi Uygulama
İşte Percona XtraBackup kullanarak fiziksel bir yedekleme stratejisi uygulamanın teknik bir özeti.
1. Adım: Yedeklemeyi Akış Haline Getirme (Streaming)
Büyük bir yedeklemeyi yerel diske yazmak genellikle kapasite sorunlarına neden olur. En iyi uygulama, yedeklemeyi doğrudan bir arşiv formatına akıtmak, sıkıştırmak ve bir hazırlık alanına veya doğrudan bir yedekleme platformuna göndermektir.
xbstream kullanarak, yedeklemeyi paralelleştirebilir ve anında sıkıştırabiliriz:
xtrabackup --backup
--user=backup_user
--password=SecurePassword!
--parallel=4
--stream=xbstream | lz4 > /mnt/backups/mysql_prod_backup.xbstream.lz4
--parallel=4: Veri dosyalarını eşzamanlı okumak için 4 iş parçacığı kullanır.--stream=xbstream: Yedeklemeyi Percona’nın özel akış formatında çıktı olarak verir.lz4: Son derece hızlı, düşük CPU tüketen sıkıştırma sağlar.
2. Adım: Yedeklemeyi Geri Yükleme İçin Hazırlama
Fiziksel bir yedekleme geri yüklenmeden önce “hazırlanmalıdır” (redo günlüklerini uygulayarak). İlk olarak, akışı çıkarın ve sıkıştırmasını açın:
mkdir -p /data/restore
lz4 -d /mnt/backups/mysql_prod_backup.xbstream.lz4 | xbstream -x -C /data/restore
Ardından, hazırlık aşamasını çalıştırın. Bu adım bellek gerektirir, bu nedenle sunucunun yeterli RAM’e sahip olduğundan emin olun:
xtrabackup --prepare --use-memory=4G --target-dir=/data/restore
3. Adım: Veritabanını Geri Yükleme
Geri yüklemek için hedef MySQL veri dizininin tamamen boş olması gerekir. MySQL hizmetini durdurun, dizini temizleyin ve dosyaları geri kopyalayın:
systemctl stop mysql
rm -rf /var/lib/mysql/*
xtrabackup --copy-back --target-dir=/data/restore
Son olarak, hizmeti başlatmadan önce dosya sistemi izinlerini düzeltin:
chown -R mysql:mysql /var/lib/mysql
systemctl start mysql
Veri dosyaları zaten oluşturulmuş ve dizinler derlenmiş olduğundan, veritabanı hemen başlar. mysqldump ile 48 saat süren bir geri yükleme, artık sadece dosyaların ağınız veya diskiniz üzerinden kopyalanması kadar sürer; bu da genellikle RTO’yu dakikalara indirir.
Mantıksal Geri Yüklemeleri Optimize Etme (Kullanmak Zorunda Kaldığınızda)
Büyük bir mantıksal dökümü geri yüklemek zorunda kalırsanız (örneğin, farklı büyük MySQL sürümleri arasında veya fiziksel dosyaların uyumsuz olduğu farklı CPU mimarileri arasında geçiş yaparken), büyük yazma iş hacmi için optimize etmek üzere MySQL yapılandırmanızı geçici olarak ayarlamanız gerekir.
Mantıksal geri yüklemeyi başlatmadan önce bu ayarları my.cnf dosyanıza uygulayın:
[mysqld]
# Bağımsız bir geri yükleme ise binlogging'i geçici olarak devre dışı bırakın
disable_log_bin
# Yazma hızını en üst düzeye çıkarmak için diske yazmayı geciktirin
innodb_flush_log_at_trx_commit = 2
# Çalışma setinin mümkün olduğunca fazlasını sığdırmak için tampon havuzunu artırın
innodb_buffer_pool_size = <Toplam RAM'in %70'ine ayarlayın>
# Agresif kontrol noktalarını önlemek için günlük dosyası boyutunu artırın
innodb_log_file_size = 2G
# Çift yazma tamponunu devre dışı bırakın (üretim için riskli, ilk yükleme için güvenli)
innodb_doublewrite = 0
Not: Üretim trafiğine izin vermeden önce bu ayarları her zaman ACID uyumlu varsayılanlarına (innodb_flush_log_at_trx_commit = 1, innodb_doublewrite = 1) döndürün ve MySQL hizmetini yeniden başlatın.
CloudSave ile Yedeklemeleri Otomatikleştirme ve Güvenli Hale Getirme
Percona XtraBackup gibi araçlar verileri verimli bir şekilde çıkarma mekaniğini çözse de, gerçek bir kurumsal felaket kurtarma stratejisi orkestrasyon, güvenli saha dışı depolama ve yaşam döngüsü yönetimi gerektirir. Fiziksel yedeklemeleri yönetmek için özel bash betiklerine ve cron işlerine güvenmek, yüksek sessiz hata riski ve uyumluluk ihlalleri doğurur.
İşte tam bu noktada, veritabanı katmanınızı CloudSave gibi kurumsal bir platformla entegre etmek kritik hale gelir.
CloudSave, ham veritabanı yardımcı programları ile kurumsal uyumluluk arasındaki boşluğu doldurur. CloudSave’in ön ve son betik yeteneklerini kullanarak, DevOps ekipleri tutarlı bir fiziksel anlık görüntü oluşturmak için XtraBackup’ı tetikleyebilir. CloudSave daha sonra yedekleme akışını sorunsuz bir şekilde alır, AES-256 şifrelemesi uygular ve verileri değişmez bulut depolama alanına çoğaltmadan önce tekilleştirir.
Bu mimari şunları sağlar:
1. Üretim Performansı Korunur: Yedeklemeler, InnoDB tampon havuzunu kirletmeden depolama hızlarında çalışır.
2. Fidye Yazılımı Koruması: CloudSave içindeki değişmez depolama politikaları, kötü niyetli aktörlerin veritabanı arşivlerinizi silmesini veya şifrelemesini önler.
3. Otomatik Saklama: Büyükbaba-Baba-Oğul (GFS) saklama politikaları otomatik olarak yönetilir, bu da veri egemenliği ve denetim gereksinimlerine uyumu sağlar.
4. Öngörülebilir RTO: CloudSave fiziksel dosya arşivlerini yönettiğinden, çok terabaytlık bir veritabanını yeni bir örneğe geri yüklemek hızla düzenlenebilir ve katı RTO hedeflerine ulaşılabilir.
Sonuç
Büyük ölçekli veritabanları için mysqldump kullanmaya devam etmek, organizasyonunuzun çalışma süresi ve veri bütünlüğü ile kumar oynamaktır. Tek iş parçacıklı doğası, tampon havuzu kirliliği ve felaket niteliğindeki geri yükleme süreleri, onu modern, yüksek iş hacimli ortamlar için temelden uygunsuz kılar.
Percona XtraBackup gibi araçları kullanarak fiziksel yedeklemelere geçerek ve yaşam döngüsünü, şifrelemeyi ve saha dışı çoğaltmayı CloudSave gibi sağlam bir platform aracılığıyla düzenleyerek, veritabanı yedekleme stratejinizi kırılgan bir yükten esnek, kurumsal düzeyde bir varlığa dönüştürürsünüz. Mevcut RTO ve RPO metriklerinizi bugün değerlendirin; eğer bir geri yükleme, işletmenizin çevrimdışı kalmayı göze alabileceğinden daha uzun sürüyorsa, mysqldump‘ı geride bırakmanın zamanı gelmiştir.
