Türkiye (Türkçe)
Almanya (German)
Worldwide (English)
Önce veri güvenliğiYedek ve log kanıtını koru
Halkalı merkez mahallesi fatih cd ozgur apt no 46 , Küçükçekmece , İstanbul , 34303 , TR
MySQL veya MariaDB durduğunda Plesk üzerindeki dinamik siteler ve panel veritabanı işlemleri etkilenebilir. Disk doluluğu, bozuk mysql sistem tabloları, InnoDB tablespace, hatalı my.cnf, RAM veya PID/socket sorunu veri kaybı riski nedeniyle kontrollü incelenmelidir.
Failed to start MariaDB database server
Fatal error: Can't open and lock privilege tables
Table mysql.user doesn't exist
InnoDB: Cannot open tablespace
No space left on deviceServisin başlamaması tek başına veritabanının bozuk olduğunu kanıtlamaz. Disk veya inode doluluğu, hatalı yapılandırma parametresi, düşük RAM, port çakışması ve sistem tabloları da aynı sonucu üretir.
Can’t open privilege tables veya mysql.user doesn’t exist mesajları, mysql sistem veritabanındaki tabloların eksik ya da bozuk olduğunu gösterir. Kullanıcı veritabanlarından farklı ele alınmalıdır.
InnoDB tablespace veya page-size mismatch hataları belirli müşteri veritabanının bozulmasına işaret edebilir. innodb_force_recovery yalnız veri çıkarma amacıyla ve kademeli değerle kullanılmalıdır.
No space left on device, MariaDB’nin geçici dosya, redo log veya PID yazmasını engelleyebilir. Önce disk ve inode sorunu çözülmeden servisi tekrar tekrar başlatmak faydasızdır.
Plesk repair db Plesk’in kendi psa veritabanı tutarlılığını kontrol eder; tüm müşteri veritabanlarını otomatik onaran genel bir komut değildir.
ibdata1, ib_logfile, redo log veya müşteri .ibd dosyalarını forum önerisiyle silmek geri dönüşü olmayan veri kaybı oluşturabilir. Servis başlamıyorsa önce tam veri dizini kopyası ve mevcut yedeklerin doğruluğu değerlendirilmelidir.
E-postada, tarayıcıda veya SSH günlüğünde gördüğünüz ifadeyi aratın. Her kartta anlam, muhtemel neden ve güvenli ilk işlem bulunur.
Anlamı: MariaDB privilege tablosunu bulamamıştır.
Muhtemel neden: Eksik/bozuk mysql sistem tabloları veya yarım yükseltme.
Anlamı: Yetki tabloları açılamadığı için servis güvenli şekilde başlayamamıştır.
Muhtemel neden: Dosya bozukluğu, yanlış format, izin veya eksik tablo.
Anlamı: InnoDB belirli tablespace dosyasını açamamıştır.
Muhtemel neden: Kayıp .ibd, bozuk metadata, disk veya yanlış dosya taşıma.
Anlamı: MariaDB yeni dosya veya geçici veri yazamamıştır.
Muhtemel neden: Disk kapasitesi veya inode yüzde 100.
Anlamı: MariaDB yapılandırmasında desteklenmeyen veya yanlış yazılmış değişken vardır.
Muhtemel neden: Sürüm yükseltmesi sonrası eski parametre veya yazım hatası.
Anlamı: Servis süreci çalışsa da kontrol betiği beklenen PID dosyasını bulamıyordur.
Muhtemel neden: Yanlış pid-file yolu, eski lock veya birden fazla servis birimi.
Anlamı: Servis kapanmış fakat eski lock dosyası kalmıştır.
Muhtemel neden: OOM veya başarısız kapanış.
Anlamı: MariaDB işletim sistemi open file limitine ulaşmıştır.
Muhtemel neden: Çok tablo/bağlantı veya düşük LimitNOFILE.
Bu ifadeyle eşleşen kayıt bulunamadı.
Komutlar root erişimi içindir. Önce yalnızca durum ve log toplayın; nedeni görmeden kalıcı ayar değiştirmeyin.
systemctl status mariadb --no-pager 2>/dev/null || systemctl status mysql --no-pager 2>/dev/null || systemctl status mysqld --no-pagerDağıtıma göre MySQL/MariaDB servis durumunu gösterir.
journalctl -u mariadb -n 150 --no-pager 2>/dev/null
tail -n 150 /var/log/mariadb/mariadb.log 2>/dev/null || tail -n 150 /var/log/mysql/error.log 2>/dev/null || tail -n 150 /var/log/mysqld.log 2>/dev/nullBaşlangıç başarısızlığının ilk teknik nedenini gösterir.
df -hT
df -iVeri, tmp ve log partitionlarında alan/inode durumunu gösterir.
free -h
journalctl -k --since "2 hours ago" | grep -Ei "oom|out of memory|killed process"MariaDB’nin bellek baskısı nedeniyle öldürülüp öldürülmediğini gösterir.
my_print_defaults mysqld 2>/dev/null
grep -RniE 'innodb_force_recovery|pid-file|datadir|socket' /etc/my.cnf /etc/my.cnf.d /etc/mysql 2>/dev/nullEtkin ve riskli MariaDB yapılandırma satırlarını bulur.
ss -lntp | grep :3306
ps -ef | grep -E "[m]ysqld|[m]ariadbd"3306 portu ve çalışan gerçek veritabanı süreçlerini gösterir.
plesk repair dbPlesk psa veritabanı tutarlılığını etkileşimli kontrol eder; müşteri DB onarımından farklıdır.
Servisi zorlamadan önce log, disk, RAM, yapılandırma ve veri bütünlüğü sırasıyla değerlendirilmelidir.
MariaDB/MySQL sürümü ile ilk error satırı not edilmelidir. Son satır çoğu zaman yalnız başarısız sonucu gösterir.
Alan veya RAM yoksa veritabanı onarımına geçmeden önce sistem kaynağı güvenli biçimde açılmalıdır.
df -hT && df -i && free -hSon güncelleme veya manuel optimizasyon sonrası eklenen unsupported variable satırlarını tespit edin.
mysql.* tabloları, Plesk psa veritabanı ve müşteri veritabanları farklı kurtarma prosedürleri gerektirir.
innodb_force_recovery yazma işlemi için normal çalışma modu değildir. En düşük değerle dump alma planı yapılır.
Servis açıldıktan sonra mysqlcheck/dump doğrulaması, Plesk DB kontrolü ve uygulama testleri yapılır.
Alan açıldıktan sonra error log, tmp dizini, redo log ve filesystem durumu kontrol edilir; rastgele InnoDB dosyası silinmez.
Paket sürümü, system table upgrade ve eski my.cnf parametreleri kontrol edilir.
Servis çalışıyorsa ilgili DB için tablo bazlı yedek/kurtarma yapılır; tüm datadir etkilenmez.
RAM tüketen süreçler, MariaDB buffer ayarları ve systemd OOM logu analiz edilir.
Gerçek mysqld süreci olmadığından emin olmadan PID veya lock dosyası silinmez.
Hayır. Plesk’in psa veritabanı tutarlılığına odaklanır. Müşteri veritabanı ve InnoDB bozulması ayrı incelenmelidir.
Yalnız acil veri çıkarma için, en düşük değerden başlanarak ve uzman kontrolünde kullanılmalıdır. Normal yazma modu değildir.
Bazı stale lock durumlarında geçici çözebilir; fakat disk, bozuk tablo veya my.cnf hatasını çözmez ve log kanıtını azaltabilir.
Yarım yükseltme, dosya bozulması, yanlış datadir geri yüklemesi veya sistem tablo format uyumsuzluğu neden olabilir.
Önce hangi mountun dolduğunu ve neyin alan tükettiğini belirleyin. Veritabanı dosyaları doğrudan silinmemelidir.
Gerçek açık dosya sayısı, table_open_cache ve systemd LimitNOFILE birlikte ölçülerek dengeli ayarlanmalıdır.
Hayır. Tabloların okunması, dump alınması, uygulama bağlantısı ve restart sonrası kalıcılık doğrulanmalıdır.
cPanel, WHM, CloudLinux, LiteSpeed, MariaDB, Exim ve güvenlik katmanlarını birlikte analiz ederek yalnızca servisi kaldırmak yerine arızanın temel nedenini gideriyoruz.