Veritabanı Taşıma: mysqldump/mydumper ile Sıfır Kayıp Geçiş

Veritabanı Taşıma: mysqldump/mydumper ile Sıfır Kayıp Geçiş

Veritabanı taşıma, bir sunucu değişikliğinin belki de en gergin adımıdır. Dosya taşımak görece basittir — kopyala, yapıştır, bitti. Ama bir veritabanını taşırken elinizde "canlı", sürekli yazılan, transaction'ların ortasında olabileceği bir yapı vardır. Yanlış yapılan bir dump işlemi, yarım kalan bir tablo, tutarsız bir foreign key ilişkisi ya da karakter seti uyuşmazlığı; sipariş kayıtlarının kaybolmasına, kullanıcı hesaplarının bozulmasına ya da e-ticaret sitesinde stok sayılarının çakışmasına kadar uzanan sorunlara yol açabilir.

Bu yazıda iki temel aracı — mysqldump ve mydumper — kullanarak MySQL/MariaDB veritabanlarını sıfır veri kaybıyla nasıl taşıyacağınızı, hangi durumda hangi aracı seçmeniz gerektiğini ve taşıma sürecinin her aşamasında veri bütünlüğünü nasıl doğrulayacağınızı adım adım anlatıyoruz. Yeni bir sunucuya geçiş yapıyor, eski bir paylaşımlı hosting'den VDS Sunucu altyapısına yükseliyor ya da sadece veritabanı sürümünü güncelliyor olun, aşağıdaki adımlar sizi kayıpsız bir geçişe götürecek.

Veritabanı Taşıma Sürecinde Nelerin Yanlış Gidebileceği

Taşıma sırasında yaşanan veri kayıplarının büyük çoğunluğu üç kaynaktan gelir:

1. Tutarsız anlık görüntü (snapshot) sorunu — dump işlemi sürerken tablolar arasında yazma işlemleri devam ediyorsa, bazı tablolar dump'ın başındaki, bazıları sonundaki veriyi yansıtır. Sipariş tablosu güncel ama ona bağlı sipariş kalemleri tablosu eski olabilir.
2. Karakter seti ve collation uyuşmazlığı — kaynak veritabanı utf8 ile oluşturulmuş, hedef sunucuda varsayılan utf8mb4 ise Türkçe karakterler (ı, ğ, ş, ç) bozulabilir.
3. Kesme (timeout) ve bağlantı kopması — büyük tablolarda dump veya import işlemi saatler sürebilir; bağlantı kopması işlemi yarıda bırakır ve fark edilmeden eksik bir veritabanı devreye alınabilir.

Büyükweb notu: Destek ekibimize gelen taşıma taleplerinin çoğunda asıl sorun aracın yanlış kullanılması değil, taşıma öncesi hazırlığın atlanmasıdır. Doğru sırayla ilerleyen bir taşıma, saatler süren bir kriz yerine 15-20 dakikalık planlı bir bakım penceresine sığar.

Bu riskleri azaltmanın yolu, doğru aracı seçmek ve taşımayı bir "kopyala-yapıştır" işlemi değil, kontrollü bir süreç olarak yönetmektir.

mysqldump: Klasik ve Güvenilir Yöntem

