ALTER TABLE neden risklidir?
Küçük tabloda ALTER TABLE hızlıdır ve unutulur. Büyük tabloda ise aynı komut uzun sürebilir, metadata lock bekletebilir ve uygulama sorgularını kuyruğa sokabilir. En kötü tarafı, bu etki bazen komutun başında değil ortasında hissedilir.
Bu yüzden MySQL şema değişikliğinde ilk soru “komut doğru mu?” değil, “bu komut bu tablo boyutunda nasıl davranacak?” olmalıdır.
- Tablo boyutu ve indeks sayısı değişiklik süresini etkiler.
- Metadata lock kısa sürse bile bekleyen transactionlar yüzünden uzayabilir.
- Online DDL her değişiklik türünde aynı davranmaz.
- Rollback, her zaman eski ALTERı tersine çalıştırmak kadar basit değildir.
Önce lock ve tablo durumunu okuyun
Şema değişikliğinden önce uzun transaction ve metadata lock riski görülmelidir. Büyük bir migrationın ortasında “kim kilidi tutuyor?” diye bakmak yerine, bunu preflight kontrolü haline getirin.
Uzun transaction ve lock kontrolü
SHOW FULL PROCESSLIST; SELECT trx_id, trx_started, trx_state, trx_query FROM information_schema.innodb_trx ORDER BY trx_started LIMIT 20; SELECT table_schema, table_name, table_rows FROM information_schema.tables WHERE table_schema = DATABASE() ORDER BY table_rows DESC LIMIT 20;
Online DDL beklentisini test edin
MySQL sürümü, tablo motoru, indeks tipi ve yapılacak değişiklik online davranışı etkiler. ALGORITHM=INPLACE veya LOCK=NONE kullanmak iyi bir niyet beyanıdır; ama gerçek tablo üzerinde prova yapmadan kesin güvence değildir.
Çok büyük tablolarda gh-ost veya pt-online-schema-change gibi gölge tablo yaklaşımı daha güvenli olabilir. Bu araçlar da sihirli değildir; trigger/binlog etkisi, replikasyon gecikmesi ve cutover anı izlenmelidir.
Daha açık niyetli ALTER örneği
ALTER TABLE orders ADD COLUMN source varchar(32) NULL, ALGORITHM=INPLACE, LOCK=NONE;
Bu sözdizimi her değişikliği risksiz yapmaz. Önce test ortamı/prod benzeri veriyle test edin, sonra bakım penceresi ve rollback eşiği yazın.
Release sırası şema değişikliğini belirler
Güvenli şema değişikliği çoğu zaman iki aşamalıdır: önce geriye uyumlu kolon eklenir, sonra uygulama yeni alanı kullanır, en son eski alan temizlenir. Tek yayına almada kolon silip kodu değiştirmek, rollback şansını azaltır.
TürkDB tarafında bakım penceresi ve PITR kontrolünü yayına alma kontrol listesine koymak iyi alışkanlıktır. Şema değişikliği teknik olduğu kadar operasyonel bir olaydır.
MySQL DDL release notu
1. Yedekleme/PITR penceresi kontrol edildi 2. Uzun transaction ve processlist temiz 3. Kolon geriye uyumlu eklenecek 4. Uygulama yeni kolonu opsiyonel okuyacak 5. Metrikler 30 dakika izlenecek 6. Eski kolon ayrı bakım penceresinde kaldırılacak