ServBay MariaDB/MySQL Paketleri Hata Ayıklama Rehberi

Genel Bakış

MariaDB ve MySQL, endüstride lider olan açık kaynaklı ilişkisel veritabanı yönetim sistemleridir ve çeşitli web uygulamaları ile iş senaryolarında yaygın olarak kullanılmaktadır. ServBay, macOS ortamında birden fazla MariaDB/MySQL sürümünü entegre ederek geliştiricilere hızlı ve pratik bir yerel veritabanı ortamı sağlar. Stabilite yönünden güçlü olmalarına rağmen, geliştirme ya da çalışma sırasında paketlerin başlatılamaması, bağlantı hatası ya da performans düşüşü gibi sorunlarla karşılaşmak mümkündür.

Bu rehber, ServBay kullanıcılarına MariaDB/MySQL paketlerinde sık karşılaşılan arızaları teşhis etme ve çözme konusunda yardımcı olmayı amaçlamaktadır. Yaygın sorunlar, tanı adımları ve pratik çözümler ile birlikte ServBay ortamına özgü komutlar ve dosya yolları ayrıca belirtilmiştir.

Önemli Uyarılar:

• Verinizi mutlaka yedekleyin! Veri ya da yapılandırmalarda değişikliğe yol açabilecek herhangi bir işlemi uygulamadan önce veritabanınızı mutlaka yedekleyin. ServBay, yerleşik yedekleme özelliği sunar, düzenli yedekleme şiddetle tavsiye edilir.
• Komutlar ve yol örneklerinde belirli sürüm numaraları (örn. 11.3 veya 11.5) kullanılmıştır. Kendi ServBay ortamınızda kurulu ve aktif olan MariaDB/MySQL sürümüne göre bu numaraları değiştirin. Yüklü ve etkin paket sürümünü ServBay uygulama arayüzünde görebilirsiniz.
• Komutlardaki <username>, <database>, <your_backup.sql> gibi ifadeler birer yer tutucudur; kendi kullanıcı adınız, veritabanı adınız ve yedek dosyanızla değiştirin.
• Bu rehberde örnekler ve açıklamalar macOS işletim sistemi odağında hazırlanmıştır.

Genel Ön Tanı Adımları

Spesifik problem tespitinden önce aşağıdaki temel kontrolleri yapınız:

1. ServBay Paket Durumunu Kontrol Edin: ServBay arayüzünü açıp, işlem yapmak istediğiniz MariaDB/MySQL paketinin etkin ve "Çalışıyor" olarak işaretli olup olmadığını kontrol edin. Ayrıca aşağıdaki komutla durum kontrolü yapabilirsiniz:

   servbayctl status mariadb <version>
   # Örneğin, MariaDB 11.3 versiyonunun durumunu kontrol etmek için:
   servbayctl status mariadb 11.3

2. ServBay Uygulama Loglarını İnceleyin: ServBay, paket başlatma ya da yönetim sırasındaki hataları kendi log bölümünde gösterir veya ana log dosyasından ulaşabilirsiniz.
3. MariaDB/MySQL Hata Kayıtlarını Kontrol Edin: Paket başlatılamadığında ya da çalışırken hata veriyorsa, bunun nedeni genellikle hata kayıt dosyasında bulunur:

   /Applications/ServBay/logs/mariadb/<version>/<version>.err
   # Örneğin, MariaDB 11.3 son 50 satırlık hata kaydı:
   tail -n 50 /Applications/ServBay/logs/mariadb/11.3/11.3.err

   Kayıtların sonundaki hata mesajlarını dikkatlice inceleyin; genellikle doğrudan probleme işaret ederler.

Sık Karşılaşılan Sorunlar ve Çözümleri

1. Bağlantı Hatası: SQLSTATE[HY000] [2002] No such file or directory

Bu hata, istemci ile MariaDB/MySQL sunucusu arasındaki Unix socket dosyası üzerinden bağlantı kurulamadığı zaman görülür. macOS'ta Unix soketi, yerel süreçler arası iletişim için kullanılır ve TCP/IP bağlantısına göre daha düşük maliyetlidir. Bir uygulama ya da komut satırı aracı, belirtilen yolda bir socket dosyası bulamazsa bu hata alınır.

