MariaDB / MySQL InnoDB Teknik Rehberi

MariaDB Başlamıyor: InnoDB Corruption ve Recovery Rehberi

InnoDB bozulması veya crash recovery hatası veri kaybı riski taşıyan kritik bir durumdur. Amaç servisi normal kullanıma zorlamak değil, önce fiziksel kopya ve yedek almak, en düşük recovery seviyesinde okunabilir veriyi dışarı çıkarmaktır.

InnoDB CorruptionCrash Recoveryinnodb_force_recoveryPhysical BackupLogical Dump

Hata Mesajlarını İncele Teknik Destek Al

database.log

InnoDB: Database page corruption on disk or a failed file read
InnoDB: Plugin initialization aborted with error Data structure corruption

01Hata mesajını aynen kaydedin

02Servis, port ve disk durumunu ayırın

03Yetki ve uygulama config’ini doğrulayın

04Yedek ve kontrollü değişiklik uygulayın

Teknik açıklama

InnoDB Corruption Recovery ne anlama gelir?

İlk ayrım, sorunun uygulama bağlantı bilgilerinden mi, veritabanı servisinden mi, ağ katmanından mı yoksa veri dosyasından mı kaynaklandığıdır. Tarayıcıdaki genel mesaj yerine motorun kendi error logu esas alınmalıdır.

cPanel ve Plesk yönetimi kolaylaştırır ancak servis, port, kullanıcı, rol ve veri bütünlüğü kontrolleri veritabanı motorunun native araçlarıyla doğrulanmalıdır.

Yetki sorunlarında en az yetki ilkesi korunmalı; servis ve recovery sorunlarında veri dosyalarına dokunmadan önce fiziksel veya mantıksal yedek hazırlanmalıdır.

Bir ayarı büyütmek veya güvenliği gevşetmek geçici rahatlama sağlayabilir. Kalıcı çözüm, hatanın hangi katmanda başladığını ölçerek en küçük değişikliği uygulamaktır.

ibdata1, redo log, undo veya .ibd dosyalarını rastgele silmeyin.

Log mesajları

Hata kodları, anlamları ve ilk güvenli işlem

8 kayıt

01kritik

Database page corruption on disk

Anlamı: InnoDB sayfası bozuk.

Muhtemel neden: Disk, I/O veya ani kesinti.

02kritik

Plugin initialization aborted

Anlamı: InnoDB başlatılamadı.

Muhtemel neden: Tablespace, redo veya dictionary bozulması.

03kritik

Unable to open ibdata1

Anlamı: Shared tablespace açılamıyor.

Muhtemel neden: Dosya eksik, izin veya disk hatası.

04kritik

Tablespace is missing for a table

Anlamı: Dictionary tabloyu biliyor fakat .ibd yok.

Muhtemel neden: Yarım restore veya dosya kaybı.

05uyari

Crash recovery failed

Anlamı: Redo ile tutarlı durum oluşturulamadı.

Muhtemel neden: Bozuk veya eksik redo.

06uyari

Page checksum mismatch

Anlamı: Sayfa checksum sağlamıyor.

Muhtemel neden: Storage corruption.

07uyari

innodb_force_recovery is set

Anlamı: Sunucu emergency modda.

Muhtemel neden: Eski recovery ayarı bırakılmış.

08bilgi

Starting crash recovery

Anlamı: Normal çökme kurtarması çalışıyor.

Muhtemel neden: Önceki kapanış temiz değil.

Bu ifadeyle eşleşen kayıt bulunamadı.

Kopyalanabilir kontroller

SSH, SQL ve servis teşhis komutları

InnoDB logları

journalctl -u mariadb -u mysqld -n 300 --no-pager

Bozulma türünü gösterir.

Disk ve kernel

df -hT
df -i
journalctl -k -n 300 --no-pager | grep -iE 'i/o error|ext4|xfs|nvme|ata|corrupt'

Storage hatalarını gösterir.

Fiziksel kopya

systemctl stop mariadb 2>/dev/null || systemctl stop mysqld
rsync -aHAX --numeric-ids /var/lib/mysql/ /guvenli-alan/mysql-fiziksel-kopya/

Veri dizini kopyası alır.

Recovery seviyesi

my_print_defaults mysqld | grep -i innodb_force_recovery

Aktif recovery değerini gösterir.

Mantıksal dump

mariadb-dump --all-databases --quick --skip-lock-tables > kurtarma.sql

Okunabilen veriyi dışarı çıkarır.

Tablo kontrolü

mariadb-check --all-databases --check-upgrade

Normal moda dönüşte tabloları kontrol eder.

Barındırma ortamına göre

cPanel, Plesk ve panelsiz sunucu kontrolleri

cPanel / WHM

MariaDB / MySQL InnoDB hatasını cPanel servis, kullanıcı ve kaynak katmanlarıyla birlikte inceleyin.

