MariaDB Hata Günlüğü, Genel ve Yavaş Sorgu Günlükleri

Hangi günlük ne için?

Belgeler bütün bu dosyalara ortak bir ön ek vermek için --log-basename seçeneğini önerir. Bu seçenek hata, genel sorgu, yavaş sorgu ve binary log dosyalarının taban adını birlikte belirler; özellikle aynı makinede birden fazla sunucu örneği çalıştırıyorsanız adların karışmasını önler. Bir kısıtı var: log-basename mutlak yol olamaz, dosyalar her zaman veri dizinine (datadir) göre konumlanır. Günlükleri ayrı bir dizine koymak istiyorsanız her biri için ilgili değişkene mutlak yol vermeniz gerekir. Güvenlik denetimi için genel sorgu günlüğü yerine belgeler MariaDB Audit Plugin'i işaret eder.

Hata günlüğü

Hata günlüğü sunucunun işleyişi sırasında oluşan kritik hataları, tablo bozulmalarını ve başlatma ile kapatma bilgilerini içerir. Belgelere göre MariaDB bu günlüğü her zaman yazar; değişen yalnızca hedefidir. log_error değişkeni ayarlanırsa günlük bir dosyaya gider. Değişken değer almadan yazılırsa dosya, veri dizininde ${hostname}.err adını alır. Göreli bir ad verilirse veri dizinine göre, mutlak yol verilirse o yola yazılır.

[mariadb]
log_error=/var/log/mysql/mariadb.err

Unix'te log_error hiç ayarlanmamışsa hatalar stderr'e, yani genellikle mariadbd'yi başlatan terminale yazılır. Sunucu systemd ile çalışıyorsa bazı hatalar systemd'nin kendi günlük sistemi olan journal'a düşebilir; belgeler, hata günlüğünün syslog'a yönlendirilmiş olabileceğini ve bu durumda journalctl ile bakmanız gerektiğini hatırlatır. Windows'ta iletiler ayrıca Olay Görüntüleyicisi'ne (Event Viewer) MariaDB kaynağıyla yazılır.

Günlüğün nerede olduğunu bilmiyorsanız belgeler şu komutları önerir. İlki sunucunun okuyacağı bütün seçenekleri yazar; ikincisi MariaDB 10.11'den itibaren [mariadbd] grubundaki seçenekler içinden günlük ayarını süzer. systemd günlüğüne bakmak için son satırdaki komut kullanılır:

mariadbd --print-defaults
my_print_defaults --mariadbd | grep log-error
sudo journalctl -u mariadb.service

Ayrıntı düzeyini log_warnings belirler ve belgelere göre varsayılan değeri 2'dir. Değer çalışırken SET GLOBAL log_warnings=3; ile değiştirilebilir. Bu değişken yalnızca bazı iletileri etkiler; örneğin InnoDB uyarılarının çoğu her durumda yazılır. Seviye 1 ve üzerinde replikasyon iş parçacıklarının durma iletileri, DNS çözümleme hataları ve ifade tabanlı replikasyon için güvensiz ifade uyarıları gibi faydalı kayıtlar görünür. Varsayılan seviye 2'de bunlara erişim reddi (Access denied for user ...) ve hata ya da zaman aşımıyla kesilen bağlantılar (Aborted connection ...) uyarıları eklenir. Daha yüksek seviyeler daha da ayrıntılı kayıt üretir; sorun ayıklarken geçici olarak artırıp sonra geri almak günlüğün gereksiz büyümesini önler.

Biçim oldukça düzenlidir: her kayıt tek satırdır ve tarih ile saat, iş parçacığı kimliği, köşeli parantez içinde düzey ([Note], [Warning] veya [Error]) ve iletiden oluşur. Sistem iletilerinde iş parçacığı kimliği 0'dır. Belgelerdeki örnek satır:

2016-06-15 16:53:33 139651251140544 [Note] InnoDB: The InnoDB memory heap is disabled