Muhtemel Nedenler & Çözümler:

• MariaDB/MySQL Paketi Çalışmıyor:
  • ServBay arayüzünden ya da servbayctl status mariadb <version> komutuyla paket durumu kontrol edin.
  • Paket durmuyorsa şu komutla başlatmayı deneyin: servbayctl start mariadb <version>. Başlatma sebebini görmek için hata kaydını (.err dosyası) kontrol edin.
• Socket Dosya Yolu Hatalı:
  • Bağlantı sırasında kullanılan socket dosya yolu ile sunucu ayarlarında (my.cnf) belirtilen yol farklı olabilir.
  • MariaDB/MySQL ayar dosyasında (/Applications/ServBay/etc/mariadb/<version>/my.cnf) socket değişkeninin nereyi gösterdiğini kontrol edin.
  • Bağlantı yaptığınız istemci ya da uygulamada socket yolu olarak doğru yolu belirtin ya da ServBay'in varsayılan yolunu kullanın. ServBay varsayılanı çoğunlukla /Applications/ServBay/tmp/ veya /tmp/ altındadır; örn. /Applications/ServBay/tmp/mysql.sock veya /tmp/mysql.sock gibi.
• ServBay Varsayılan Ayar Problemi:
  • ServBay’in "Ayarlar" -> "Varsayılan SQL Sunucu" kısmında doğru MariaDB/MySQL sürümünün seçili olduğundan emin olun. Bazı istemci araçları (mysql terminal aracı gibi) -S veya -h parametresi verilmezse varsayılan socket’e bağlanacaktır.
• Yetki Problemleri:
  • MariaDB/MySQL servisini çalıştıran kullanıcının socket dosyasının bulunduğu dizinde yazma; istemci tarafında ise okuma yetkisi olması gerekir. Genelde ServBay kısıtları otomatik ayarlar, fakat /Applications/ServBay/tmp/ veya /tmp/ dizinlerinde manuel bir değişiklik yapıldıysa sorunlar oluşabilir.

Alternatif: Ağ Üzerinden Bağlantı Zorlamak (TCP/IP):

• Bağlantıyı localhost yerine 127.0.0.1 adresiyle kurmayı deneyin; bu şekilde istemci Unix socket yerine TCP/IP kullanmaya zorlanır. Eğer bu şekilde bağlantı kurulabiliyorsa, sorun socket dosyasındadır.

  mysql -u <username> -p -h 127.0.0.1 -P 3306