Panel servis durumunu motorun kendi error loguyla aynı zaman aralığında karşılaştırın.
Hesap kullanıcıları, veritabanı eşlemesi ve kaynak limitlerini doğrulayın.
Panel dışı değişiklik yapmadan önce yedek ve geri dönüş hazırlayın.

Plesk Obsidian

MariaDB / MySQL InnoDB için Database Servers, abonelik kullanıcıları ve repair araçlarını kontrollü kullanın.

Tools & Settings > Database Servers bölümünde doğru instance’ı doğrulayın.
Abonelik kullanıcıları ve uzak erişim kurallarını minimum kapsamla kontrol edin.
Repair komutlarını önce denetim ve güncel yedekle uygulayın.

Panelsiz Sunucu

MariaDB / MySQL InnoDB servis, port, log ve native istemci araçlarıyla doğrudan teşhis edin.

Doğru servis ve instance’ı belirleyin.
Hata anını uygulama ve motor loglarıyla eşleştirin.
Config veya veri dosyası değişikliğini küçük ve geri alınabilir tutun.

Kesinlikle yapmayın

ibdata1, redo log, undo veya .ibd dosyalarını rastgele silmeyin.
Yüksek recovery seviyesinde normal yazma trafiği açmayın.
Fiziksel kopya olmadan recovery denemesi yapmayın.
Disk I/O hatası sürerken aynı diske restore yapmayın.

Çözüm sonrası doğrulama

Veri temiz instance üzerinde recovery ayarı olmadan açılıyor.
Tablo ve uygulama kritik sorguları başarılı.
Yeni I/O veya corruption kaydı yok.
Test restore tamamlandı.

İç SEO içerik kümesi

İlgili veritabanı hata çözümleri

MySQL Error 1045MySQL ve MariaDB Error 1045 Access denied for user hatasını kullanıcı, parola, host, yetki ve authentication plugin kontrolleriyle çözün.

→

MySQL/MariaDB BağlanmıyorMySQL veya MariaDB servisi başlamıyor ve bağlantı reddediliyorsa socket, port 3306, disk, izin, SELinux ve yapılandırmayı kontrol edin.

→

MySQL Server Has Gone AwayMySQL server has gone away ve lost connection during query hatasını timeout, max_allowed_packet, ağ, büyük sorgu ve servis kesintisi kontrolleriyle çözün.

→

MySQL Error 1040MySQL ve MariaDB Error 1040 Too many connections hatasını max_connections, connection pool, uyuyan bağlantılar ve yavaş sorgu analiziyle çözün.

→

MySQL Error 1064MySQL Error 1064 SQL syntax hatasını eksik tırnak, virgül, parantez, reserved keyword, sürüm farkı ve dump import kontrolleriyle çözün.

→

PostgreSQL AuthenticationPostgreSQL password authentication failed, no pg_hba.conf entry ve connection refused hatalarını rol, parola, host ve listen_addresses kontrolleriyle çözün.

→

Resmî kaynaklar

Üretici dokümantasyonu

MariaDB InnoDB Recovery Modes MariaDB InnoDB Redo Log MySQL Forcing InnoDB Recovery

Sık sorulan sorular

InnoDB Corruption Recovery hakkında sorular

InnoDB Corruption Recovery hatasında ilk kontrol nedir?

Tam hata mesajı ve zaman bilgisi kaydedilir; ardından servis, port, disk ve uygulama config’i birbirinden ayrılır.

Panelden servisi yeniden başlatmak yeterli mi?

Geçici olarak çalıştırabilir ancak kök neden motorun error logu, native istemci ve kaynak metrikleriyle doğrulanmalıdır.

Uzak veritabanı portu herkese açılmalı mı?

Hayır. Yalnız gereken özel ağ, VPN veya belirli kaynak IP’leri için firewall ve motor erişim kuralı kullanılmalıdır.

Veritabanı kullanıcısına tam yetki vermek doğru mu?

Uygulamalar en az yetki prensibiyle yalnız gereken database, schema ve işlemlere erişmelidir.

Hata çözülmeden önce yedek alınmalı mı?

Yetki ve config sorunlarında bile güncel yedek önerilir; corruption, servis başlamama veya dosya müdahalesinde zorunludur.

Komutları doğrudan üretimde çalıştırabilir miyim?

Önce motor, sürüm, dosya yolu ve yetkiler doğrulanmalı; veri değiştiren komutlar test veya yedekli ortamda uygulanmalıdır.

Bu sayfa sıralama garantisi verir mi?

Hayır. Teknik kalite, gerçek kullanıcı faydası, iç linkleme, site otoritesi, hız ve Search Console verileri birlikte sonuç üretir.

EKA YAZILIM VE BİLİŞİM SİSTEMLERİ

Veritabanı sorununu veri kaybı oluşturmadan çözelim

MySQL, MariaDB, PostgreSQL, MongoDB, SQLite ve SQL Server bağlantı, yetki, performans, taşıma ve kurtarma süreçlerini birlikte analiz ediyoruz.

Teknik Destek Al WhatsApp

Custom Server Services

Standard Servers