Bu düzenin istisnaları da vardır: bir çökmeden sonra yazılan yığın izi (stack trace) çok satırlıdır, Galera'da durum aktarımı sırasında dış betiklerin iletileri düzey öneki olmadan görünebilir ve syslog'a yazılırken satırın başına sistemin kendi başlığı eklenir. Günlüğü bir izleme aracına aktarıyorsanız ayrıştırıcıyı bu durumlara göre ayarlamanız gerekir. SQL hatalarını ayrı bir dosyada toplamak isterseniz belgeler SQL_ERROR_LOG eklentisini işaret eder. Sunucu açılmadığında hata günlüğünde nelere bakılacağı sık hatalar ve çözümleri yazısında.

Genel sorgu günlüğü

Genel sorgu günlüğü, istemciden gelen her ifadeyi ve her bağlanma ile kopmayı kaydeder. Belgelerin uyardığı gibi sunucuya gelen her şeyin kaydı olduğu için çok hızlı büyür. Binary log ile önemli bir farkı vardır: binary log bir ifadeyi ancak işlem onaylandığında yazar, genel sorgu günlüğü ise ifadeyi sunucuya ulaştığı anda yazar. Yalnızca veriyi değiştiren ifadeleri izlemek istiyorsanız binary log daha uygundur.

Günlük varsayılan olarak kapalıdır. general_log değişkeniyle çalışırken açılır; kalıcı olması için seçenek dosyasına yazılır. Dosya adı varsayılan olarak veri dizininde ${hostname}.log'dur ve general_log_file ile değiştirilir.

SET GLOBAL general_log=1;
SET GLOBAL general_log_file='mariadb.log';

Günlük dosyaya ya da mysql.general_log tablosuna yazılabilir; hedefi log_output değişkeni (FILE veya TABLE) belirler. Tabloya yazmak, kayıtları SQL ile süzmeyi kolaylaştırır. Bir oturumun kayıtlarını dışarıda bırakmak için SUPER yetkili bir kullanıcı SET SESSION SQL_LOG_OFF=1; kullanabilir. Belirli ifade türlerini dışarıda bırakan log_disabled_statements ise çalışırken değiştirilemez, seçenek dosyasında ayarlanır.

[mariadb]
log_output=FILE
general_log
general_log_file=queries.log
log_disabled_statements='slave,sp'

Yavaş sorgu günlüğü

Yavaş sorgu günlüğü, belirlenen süreden uzun çalışan sorguları ve etkiledikleri satır sayılarını kaydeder. Varsayılan olarak kapalıdır. Belgelere göre MariaDB 10.11'den itibaren değişkenlerin yeni adları vardır: slow_query_log için log_slow_query, slow_query_log_file için log_slow_query_file, long_query_time için log_slow_query_time. Eski adlar hâlâ çalışır ve belgelerdeki örneklerin çoğu onları kullanır.

SET GLOBAL slow_query_log=1;
SET GLOBAL long_query_time=5.0;

SET GLOBAL ile yapılan değişiklik sunucu yeniden başlayana kadar geçerlidir. Kalıcı olması için aynı ayarları seçenek dosyasının sunucu grubuna yazıp yeniden başlatırsınız. Eşik saniye cinsindendir, isteğe bağlı olarak milisaniye kısmı içerebilir ve varsayılanı 10'dur. Dosya varsayılan olarak veri dizininde ${hostname}-slow.log adını alır.

[mariadb]
slow_query_log
slow_query_log_file=/var/log/mysql/mariadb-slow.log
long_query_time=5.0

Günlüğün çalıştığını görmek için belgeler bilerek yavaş bir sorgu üretmeyi önerir. Aşağıdaki örnekte log_output TABLE olarak ayarlı ve eşik varsayılan 10 saniye; 11 saniye süren bir SLEEP sorgusu çalıştırılıp mysql.slow_log tablosuna bakılıyor. Çıktı belgelerdeki gibidir:

SELECT SLEEP(11);
+-----------+
| SLEEP(11) |
+-----------+
|         0 |
+-----------+
1 row in set (11.074 sec)

SELECT * FROM mysql.slow_log \G
*************************** 1. row ***************************
    start_time: 2026-02-06 18:38:23.071314
     user_host: stefanhinz[stefanhinz] @ localhost []
    query_time: 00:00:11.073655
     lock_time: 00:00:00.000000
     rows_sent: 1
 rows_examined: 0
            db:
last_insert_id: 0
     insert_id: 0
     server_id: 1
      sql_text: SELECT SLEEP(11)
     thread_id: 7
 rows_affected: 0

Kayıttaki query_time sorgunun toplam süresini, lock_time kilit beklemesini, rows_examined incelenen satır sayısını gösterir. Çok satır inceleyip az satır döndüren sorgular genellikle eksik bir dizinin işaretidir; dizin tasarımı için index oluşturma ve sorgu optimizasyonu yazılarına bakabilirsiniz.

Günlüğü daraltmak ve zenginleştirmek

Yavaş sorgu günlüğünün birkaç ayarı vardır ve hepsi belgelerde örnekleriyle anlatılır:

• log_queries_not_using_indexes: Dizin kullanmayan sorguları süresinden bağımsız olarak kaydeder. Aynı etki log_slow_filter listesine not_using_index eklenerek de elde edilir.
• min_examined_row_limit (10.11'den itibaren log_slow_min_examined_row_limit): Belirtilen sayıdan az satır inceleyen sorguları dışarıda bırakır; dizinsiz ama küçük sorguların günlüğü doldurmasını önler.
• log_slow_filter: Yalnızca belirli ölçütlere uyan sorguları kaydeder, örneğin filesort,filesort_on_disk,tmp_table,tmp_table_on_disk.
• log_slow_admin_statements: ALTER TABLE, OPTIMIZE, ANALYZE gibi yönetim ifadelerini kaydeder. Belgelere göre MariaDB 11.0'dan beri kullanımdan kaldırılmıştır; yerine log_slow_filter içindeki admin değeri kullanılır.
• log_slow_rate_limit: Yavaş sorguların yalnızca bir kısmını kaydederek G/Ç yükünü azaltır.
• log_slow_verbosity: Kayda sorgu planı, explain ve motor bilgisi gibi ek ayrıntılar katar; full değeri de kabul edilir.
• log_slow_disabled_statements: admin, call, slave, sp gibi türleri dışarıda bırakır; yalnızca seçenek dosyasında ayarlanır.

SET GLOBAL log_queries_not_using_indexes=ON;
SET GLOBAL min_examined_row_limit=100000;
SET GLOBAL log_slow_verbosity='full';

Bir oturumun yavaş sorgularını günlüğe yazdırmamak için belgelere göre her kullanıcı SET SESSION slow_query_log=0; kullanabilir. Bu, örneğin bilerek uzun süren bir bakım betiğinin günlüğü doldurmasını önler.

mariadb-dumpslow ile özet çıkarmak

Dosyaya yazılmış bir yavaş sorgu günlüğü uzun olabilir. mariadb-dumpslow (eski adı mysqldumpslow) günlüğü ayrıştırır ve yalnızca sayı ve metin değerleriyle farklılaşan benzer sorguları gruplar; değerleri özet çıktıda N ve 'S' olarak soyutlar. -s sıralama ölçütünü belirler (varsayılan at, yani ortalama sorgu süresi; c sayı, t toplam süre, r gönderilen satır gibi), -t yalnızca ilk N sorguyu gösterir, -g belirli bir metni içeren ifadelerle sınırlar. MariaDB 12.1'den itibaren -j (--json) çıktıyı JSON biçiminde verir.

mariadb-dumpslow -s c -t 10 /var/log/mysql/mariadb-slow.log

Günlükleri logrotate ile döndürmek

Hata, genel ve yavaş sorgu günlükleri kendiliğinden küçülmez. Linux'ta belgelerin önerdiği araç logrotate'tir. Belgelerdeki düzen önce günlükleri tek bir dizinde toplar; yukarıdaki gibi log_error, general_log_file ve slow_query_log_file değişkenlerine /var/log/mysql/ altında mutlak yollar verir ve dizini sunucu kullanıcısına ait olacak şekilde oluşturur:

sudo mkdir /var/log/mysql/
sudo chown mysql:mysql /var/log/mysql/
sudo chmod 0770 /var/log/mysql/

SELinux kullanan sistemlerde dizinin güvenlik bağlamını da ayarlamanız gerekebilir. logrotate döndürmeden sonra sunucuya dosyaları yeniden açtırmak için MariaDB'ye bağlanmak zorundadır. Belgelere göre en kolay yol root@localhost hesabını kullanmaktır; bu hesap varsayılan olarak unix_socket kimlik doğrulaması kullanır, yani sistemde root olarak çalışan bir süreç parolasız bağlanabilir. Bu kimlik doğrulama yöntemi unix_socket ve ed25519 yazısında anlatılıyor.

Ardından /etc/logrotate.d/mariadb dosyası oluşturulur. Belgelerdeki yapılandırmanın kısaltılmış hâli aşağıda; tam hâlinde bazı yönergelerin hangi logrotate sürümünden itibaren desteklendiği de not edilmiştir. Örnek, aracın eski adı olan mysqladmin'i kullanır; belgelere göre bu ad Linux'ta mariadb-admin'e giden bir sembolik bağ olarak hâlâ erişilebilirdir.

/var/log/mysql/* {
        su mysql mysql
        missingok
        create 660 mysql mysql
        notifempty
        daily
        rotate 30
        compress
        delaycompress
        sharedscripts
    postrotate
        if test -x /usr/bin/mysqladmin && \
           /usr/bin/mysqladmin ping &>/dev/null
        then
           /usr/bin/mysqladmin --local flush-error-log \
              flush-engine-log flush-general-log flush-slow-log
        fi
    endscript
}

Yönergelerin anlamı kısaca şöyle: daily günde bir döndürür, rotate 30 otuz eski kopya tutar, compress eski dosyaları gzip ile sıkıştırır, delaycompress sıkıştırmayı bir sonraki döndürmeye erteler. Belgeler bu ertelemenin nedenini açıklar: sunucu dosyayı yeniden açmadan sıkıştırma başlarsa, hâlâ yazılan bir dosyanın sıkıştırılması gibi yarış durumları oluşabilir. sharedscripts postrotate betiğini her dosya için değil bir kez çalıştırır. Betik, FLUSH komutlarını gönderir; sunucu bir günlüğü flush ettiğinde eski dosya tanıtıcısını kapatıp yenisini açar. Yapılandırmayı denemek için belgeler --force seçeneğini önerir; bu seçenek notifempty, daily ve boyut sınırı gibi koşulları yok sayar:

sudo logrotate --force /etc/logrotate.d/mariadb

mariadb-admin'in flush-error-log, flush-general-log ve flush-slow-log komutları ilgili günlüğü, flush-logs ise belgelere göre bütün günlükleri flush eder. Servisin kendisini yönetmek için systemd ile başlatma ve durdurma yazısına bakın. Binary log ise logrotate ile değil, MariaDB'nin kendi süre ve boyut ayarlarıyla ya da PURGE BINARY LOGS ile temizlenir.

Uygulamalı örnek: yavaş sorgu avı

Bir web uygulamasının bazı sayfaları yavaş açılıyor diyelim. Önce eşiği makul bir değere çekip yavaş sorgu günlüğünü açarsınız; dizin kullanmayan ama çok satır inceleyen sorguları da yakalamak için iki ayar eklersiniz. Bunları önce SET GLOBAL ile deneyip işe yaradığını görünce seçenek dosyasına taşıyabilirsiniz:

SET GLOBAL long_query_time=1.0;
SET GLOBAL log_queries_not_using_indexes=ON;
SET GLOBAL min_examined_row_limit=1000;
SET GLOBAL slow_query_log=1;

Bir süre trafik aldıktan sonra mariadb-dumpslow -s c ile en sık tekrarlanan yavaş sorguları listeler, ilk birkaçını EXPLAIN ile incelersiniz. Bir dizin ekleyip aynı sorgunun günlükte görünmediğini doğruladıktan sonra eşiği yeniden yükseltir ya da günlüğü kapatırsınız. Böylece günlük, sürekli büyüyen bir dosya olmak yerine hedefli bir teşhis aracı olarak kalır.

Sık yapılan hatalar

• Hata günlüğünü yanlış yerde aramak: log_error ayarlanmamışsa Unix'te kayıtlar stderr'e gider; systemd kullanıyorsanız journalctl ile de bakın.
• SET GLOBAL ile açıp kalıcı sanmak: Çalışırken yapılan değişiklikler yeniden başlatmada kaybolur; seçenek dosyasına da yazın.
• log-basename ile mutlak yol vermeye çalışmak: Belgelere göre bu ön ek her zaman veri dizinine görelidir.
• Genel sorgu günlüğünü üretimde açık unutmak: Hızla büyür ve hassas bilgi içerebilir.
• logrotate'i flush olmadan kullanmak: Sunucu eski dosya tanıtıcısına yazmaya devam eder; postrotate içinde flush komutları gerekir.
• Eşiği çok düşük tutmak: long_query_time çok küçükse günlük her sorguyla dolar; min_examined_row_limit ve log_slow_rate_limit ile daraltın.

Sık Sorulan Sorular

Hata günlüğünü kapatabilir miyim?

Hayır. Belgelere göre MariaDB hata günlüğünü her zaman yazar; yalnızca hedefini (dosya, stderr, syslog) seçebilirsiniz. Ayrıntı miktarını log_warnings ile azaltabilirsiniz, ama bazı iletiler her durumda yazılır.

Yavaş sorgu günlüğünü tabloya mı dosyaya mı yazmalıyım?

Varsayılan dosyadır ve mariadb-dumpslow gibi araçlar dosyayla çalışır. Tabloya (log_output='TABLE') yazmak kayıtları SQL ile sorgulamayı kolaylaştırır. İkisi de log_output değişkeniyle seçilir.

long_query_time değişikliği mevcut bağlantıları etkiler mi?

Belgelere göre long_query_time hem genel (global) hem oturum (session) kapsamına sahip, çalışırken değiştirilebilen bir değişkendir. SET GLOBAL sunucu genelindeki değeri değiştirir; zaten açık olan oturumunuzda farklı bir değer görürseniz kendi oturumunuz için aynı değeri SET SESSION ile verin ve SELECT @@SESSION.long_query_time ile kontrol edin.

Günlükleri silmek güvenli mi?

Hata, genel ve yavaş sorgu günlüklerini döndürüp eski kopyaları silebilirsiniz; önemli olan, sunucuya flush ettirerek yeni dosyayı açtırmaktır. Binary log dosyalarını ise asla işletim sisteminden silmeyin; PURGE BINARY LOGS kullanın.

Marka adları sahiplerine aittir. Bu yazı bağımsız bir teknik rehberdir; adı geçen kuruluşlarla bayilik veya ortaklık ilişkisi bulunduğu anlamına gelmez.

İlgili içerikler: MariaDB öğrenme rehberi · Binary log ve PITR · SHOW PROCESSLIST ve KILL · EXPLAIN ve ANALYZE · Sık hatalar ve çözümleri · SQL sorgu optimizasyonu