2. Bağlantı Hatası: Ağ Bağlantısı Sorunları (Connection refused, Can't connect to MySQL server gibi)

Bu tür hatalar, istemcinin TCP/IP üzerinden MariaDB/MySQL sunucusuna ulaşamadığını gösterir.

Muhtemel Nedenler & Çözümler:

• MariaDB/MySQL Paketi Çalışmıyor: (Yukarıdaki gibi, paket durumunu ve .err kaydını kontrol edin)
• Port Meşguliyeti:
  • MariaDB/MySQL’in dinlemek istediği (varsayılan 3306) portta başka bir servis çalışıyor olabilir.
  • Port kullanımı aşağıdaki şekilde kontrol edilebilir:

    lsof -i :3306
    # veya
    netstat -anv | grep LISTEN | grep 3306

  • Eğer port doluysa, ya ilgili süreci sonlandırın ya da paket ayar dosyasındaki (/Applications/ServBay/etc/mariadb/<version>/my.cnf) port değerini başka bir numarayla değiştirin ve paketi yeniden başlatın.
• Güvenlik Duvarı Engellemesi:
  • macOS dâhili veya üçüncü parti güvenlik duvarı, 3306 portuna gelen bağlantıları engelliyor olabilir.
  • Sistem Ayarları -> Ağ -> Güvenlik Duvarı kısmını kontrol edin.
  • mysqld çalıştırılabilir dosyasının geçişine izin vermek için şu komutları kullanabilirsiniz (yolu kendi kurulumunuza göre değiştirin):

    # Örnek, yol değişebilir
    sudo /usr/libexec/ApplicationFirewall/socketfilterfw --add /Applications/ServBay/bin/mariadb/<version>/bin/mysqld
    sudo /usr/libexec/ApplicationFirewall/socketfilterfw --unblockapp /Applications/ServBay/bin/mariadb/<version>/bin/mysqld

• Ayar Problemi (bind-address):
  • my.cnf dosyasındaki bind-address ayarını kontrol edin. 127.0.0.1 veya localhost olursa sadece yerel TCP/IP erişimine izin verilir. Diğer makinelerden bağlantı gerekirse 0.0.0.0 ya da belirli bir IP adresiyle değiştirilir ve güvenlik duvarı uygun şekilde ayarlanır.
• Ağ Yapılandırmasında Problem (localhost Çözümlemesi):
  • localhost doğru şekilde 127.0.0.1 (IPv4 loopback) ve ::1 (IPv6 loopback) olarak çözülmeli.
  • Terminalde ping localhost ile kontrol edin.
  • /etc/hosts dosyanızda localhost satırı doğru şekilde girilmiş mi bakın.
  • Proxy yazılımları, localhost veya 127.0.0.1 trafiğini bozabiliyor; devre dışı bırakmayı deneyin.

3. MariaDB/MySQL Paketi Başlatılamıyor

Muhtemel Nedenler & Çözümler:

1. Hata Kayıtlarını Kontrol Edin: /Applications/ServBay/logs/mariadb/<version>/<version>.err dosyasındaki hata açıklamaları sorunun kaynağına ulaşmak için anahtar niteliğindedir.
2. Yapılandırma Dosyası Hatası:
   • /Applications/ServBay/etc/mariadb/<version>/my.cnf dosyasında yazım hatası, geçersiz parametre veya yanlış yol tanımlamaları olabilir.
   • Yapılandırma dosyası doğrulamasını komutla yapabilirsiniz (ServBay sürüm yoluna göre değiştirin):

     # Örnek, kendi kurulumunuza göre değiştirin
     /Applications/ServBay/bin/mariadb/<version>/bin/mysqld --defaults-file=/Applications/ServBay/etc/mariadb/<version>/my.cnf --validate-config

3. Port Meşguliyeti: (Daha önce belirtildiği gibi, lsof -i :<port> veya netstat kullanın)
4. Disk Alanı Yetersizliği: Veritabanı veri dizini (/Applications/ServBay/db/mariadb/<version>/) ya da log dizini (/Applications/ServBay/logs/mariadb/<version>/) barındıran bölümde yeterli boş alan yoksa paket başlatılamaz.
5. Yetki Sorunu:
   • MariaDB/MySQL servisinin çalıştığı sistem kullanıcısının (genellikle ServBay tarafından otomatik atanır, örn. _mysql) ayar dosyası, veri dizini ve log dizinini okuma/yazma yetkisi olmalıdır. ServBay kurulum esnasında gerekli izinleri otomatik atar fakat kullanıcı manuel olarak /Applications/ServBay altında izin değişikliği yaptıysa problem çıkabilir.
   • Örnek kontrol:

     ls -ld /Applications/ServBay/db/mariadb/<version>
     ls -l /Applications/ServBay/etc/mariadb/<version>/my.cnf
     ls -ld /Applications/ServBay/logs/mariadb/<version>

     İlgili dizin ve dosyaların okuma, yazma, çalıştırma yetkisi düzgün atanmalı.
6. Veri Dosyası Bozulması: (Aşağıdaki "Veritabanı Çökmesi veya Veri Bozulması" bölümüne bakın) Eğer önceki kapanış anormal gerçekleştiyse ya da başka bir arıza olduysa veri dosyaları hatalı olabilir.

Çözüm Sonrası:

• Paketi yeniden başlatmayı deneyin: servbayctl restart mariadb <version>

4. Kullanıcı Yetkisi veya Kimlik Doğrulama Problemleri

Veritabanı sunucusuna bağlandıktan sonra, kullanıcı adı, şifre veya yetkiler eksik olduğunda ör. Access denied gibi hatalar alınabilir.

Muhtemel Nedenler & Çözümler:

• Kullanıcı Adı ya da Şifresi Hatalı: Bağlantıda kullandığınız bilgiler tamamen doğru olmalı. ServBay’de root şifresini sıfırlama imkanı var; unuttuysanız yeniden oluşturabilirsiniz.
• Kullanıcı Host Sınırlaması: Hesabınız sadece belirli hostlardan bağlanmaya izinli olabilir (örn. '<username>'@'localhost'). '<username>'@'127.0.0.1' ile deneyince sorun yaşanabilir ve tersi de geçerli. '%' ifadesi tüm IP’lerden bağlantıyı açar.
• Yetki Eksikliği: Kullanıcının hedef veritabanına bağlanmak veya belirli işlemleri (SELECT, INSERT, UPDATE, DELETE, CREATE, DROP, vb.) yapmak için gerekli izinleri yoktur.
• Yetki Kontrolü:
  • Yeterli mevcut yetkilere sahip bir hesapla login olun (örn. root):

    mysql -u root -p

  • SQL'de ilgili kullanıcının haklarını görüntüleyin:

    SHOW GRANTS FOR '<username>'@'<hostname>';
    -- Ör: 'webapp' kullanıcısının 'localhost'tan bağlanma yetkileri:
    SHOW GRANTS FOR 'webapp'@'localhost';
    -- 'admin' kullanıcısının tüm IP'lerden yetkileri:
    SHOW GRANTS FOR 'admin'@'%';

  • Gerekirse GRANT ve REVOKE ile hakları düzenleyin ya da yeni kullanıcı atayın.

5. Performans Sorunları

Veritabanı performansındaki düşüş, uygulamanızın genel performansını olumsuz etkiler.

Muhtemel Nedenler & Çözümler:

1. Yavaş Sorgular: Sorgu yanlış kurgulanmış, indeks yok ya da problemli plan yürütülüyor.
   • Yavaş Sorgu Logunu Açın: my.cnf dosyasına slow_query_log = 1 ve long_query_time = 1 ekleyin (1 saniyeden uzun sürenleri loglar), ve dosya yolunu slow_query_log_file ile belirtin. Yazılımı yeniden başlatın. Oluşan logu analiz edin.
   • EXPLAIN Kullanımı: Yavaş sorgularda ya da performanstan şüpheli her sorguda önüne EXPLAIN ekleyerek analiz edin, indeks kullanılıp kullanılmadığını, kaç kayıt tarandığını görün.

     EXPLAIN SELECT * FROM your_table_name WHERE column_name = 'value';

   • Sorgu Optimizasyonu: EXPLAIN ile elde edilen sonuçlara göre sorguları yeniden düzenleyin; verimsiz işlemlerden kaçının (SELECT * gibi); WHERE/JOIN koşullarının indekslerle uyumlu olmasına dikkat edin.
2. Eksik ya da Yanlış İndeks: Sık kullanılan sorgu, sıralama (ORDER BY), gruplanma (GROUP BY) işlemleri yapılan sütunlarda indeks yoksa tam tablo taranır.
   • Tablo yapısını ve sorguları analiz edin: Hangi alanlarda indeks gerektiğine karar verin.
   • İndeks Oluşturun:

     CREATE INDEX idx_column_name ON your_table_name(column_name);

     Unutmayın: İndeks oluşturmak, yazma işlemlerini ve disk kullanımını artırır; avantaj-dezavantaj dengesine dikkat edin.
3. Yanlış Önbellek Ayarları: my.cnf dosyasındaki önbellek ile ilgili parametreler (innodb_buffer_pool_size, MyISAM için key_buffer_size gibi) çok düşük ya da çok yüksek olabilir.
   • my.cnf'ı Düzenleyin: macOS sisteminizin sahip olduğu RAM ve kullanım amaçlarınıza göre önbellek parametrelerini ayarlayın. innodb_buffer_pool_size genellikle sistem belleğinin %50-70’i kadar önerilir. Değişiklik sonrası paketi yeniden başlatın.

     [mysqld]
     # Örnek, ihtiyacınıza göre ayarlayın (K/M/G biçimini kullanabilirsiniz)
     innodb_buffer_pool_size = 2G
     # MyISAM tablolarda ağırlıkta ise:
     # key_buffer_size = 256M

4. Donanım Sıkışıklığı: CPU aşırı kullanımda, RAM yetmiyor, disk I/O yoğunluğunda yavaşlama var ise etkinlik monitörü (Activity Monitor) ya da terminalde top/htop ile kaynak tüketimini izleyip darboğazı bulun.

6. Veritabanı Çökmesi veya Veri Bozulması

Veritabanı başlatılamıyor, sık sık çöküyor ya da veri erişimi anormal hale geldiyse veri dosyalarında bozulma olabilir.

Muhtemel Nedenler & Çözümler:

1. Hata Kayıtlarını Kontrol Edin: /Applications/ServBay/logs/mariadb/<version>/<version>.err dosyasında çökme ve bozulmanın ayrıntıları (ör. InnoDB hatası, dosya sistemi problemi, donanım arızası) yer alır.
2. Donanım Hataları: Disk ya da bellekteki fiziksel sorunlar, veri okuma/yazmada hata oluşturabilir. Sistem loglarını (Console.app) veya donanım tanı araçlarını kullanın.
3. Yazılım Çakışması ya da Hatası: Spesifik MariaDB/MySQL sürümlerinde bug ya da başka yazılımlarla çakışma meydana gelebilir.
4. Yanlış Konfigürasyon: my.cnf dosyasındaki yanlış parametreler veritabanını istikrarsız veya çökebilir kılar.
5. Ani Kapatma veya Kesinti: MariaDB/MySQL paketi düzgün şekilde durdurulmazsa (örn. ServBay’in ani kapatılması veya sürecin öldürülmesi) veri tutarsızlığı oluşabilir.

Çözüm Yolları:

• Güvenli Yeniden Başlatma Deneyin: Öncelikle ServBay arayüzünden ya da terminalden servbayctl restart mariadb <version> ile paketi normal şekilde yeniden başlatmayı deneyin. Bazen bu yol kendi kendine kurtarma yapılmasını sağlar.
• mysqlcheck ile Tabloları Kontrol ve Onarımı: Bu araç, veritabanı tablolarını kontrol eder ve bazı problemleri çözebilir (özellikle MyISAM tabloları için).

  # ServBay my.cnf ve root kullanıcı ile tüm tablo ve veritabanlarını kontrol edin
  mysqlcheck --defaults-file=/Applications/ServBay/etc/mariadb/<version>/my.cnf -u root -p --check --all-databases
  # MyISAM tabloları için otomatik onarımı deneyebilirsiniz:
  # mysqlcheck --defaults-file=/Applications/ServBay/etc/mariadb/<version>/my.cnf -u root -p --auto-repair --check --all-databases

  Dikkat: --auto-repair sadece MyISAM için geçerlidir. InnoDB için ise genellikle aşağıdaki InnoDB kurtarma veya yedekten geri yükleme gerekir.
• InnoDB Zorunlu Kurtarma (innodb_force_recovery): InnoDB motoru başlatılamıyorsa (loglarda InnoDB hatası varsa) zorunlu kurtarma yapılabilir. Tehlikeli bir işlemdir; veri kaybı ya da tutarsızlık olabilir! Sadece normal başlatma imkansızsa ve asıl amaç veri yedekleyip kurtarmak olduğunda kullanın.
  1. Öncelikle verinin (bozuk olsa da) tam bir yedeğini alın: /Applications/ServBay/db/mariadb/<version>/ yolunu farklı konuma kopyalayın.
  2. Hatalı sürüme ait my.cnfyi (/Applications/ServBay/etc/mariadb/<version>/my.cnf) düzenleyin.
  3. [mysqld] başlığı altında innodb_force_recovery = N satırı ekleyin (N 1’den başlayarak 6’ya kadar artırılır, her seferinde bir basamak denenir, başlatmazsa bir üst değeri deneriz).
  4. MariaDB/MySQL’i başlatmaya çalışın: servbayctl start mariadb <version>
  5. Başlatılır (salt-okunur veya kısıtlı bir modda da olsa) ise, hemen mysqldump ile tüm veritabanını yedekleyin! Bu, çoklukla tek kurtuluş yoludur.

     mysqldump --defaults-file=/Applications/ServBay/etc/mariadb/<version>/my.cnf -u root -p --all-databases --routines --triggers --events > /path/to/your_emergency_backup.sql

     Yedek dosyasının gerçekten oluştuğundan ve büyüklüğünün makul olduğundan emin olun.
  6. Yedek sonrası, MariaDB/MySQL paketini hemen durdurun: servbayctl stop mariadb <version>
  7. my.cnf dosyasını tekrar açıp innodb_force_recovery = N satırını silin veya yoruma alın.
  8. Veri geri yükleme işlemi: Genellikle bu, veri dizinini baştan oluşturmak (bozuk eski dizini yeniden adlandırmak ya da silmek) ve yedekten alınan SQL dosyasını yeni kurulu veritabanına aktarmak anlamına gelir.
• Yedekten Geri Yükleme: Veritabanı onarılamıyorsa ya da onarım sonrası veri tutarsızlığı varsa en sağlam yol güvenilir bir yedekten dönmektir. ServBay’in dahili yedekleme dosyaları şurada bulunur: /Applications/ServBay/backup/mariadb/<version>/
  • Örnek geri yükleme komutu (yedek bir veritabanı <target_database_name>’e aktarılacaksa):

    # Hedef veritabanının mevcut olduğundan emin olun
    # mysql --defaults-file=/Applications/ServBay/etc/mariadb/<version>/my.cnf -u root -p -e "CREATE DATABASE <target_database_name>;"
    
    # Yedekten geri yükleme
    mysql --defaults-file=/Applications/ServBay/etc/mariadb/<version>/my.cnf -u <username> -p <target_database_name> < /Applications/ServBay/backup/mariadb/<version>/<your_backup.sql>

    Not: <version> hedef MariaDB/MySQL paket sürümünüz ile değiştirilmeli.

7. Yedekleme ve Geri Yükleme Sorunları

ServBay’in yerleşik yedekliği ya da elle mysqldump kullanımıyla yapılan yedekleme/geri yükleme sürecinde sorunlar oluşabilir.

Muhtemel Nedenler & Çözümler:

• Yedek Dosyası Eksik ya da Bozuk:
  • Yedek dosyasının boyutunu kontrol edin (ls -lh /path/to/your_backup.sql); veri büyüklüğüyle uyumlu görünmeli.
  • Bir metin editörü ya da less ile açıp içeriğinin geçerli SQL dosyası gibi göründüğünden emin olun.
  • mysqldump ile manuel yedek aldıysanız komut sırasında hata mesajı olup olmadığını kontrol edin. Yerleşik ServBay yedeği için uygulama loglarını inceleyin.
• Yanlış Geri Yükleme Komutu:
  • Yanlış kullanıcı adı, şifre ya da hedef veritabanı adı kullanılmış olabilir.
  • Komutu çalıştıran kullanıcının yetkisi yoktur.
  • SQL sözdizimi hatası: Farklı sürüm ya da MariaDB↔MySQL tipinde yedek/dönüşüm yapılırsa uyumsuzluk çıkabilir.
• Dış Anahtar (Foreign Key) Kısıtlaması: Veri aktarımı sırasında tabloların yüklenme sırası nedeniyle foreign key kısıtı hatası alınabilir (bağlantılı tablo daha gelmemiştir). Geçici olarak dış anahtar kontrolünü kapatıp yükleme sonunda yeniden açabilirsiniz:

  -- İçe aktarım öncesi
  SET foreign_key_checks = 0;
  -- Aktarım komutu örneği:
  source /path/to/your_backup.sql; -- mysql istemcisinde
  -- veya: mysql ... < /path/to/your_backup.sql
  
  -- Aktarım sonrası
  SET foreign_key_checks = 1;

  Dikkat: Dış anahtar kontrolünü sadece veri aktarımı sırasında kapatın; aksi takdirde veri tutarsızlığı oluşabilir.
• Karakter Seti ya da Sıralama Sorunu: Yedekteki tablodaki karakter seti veya karşılaştırma kuralı, hedef veritabanında tanımlı olanla uyumsuzsa hata ya da veri bozulması ortaya çıkabilir. Tablo/DB tanımlarında utf8mb4 gibi aynı karakter seti kullanıldığından ve uyumlu olduğundan emin olun.

Doğru Veritabanı Geri Yüklemesi (komut satırı örneği):

# Diyelim ki yedek belirli bir veritabanına ait
# Önce hedef veritabanını oluşturun (<target_database_name>)
# mysql --defaults-file=/Applications/ServBay/etc/mariadb/<version>/my.cnf -u root -p -e "CREATE DATABASE <target_database_name>;"

# Doğru config, kullanıcı, şifre ve veritabanı ile yükleyin
mysql --defaults-file=/Applications/ServBay/etc/mariadb/<version>/my.cnf -u <username> -p <target_database_name> < /Applications/ServBay/backup/mariadb/<version>/<your_backup.sql>

# Eğer yedek tüm veritabanlarını içeriyorsa (--all-databases) DB adı vermeniz gerekmez
# mysql --defaults-file=/Applications/ServBay/etc/mariadb/<version>/my.cnf -u <username> -p < /Applications/ServBay/backup/mariadb/<version>/<your_backup.sql>

Not: <version>, hedef MariaDB/MySQL paket sürümünüzle eşleşmeli. ServBay’in yerleşik yedekleri genellikle kurtarması kolay SQL dosyaları üretir ve arayüzünde de geri yükleme seçenekleri sunar.

8. Özel Hata: MariaDB 11.5.1 InnoDB Başlatma Sorunu (ib_logfile0 was not found / Missing FILE_CHECKPOINT)

Bu hata, MariaDB 11.5.1 sürümündeki bilinen kritik bir bug’dur; InnoDB motorunun log dosyasıyla ilgili sorunlardan ötürü başlatılamamasına yol açar.

Hata Logu Özellikleri:

/Applications/ServBay/logs/mariadb/11.5/11.5.err dosyasında şu örnek satırlar görülebilir:

[ERROR] InnoDB: File /Applications/ServBay/db/mariadb/11.5/ib_logfile0 was not found
[ERROR] InnoDB: Plugin initialization aborted with error Generic error
[ERROR] Plugin 'InnoDB' registration as a STORAGE ENGINE failed.
[ERROR] Unknown/unsupported storage engine: InnoDB

veya:

[ERROR] InnoDB: Missing FILE_CHECKPOINT(xxxxx) at xxxxx
[ERROR] InnoDB: Log scan aborted at LSN xxxxx
[ERROR] InnoDB: Plugin initialization aborted with error Generic error
[ERROR] Plugin 'InnoDB' registration as a STORAGE ENGINE failed.
[ERROR] Unknown/unsupported storage engine: InnoDB

Bu hatalar, InnoDB'nin log dosyasına erişemediğini veya dosyadaki checkpoint kaydını bulamadığını ve dolayısıyla başlatılamadığını gösterir.

Çözüm (Veri Taşıması Gerektirir, Mutlaka Önce Yedek Almaya Çalışın!):

Bu sorun, olağan yollarla kolay onarılabilir değildir. Çözümdeki temel amaç varolan veriyi kurtarıp daha sağlam bir MariaDB sürümüne aktarmaktır.

1. Veriyi Kurtarıp Yedekleme için Zorunlu Kurtarma (Riskli!):
   • MariaDB 11.5’in yapılandırma dosyasını (/Applications/ServBay/etc/mariadb/11.5/my.cnf) açın.
   • [mysqld] altında şu satırı ekleyin: innodb_force_recovery = 6
   • ServBay arayüzünden ya da şu komutla MariaDB 11.5’i başlatmayı deneyin: servbayctl start mariadb 11.5
   • Eğer başlatılırsa (kısıtlı modda dahi olsa) hemen mysqldump ile tüm veritabanlarını yedekleyin. Bu, verinizi kurtarmak için tek şansınızdır.

     mysqldump --defaults-file=/Applications/ServBay/etc/mariadb/11.5/my.cnf -u root -p --all-databases --routines --triggers --events > /Applications/ServBay/backup/mariadb/11.5/mariadb_11.5_emergency_backup.sql

     Yedek dosyasının oluşup oluşmadığını ve boyutunun makul olduğunu mutlaka kontrol edin.
2. Problemli Sürümün Veri Dizinini Durdurma ve İşleme:
   • MariaDB 11.5 paketini durdurun: servbayctl stop mariadb 11.5
   • my.cnf dosyasını açıp innodb_force_recovery...