mysqldump, MySQL ve MariaDB ile birlikte gelen, ek kurulum gerektirmeyen standart yedekleme/taşıma aracıdır. Küçük ve orta ölçekli veritabanları (birkaç GB'a kadar) için hâlâ en pratik seçenektir çünkü tek bir SQL dosyası üretir, okunması ve taşınması kolaydır.

Temel mysqldump Komutu

Tutarlı bir dump almak için en kritik parametre --single-transaction'dır. Bu parametre, InnoDB tabloları için işlemi tek bir transaction içinde çalıştırarak dump sırasında devam eden yazma işlemlerinin tutarsızlık yaratmasını engeller:

mysqldump \
  --single-transaction \
  --routines \
  --triggers \
  --events \
  --set-gtid-purged=OFF \
  --default-character-set=utf8mb4 \
  -u kullanici_adi -p veritabani_adi > veritabani_yedek.sql

Bu komutta neyi neden eklediğimize bakalım:

• --single-transaction: MyISAM dışındaki (InnoDB) tablolarda kilitlenme yapmadan tutarlı bir görüntü alır.
• --routines --triggers --events: Stored procedure, trigger ve event scheduler tanımlarını da dahil eder — çoğu taşıma hatası bunların unutulmasından kaynaklanır.
• --set-gtid-purged=OFF: Farklı sunucular arası taşımada GTID uyuşmazlığı hatalarını önler.
• --default-character-set=utf8mb4: Türkçe karakterlerin bozulmadan aktarılmasını garanti eder.

Büyük tablolarda mysqldump'ı satır satır (extended-insert kapalı) çalıştırmak import'u ciddi şekilde yavaşlatır; bu yüzden varsayılan --extended-insert ayarını kapatmayın.

Büyük Veritabanlarında mysqldump Optimizasyonu

Tablo sayısı fazla ama veri hacmi büyükse, dump'ı tek dosya yerine veritabanı bazında ya da tablo bazında bölmek, hem paralel çalıştırmayı hem de hata ayıklamayı kolaylaştırır:

mysqldump --single-transaction -u kullanici_adi -p \
  veritabani_adi tablo1 tablo2 > parca1.sql

İçe aktarma sırasında ise pv gibi bir araçla ilerlemeyi izlemek, saatler sürebilecek işlemlerde ne kadar yol alındığını görmek için faydalıdır:

pv veritabani_yedek.sql | mysql -u kullanici_adi -p veritabani_adi

mysqldump tek iş parçacığında (single-threaded) çalıştığı için 10-20 GB üzerindeki veritabanlarında saatlerce sürebilir. İşte tam bu noktada mydumper devreye giriyor.

mydumper/myloader: Paralel Dump ile Hız Kazanmak

mydumper, mysqldump'ın açık kaynaklı, çok iş parçacıklı (multi-threaded) alternatifidir. Büyük veritabanlarında dump ve restore süresini kat kat kısaltır çünkü tabloları paralel olarak işler ve her tabloyu ayrı dosyalara yazar.

Özellik	mysqldump	mydumper/myloader
Çalışma modeli	Tek thread	Çok thread (paralel)
Çıktı formatı	Tek büyük .sql dosyası	Tablo başına ayrı dosya
Büyük veritabanı performansı	Yavaş (saatler)	Hızlı (dakikalar-saatler)
Tutarlılık garantisi	--single-transaction	Otomatik tutarlı snapshot
Kurulum	Ön yüklü gelir	Ayrıca kurulmalı
Küçük/orta veritabanı için	İdeal	Gereksiz karmaşıklık

Kurulum

Debian/Ubuntu tabanlı sistemlerde mydumper genellikle paket deposunda bulunur:

sudo apt update
sudo apt install mydumper

Paket depoda yoksa, projenin GitHub sayfasındaki resmi .deb/.rpm paketlerini indirip kurabilirsiniz.

Paralel Dump Alma

mydumper \
  --host=localhost \
  --user=kullanici_adi \
  --password=sifre \
  --outputdir=/yedekler/mydumper_yedek \
  --rows=100000 \
  --compress \
  --build-empty-files \
  --threads=4 \
  --triggers \
  --events \
  --routines

• --threads=4: Sunucu çekirdek sayısına göre ayarlanır; VDS ortamında 4 çekirdekli bir sunucuda 4 thread makul bir başlangıçtır.
• --rows=100000: Çok büyük tabloları chunk'lara bölerek hem paralelliği artırır hem de tek bir dosyanın devasa boyuta ulaşmasını önler.
• --compress: Disk alanından tasarruf sağlar, özellikle sınırlı disk alanlı VDS paketlerinde önemlidir.

Paralel Geri Yükleme

myloader \
  --host=localhost \
  --user=kullanici_adi \
  --password=sifre \
  --directory=/yedekler/mydumper_yedek \
  --threads=4 \
  --overwrite-tables

mydumper'ın en büyük avantajı, dump sırasında FLUSH TABLES WITH READ LOCK ve tüm InnoDB tabloları için tutarlı bir snapshot alarak, mysqldump'a göre çok daha kısa sürede tutarlı bir kopya çıkarabilmesidir. 50 GB'ı aşan veritabanlarında mysqldump'ın 4-5 saat sürdüğü bir işlem, doğru thread sayısıyla mydumper'da 45-60 dakikaya inebilir.

Büyükweb notu: VDS paketlerimizde günlük otomatik yedekleme standart olarak sunulur, ancak bu, taşıma öncesi manuel bir dump almanızın yerini tutmaz. Otomatik yedek "felaket kurtarma" içindir; taşıma dump'ı ise "kontrollü geçiş" içindir — ikisini karıştırmayın.

Sıfır Kayıp İçin Taşıma Öncesi Hazırlık Checklist'i

Taşımaya başlamadan önce aşağıdaki adımları sırayla tamamlayın:

1. Kaynak ve hedef MySQL/MariaDB sürümlerini karşılaştırın. Büyük sürüm farkları (örneğin MySQL 5.7'den 8.0'a geçiş) sql_mode, kimlik doğrulama eklentisi (caching_sha2_password) ve bazı veri tiplerinde davranış farkına yol açabilir.
2. Disk alanını kontrol edin. Dump dosyası + sıkıştırılmış yedek + import sırasında geçici tablo alanı için, veritabanı boyutunun en az 2-3 katı boş disk alanı ayırın.
3. Karakter seti ve collation'ı doğrulayın. SHOW VARIABLES LIKE 'character_set%'; komutuyla kaynak sunucudaki ayarları not edin, hedefte aynısını uygulayın.
4. Kullanıcı ve yetki yapısını ayrıca yedekleyin. mysqldump/mydumper veri ve şemayı taşır ama kullanıcı hesapları ile yetkileri genelde ayrı taşınmalıdır (mysqldump --all-databases --no-data ile mysql.user tablosunu değil, GRANT ifadelerini almak daha güvenlidir). Bu konuda MySQL/MariaDB kullanıcı ve yetki yönetimi yazımızda detaylı adımlar var.
5. Uygulamayı bakım moduna alacağınız zaman penceresini planlayın. Trafiğin en düşük olduğu saat dilimini seçin ve kullanıcıları önceden bilgilendirin.
6. Tam bir yedek (full backup) alın ve ayrı bir konumda saklayın. Taşıma sırasında bir şey ters giderse geri dönüş noktanız bu olacak. Farklı yedekleme stratejilerini karşılaştırmak isterseniz veritabanı yedekleme stratejileri: full ve incremental yazımıza göz atabilirsiniz.

Bu adımların tamamı tamamlanmadan dump işlemine başlamayın — özellikle disk alanı ve karakter seti kontrolleri, taşıma sırasında en sık karşılaşılan "iş yarıda kaldı" senaryolarını önler.

Taşıma Sırasında ve Sonrasında Veri Bütünlüğü Doğrulama

Dump ve import işlemleri "hatasız tamamlandı" demek, verinin doğru olduğu anlamına gelmez. Aşağıdaki doğrulama adımlarını mutlaka uygulayın.

Satır Sayısı Karşılaştırması

Her tablo için kaynak ve hedef sunucuda satır sayılarını karşılaştırın:

SELECT table_name, table_rows
FROM information_schema.tables
WHERE table_schema = 'veritabani_adi'
ORDER BY table_name;

Bu sorguyu hem kaynakta hem hedefte çalıştırıp sonuçları diff'leyin. table_rows InnoDB'de tahmini bir değerdir; kritik tablolar için SELECT COUNT(*) FROM tablo_adi; ile kesin sayıyı doğrulayın.

Checksum ile Bütünlük Kontrolü

MySQL'in CHECKSUM TABLE komutu, iki tablonun içeriğinin bit bit aynı olup olmadığını hızlıca kontrol etmenizi sağlar:

CHECKSUM TABLE siparisler, siparis_kalemleri, kullanicilar;

Kaynak ve hedef sunucuda aynı komutu çalıştırıp checksum değerlerini karşılaştırın. Farklıysa, ilgili tabloyu yeniden dump edip import edin.

Foreign Key ve İlişkisel Bütünlük Kontrolü

Import sırasında --disable-keys veya foreign key kontrolünü geçici olarak kapatmak (SET FOREIGN_KEY_CHECKS=0;) import hızını artırır, ancak import bittikten sonra mutlaka tekrar açıp bütünlüğü doğrulayın:

SET FOREIGN_KEY_CHECKS=1;
CHECK TABLE siparis_kalemleri;

İndeksler eksik veya bozuksa uygulama sorgularınız yavaşlar ya da hatalı sonuç döner; bu yüzden import sonrası ANALYZE TABLE çalıştırmak da önemlidir. İndeks ve sorgu performansı konusunda daha fazla detay için MySQL performans optimizasyonu: index ve query cache yazımızı inceleyebilirsiniz.

Kesinti Süresini Minimize Etme: Canlı Sistemlerde Taşıma

Sıfır kayıp hedefine ulaşmanın yanında, çoğu işletme için ikinci öncelik minimum kesinti süresidir (downtime). Aşağıdaki strateji, çoğu orta ölçekli site için pratik bir yol haritasıdır:

1. Ön dump (warm-up dump): Uygulama hâlâ canlıyken tam bir dump alın. Bu, veritabanının büyük kısmını önceden hedefe aktarmanızı sağlar.
2. Bakım moduna geçiş: Uygulamayı kısa süreliğine salt-okunur ya da tamamen kapalı bakım moduna alın.
3. Fark (delta) dump: Ön dump sonrası eklenen/değişen kayıtları tespit edip (örneğin updated_at sütununa göre) sadece bu farkları aktarın — bu adım toplam kesinti süresini dakikalara indirir.
4. Son doğrulama: Yukarıdaki checksum ve satır sayısı kontrollerini hedef sunucuda yapın.
5. DNS/uygulama yönlendirmesi: Uygulamanın bağlantı dizesini (connection string) yeni sunucuya çevirin ve bakım modunu kaldırın.

Büyükweb notu: VDS'ten VDS'e taşımalarda, kaynak ve hedef sunucular aynı ağda ya da düşük gecikmeli bir bağlantıda olduğunda mysqldump | mysql şeklinde pipe ile doğrudan aktarım (ara dosya oluşturmadan) hem zaman hem disk alanı kazandırır:

mysqldump --single-transaction -u kullanıcı -p veritabani_adi | \
  mysql -h hedef_sunucu_ip -u kullanıcı -p veritabani_adi

Bu yöntem özellikle küçük-orta veritabanlarında ve iki sunucu arasında güvenilir bir bağlantı olduğunda çok etkilidir.

Taşıma Sonrası Kontrol Listesi ve Yaygın Hatalar

Import tamamlandıktan sonra atlanmaması gereken adımlar:

• Kullanıcı yetkilerini yeniden oluşturun ve FLUSH PRIVILEGES; çalıştırın.
• Auto-increment değerlerini kontrol edin. Bazı dump/import senaryolarında AUTO_INCREMENT değeri sıfırlanabilir, bu da yeni kayıtların mevcut ID'lerle çakışmasına yol açar.
• Trigger ve stored procedure'lerin doğru çalıştığını test edin. SHOW TRIGGERS; ve SHOW PROCEDURE STATUS; ile listeleyin.
• Uygulama loglarını izleyin. İlk birkaç saat, "unknown column", "foreign key constraint fails" gibi hatalara karşı log dosyalarını takip edin.
• Performans karşılaştırması yapın. Yeni sunucuda sorgu süreleri beklenmedik şekilde arttıysa, indekslerin eksiksiz taşındığından emin olun (SHOW INDEX FROM tablo_adi;).
• Eski sunucuyu hemen kapatmayın. En az birkaç gün, geri dönüş (rollback) seçeneği olarak canlı tutun.

Sık yapılan hatalardan biri de, taşıma sırasında güvenlik ayarlarının atlanmasıdır — özellikle yeni sunucuda root erişiminin dışarıya açık bırakılması ya da varsayılan portların değiştirilmemesi. Taşıma sonrası güvenlik sertleştirmesi için veritabanı güvenliği: SQL injection ve erişim kontrolü yazımızdaki önerileri uygulamanızı tavsiye ederiz.

Sıkça Sorulan Sorular

mysqldump mü yoksa mydumper mı kullanmalıyım?

Veritabanınız birkaç GB'ın altındaysa ve ek araç kurmak istemiyorsanız mysqldump yeterlidir. 10 GB üzerindeki veritabanlarında, özellikle çok çekirdekli bir VDS kullanıyorsanız, mydumper paralel çalışması sayesinde ciddi zaman kazandırır.

Taşıma sırasında siteyi kapatmak zorunda mıyım?

Tam anlamıyla sıfır kesinti (zero-downtime) için mantıksal replikasyon gibi daha karmaşık yöntemler gerekir. Ancak "ön dump + fark dump + kısa bakım penceresi" yaklaşımıyla çoğu orta ölçekli sistemde kesinti süresini birkaç dakikaya indirebilirsiniz.

mysqldump ile alınan yedek dosyası neden bu kadar büyük?

mysqldump varsayılan olarak sıkıştırma yapmaz. Çıktıyı doğrudan sıkıştırmak için mysqldump ... | gzip > yedek.sql.gz şeklinde pipe kullanabilir, mydumper'da ise --compress parametresiyle otomatik sıkıştırma elde edebilirsiniz.

Taşıma sonrası karakter bozulmaları (Türkçe karakter sorunları) nasıl önlenir?

Hem dump hem import komutlarında --default-character-set=utf8mb4 parametresini kullanın ve hedef veritabanının/tablolarının utf8mb4_turkish_ci veya utf8mb4_unicode_ci collation ile oluşturulduğundan emin olun.

Büyük bir tablo import sırasında çok yavaş ilerliyor, ne yapmalıyım?

Import sırasında innodb_buffer_pool_size değerini geçici olarak artırmak, unique_checks ve foreign_key_checks değerlerini 0 yapmak (import bitince tekrar 1'e çevirmek şartıyla) ve bulk_insert_buffer_size'ı yükseltmek işlemi ciddi ölçüde hızlandırır.

Taşıma öncesi mutlaka test ortamında deneme yapmalı mıyım?

Evet. Özellikle stored procedure, trigger ve büyük tablolar içeren veritabanlarında, canlıya geçmeden önce aynı dump/import sürecini bir test sunucusunda uygulamak, üretim ortamında karşılaşabileceğiniz sürpriz hataları önceden ortaya çıkarır.

Taşıma sırasında veri kaybı olduğunu fark edersem ne yapmalıyım?

Öncelikle uygulamayı hemen bakım moduna alın, yeni yazılan kayıtları durdurun, taşıma öncesi aldığınız tam yedeği referans alarak eksik kayıtları tespit edin ve gerekirse eski sunucudaki orijinal veritabanına geri dönün. Bu yüzden eski sunucuyu taşıma sonrası birkaç gün canlı tutmak kritik önemdedir.

Büyükweb Hizmetleri

Veritabanı taşıma sürecinde performanslı, çok çekirdekli ve disk alanı esnek bir altyapı işinizi kolaylaştırır. Kendi kaynaklarınıza tam kontrol sağlayan bir ortamda mysqldump veya mydumper işlemlerini çok daha rahat yönetebilirsiniz:

• VDS Sunucu

Taşıma planınızı birlikte değerlendirmek veya sürecin herhangi bir adımında teknik destek almak isterseniz 0850 302 60 70 numaralı satış öncesi destek numaramızdan bize ulaşabilir ya da iletişim sayfası üzerinden bizimle iletişime geçebilirsiniz.