Destekle iletişim

E-postayla, genellikle iki gün içinde yanıt veririz.

Google reCAPTCHA, kötüye kullanıma karşı bu gönderimi denetler; bu sırada veriler Google'a aktarılır. Komut dosyası yalnızca bu form açıldığında yüklenir.

← Tüm yazılar

Veritabanı şeması aslında nerede duruyor

Bu hizmetin yaptığı her şey sürüm kontrolünde. En azından kod öyle. Üzerinde çalıştığı veritabanı 32 tablodan oluşuyor ve bunların 15 tanesinin depoda hiçbir yerde tanımı yok — ne bir CREATE TABLE, ne bir şema dosyası, hiçbir şey. Bir döküm 32 tablonun hepsini yapısı bozulmadan geri yükler; deponun tutmadığı şey, bu yapının ikinci ve bağımsız bir kopyasıdır.

17 tablo tanımlı 15 tanımsız 21 indeks kodla oluşturulmuş 11 yalnızca veritabanında 32 tablo, 32 ikincil indeks, 0 şema dosyası

Bu rakamlar, canlı veritabanının depodaki 736 dosya ve 5.671.710 karakterle karşılaştırılmasından geliyor. Tahmin değiller.

Bir şemanın yarısı nasıl kaybolur

Bu bir dikkatsizlik değil ve bunu yazmaya değer kılan da bu. Adımların her biri tek tek makuldü.

Bugünkü kod tabanı ortaya çıkmadan önce oluşturulan tablolar hiç yazıya geçirilmedi, çünkü o zamanlar öylece oradaydılar. O zamandan beri eklenen tablolar geçiş betikleriyle geldi ve bu betikler depoda mevcut — 17 tanım da oradan geliyor. Sonradan eklenen sütunlar ise komut isteminde yazılan tek satırlık bir ALTER TABLE komutuyla eklendi, çünkü bir saniye süren bir değişiklik için betik yazmaktansa onu yazmak daha hızlıydı.

En kötü durum indekslerdir. Bir indeks, bir şey yavaş olduğunda, tam yavaş olduğu anda eklenir ve sorunu hemen çözer. Geride hiçbir iz kalmaz; gözden geçirilecek bir şey yoktur, unutulduğunda başarısız olan bir şey yoktur. Buradaki otuz iki ikincil indeksin on biri tam da bu nedenle var ve hiçbir yerde kayıtlı değil.

Sayaçların kendisini tutan tablo, 166.438 satırıyla, depoda tanımı olmayan on beş tablodan biri.

Gerçekte ne bozuluyor

Pek bir şey değil, ta ki belirli bir ana kadar: veritabanı bir dökümden geri yüklendiğinde.

Döküm yapıyı da taşır, bu yüzden doğrudan bir geri yükleme sorunsuzdur. Tehlike, bir tabloyu geri yüklemek yerine yeniden kuran her yoldadır — başka bir makineye taşınmak, seçili tabloları içe aktarmak, bir tabloyu betikle yeniden oluşturmak. Veriler geri gelir, indeksler ise sessizce gelmez. Hiçbir şey başarısız olmaz. Sorgular doğru yanıtları döndürür. Yalnızca daha uzun sürerler ve nedeni görünmez, çünkü indeksin ne olduğunun tek kaydı, artık o indekse sahip olmayan makinedir.

Adını koymaya değer hata türü şu: eksik bir indeks hata üretmez, daha yavaş bir doğru yanıt üretir. Bunun bir testi yok, çünkü testler geçiyor.

Bu arada ne yapıyoruz

Şema bugün depoda değil ve durumun doğru tarifi de bu. Yerinde olan şey tam bir çözümden daha dar kapsamlı, ama gerçekten bir bedeli olan durumu karşılıyor:

Yıkıcı herhangi bir işlemden önce alınan ve web kök dizininin dışında tutulan bir döküm. Varsayılmak yerine en az bir kez gerçekten yapılmış bir geri yükleme. Ve her geri yüklemeden sonra denetlenen, yalnızca çalışan veritabanında var olduğu bilinen indekslerin kısa bir listesi — çünkü makineye hangi indekslere sahip olduğu sorulabilir ve yanıt, bir önceki sorulduğundaki yanıtla karşılaştırılabilir.

Bunun genel hâli veritabanlarından daha fazlası için geçerli. Bir sistemin bir parçası yalnızca çalışan sistemde varsa, onun ikinci bir kopyası yoktur. Herhangi bir altyapı parçası için sorulmaya değer soru, yedeğinin alınıp alınmadığı değil, makine ortadan kalksa depodan neyin yeniden kurulamayacağıdır. Burada yanıt on beş tablo ve on bir indeks; bunu belirlemek bir öğleden sonra sürdü ve artık bilinmeyen bir şey değil, bir liste.

Güncelleme: Eylül 2026

Bu yazı yayımlandıktan beş gün sonra çalışma dizini depoya işlendi: 26 dosya ve 4.058 satır; aralarında 28 Ağustos ile 1 Eylül arasında yazılmış ve o zamana kadar yalnızca çalışan makinede bulunan on bir geçiş betiği de vardı. Bu işin kolay yarısıydı — yazılmış ama hiç kayda geçirilmemiş kod.

Ölçüm 1 Eylül 2026'da aynı şekilde tekrarlandı: canlı veritabanı, git tarafından izlenen her şeyle karşılaştırıldı.

Tablolar4630 tablonun depoda bir CREATE TABLE tanımı var, 16 tablonun yok
İkincil indeksler4332 tanesi depodaki kodla oluşturuluyor, 11 tanesi yalnızca çalışan veritabanında
Geçiş betikleri109sürüm kontrolünde
30 tablo tanımlı 16 tanımsız 32 indeksin dosyası var 11 yalnızca veritabanında 46 tablo, 43 ikincil indeks, 0 şema dosyası

Önemli olan sayı değişmedi. 27 Ağustos günü on bir ikincil indeks, çalışan veritabanı dışında hiçbir yerde yoktu. 1 Eylül günü hâlâ on bir tane var. Arada on bir indeks daha eklendi ve her biri bir geçiş betiğiyle geldi: alışkanlık değişti, borç değişmedi.

Bu on bir indeks beş tabloda duruyor — sayaçlar, diller, yönlendiren sayfalar, hariç tutma listesi ve olay günlüğü. Beşi de bugünkü kod tabanından eski; onlar için hiçbir şeyin yazıya geçirilmemesinin nedeni de tam olarak bu. Şimdi bir dosya yazmak, yıllar önce komut isteminde yazılanı çalışan bir sunucudan yeniden kurmak demek olurdu.

Yani ağustos ayındaki tespit geçerliliğini koruyor. Şema hâlâ depoda değil ve bir tabloyu geri yüklemek yerine yeniden kuran bir işlem, on bir indeksi yine tek kelime etmeden düşürürdü. Değişen şey daha dar kapsamlı: o zamandan beri eklenen her şey geride bir dosya bıraktı.

Reklam