MySQL Yanlış DELETE / DROP Sonrası PITR (Point-in-Time Recovery)
Kritik tabloda yanlışlıkla WHERE koşulsuz DELETE, UPDATE veya DROP çalıştırıldığında hata anından 1 saniye öncesine kadar veriyi kayıpsız geri getirme, temp instance ile cerrahi PITR ve binlog flashback adımları.
Operasyonel Güvenlik ve Risk Uyarısı
Bu runbook müdahale adımları içerir; birçok adım yazma etkilidir (KILL, terminate, DROP, RESIZE). Önce test ortamında deneyin, üretimde adımları sırayla ve doğrulayarak uygulayın.
1. Belirti / Symptom
- Yanlışlıkla `DELETE FROM table;` (WHERE koşulsuz) veya hatalı `DROP TABLE / TRUNCATE` çalıştırıldı.
- Müşteri veya uygulama verisi eksik; canlı veri kaybı alarmı geldi.
- Hata zaman damgası yaklaşık olarak biliniyor (örnek: `2026-11-05 10:15:23`).
2. Etki / Impact
P1 Kritik Kesinti (SEV1). Veri kaybı iş operasyonlarını durdurur; yeni yazmalar devam ederse veri tabanındaki bozulma derinleşir ve üzerine yazılan verilerin kurtarılması imkansızlaşır.
3. Teşhis / Diagnosis
- Uygulama yazma trafiğini durdurun veya ilgili tabloyu kilitleyin:
LOCK TABLES mydb.orders WRITE;SHOW MASTER STATUS; -- File ve Position bilgisini not edin
SELECT @@GLOBAL.gtid_executed;| Mevcut Yedek Durumu | Önerilen Kurtarma Yöntemi | RPO / Kesinti Beklentisi |
|---|---|---|
| **MySQL Enterprise Backup (MEB) var** | MEB restore -> temp instance -> binlog replay | En hızlı, minimum veri kaybı |
| **mysqldump / Logical backup var** | Full restore -> temp instance -> binlog replay | Küçük/orta ölçekte güvenli |
| **Sadece binlog var (Yedek eski)** | Binlog flashback (`my2sql` / `binlog2sql`) | Çok hızlı, sadece DML hatalarında geçerli |
4. Müdahale / Response
### En Hızlı Yöntem: İzole Temp Instance ile Cerrahi PITR
#### Adım 1: Son Tam Yedeği (Full Backup) Temp Sunucuya Restore Edin
# MEB (MySQL Enterprise Backup) örneği
mysqlbackup --backup-dir=/backups/full --datadir=/data/temp_restore copy-back-and-apply-log
# veya mysqldump yedeği örneği
mysql -h temp_instance -u root -p < /backups/full_2026-11-04.sql#### Adım 2: Binlog'ları Hata Anından 1 Saniye Öncesine Kadar Uygulayın
Hata anı: `2026-11-05 10:15:23` ise stop zamanı: `2026-11-05 10:15:22`
# Yöntem A: GTID tabanlı point-in-time replay
mysqlbinlog --skip-gtids --stop-datetime="2026-11-05 10:15:22" \
/var/log/mysql/binlog.000145 /var/log/mysql/binlog.000146 | mysql -h temp_instance -u root -p
# Yöntem B: binlog2sql ile tek tablo için ters DML (Flashback)
python binlog2sql.py -h primary -u dba -p --start-datetime "2026-11-05 09:00:00" \
--stop-datetime "2026-11-05 10:15:22" -d mydb -t orders --flashback > rollback.sql#### Adım 3: Kurtarılan Veriyi Temp Sunucuda Doğrulayın
-- temp_instance üzerinde
SELECT COUNT(*) FROM mydb.orders;
SELECT * FROM mydb.orders ORDER BY id DESC LIMIT 5;#### Adım 4: Kurtarılan Tabloyu Production'a Güvenle Geri Yazın
# Yöntem 1: Cerrahi dump alıp sadece eksik satırları aktarma
mysqldump -h temp_instance mydb orders --no-create-info --where="id IN (...)" > recovery.sql
mysql -h primary mydb < recovery.sql
# Yöntem 2: Tablo seviyesinde import
mysqldump -h temp_instance mydb orders > orders_recovered.sql
mysql -h primary mydb < orders_recovered.sql5. Doğrulama / Verification
- Satır sayısı ve veri bütünlüğünü doğrulayın:
SELECT @@GLOBAL.gtid_executed;
CHECKSUM TABLE mydb.orders;- İlgili tablonun en son işlem kimliği (Max ID) ve zaman damgasını kontrol edin.
- Uygulama servislerini kontrollü başlatarak smoke test yapın.
6. Geri Alma / Rollback
- Geri yüklenen veride tutarsızlık görülürse, aktarılan geçici tabloyu kaldırın ve temp instance üzerindeki ham veriyi tekrar inceleyin.
- **Önleme Checklist — dbaguide Standardı:**
- [ ] Tüm uygulama kullanıcılarında `sql_safe_updates = 1` zorunlu mu?
- [ ] `binlog_expire_logs_seconds = 604800` (en az 7 günlük binlog saklama)?
- [ ] Günlük tam yedek + saatlik binlog arşivleme harici S3/GCS depolamasına aktarılıyor mu?
- [ ] Production ortamında fiziksel `DELETE` yerine `SOFT DELETE` (`deleted_at`) + 7 günlük arşiv politikası uygulandı mı?
- [ ] `my2sql` / `binlog2sql` triyaj aracı tüm DBA yönetim sunucularında hazır mı?
- **İletişim & Post-Mortem:**
- P1 incident masasını açın (`#incident-response`).
- Olaydan sonraki 24 saat içinde post-mortem hazırlayın: Hangi kullanıcı, hangi servis hesabı, neden WHERE koşulu yoktu?
Mühendislik Triadı: Doğrudan Teşhis Scriptleri
Bu runbook kriz müdahalesinde darboğazı tespit etmek için önerilen hazır SQL / Shell scriptleri:
MySQL Replikasyon Durumu ve Gecikme Kontrolü
IO/SQL thread durumunu, Seconds_Behind_Source değerini ve son hataları kontrol eder. Replica sağlığını hızlıca doğrulamak için kullanılır.
MySQL Binary Log Boyutu ve Saklama Süresi
Binary log dosyalarını, toplam boyutlarını ve saklama ayarını gösterir. Disk dolması ve point-in-time recovery penceresi için önemlidir.