MariaDB ve systemd: mariadb.service Başlatma, Durdurma ve Ayarlar

Hangi dağıtımlar, hangi servis adı?

Belgelere göre systemd şu dağıtımlarda varsayılan servis yöneticisidir: RHEL ve CentOS 7 ve sonrası, Fedora 15 ve sonrası, Debian 8 ve sonrası, Ubuntu 15.04 ve sonrası, SLES 12 ve sonrası, openSUSE 12.2 ve sonrası. MariaDB'nin systemd birim dosyası RPM ve DEB sunucu paketlerinde, ayrıca bazı ikili tar arşivlerinde bulunur. Servisin adı mariadb.service'tir. Birim dosyasının tam içeriğini görmek için:

systemctl show mariadb.service

Temel komutlar

Servisle systemctl komutu üzerinden etkileşirsiniz:

sudo systemctl enable mariadb.service
sudo systemctl start mariadb.service
sudo systemctl stop mariadb.service
sudo systemctl restart mariadb.service
sudo systemctl status mariadb.service

Sunucuyu SQL tarafından da kapatabilirsiniz. mariadb-admin shutdown sunucuda SHUTDOWN komutunu çalıştırır ve SHUTDOWN yetkisi ister; mariadb-admin ping ise sunucunun ayakta olup olmadığını denetler ve sunucu çalışıyorsa, erişim reddi gibi bir hata olsa bile 0 döndürür. Bu yüzden izleme betiklerinde ping pratiktir. systemd altında çalışan bir sunucuyu ise servis yöneticisinin bilgisi dışında kapatmak yerine systemctl stop kullanmak, servis durumunun tutarlı kalmasını sağlar.

mariadb-admin ping

systemd sunucuyu nasıl başlatır?

Belgelerdeki önemli ayrıntı şudur: Sunucu systemd birim dosyasıyla başlatıldığında mariadbd süreci doğrudan ve mysql kullanıcısıyla başlatılır. Eski sysVinit düzeninin aksine araya mariadbd-safe girmez. Bunun sonucu olarak yapılandırma dosyalarındaki [mariadbd-safe] grubunda bulunan seçenekler okunmaz. mariadbd-safe, systemd desteklemeyen sistemler için önerilen başlatma sarmalayıcısıdır ve çöken sunucuyu yeniden başlatmak gibi güvenlik özellikleri sunar; systemd altında bu işlevlerin karşılıkları birim seçenekleridir.

Paketle kurulumda sunucu RPM ya da DEB paketi, ilk veritabanlarını ve kullanıcıları oluşturan mariadb-install-db betiğini kendiliğinden çalıştırır. Kurulumun kendisi MariaDB kurulum yazısında anlatılıyor.

Drop-in dosyalarıyla yapılandırma

Servisi yapılandırmanın yolu bir drop-in dosyası oluşturmaktır. Çoğu sistemde bu dosyaların dizini /etc/systemd/system/mariadb.service.d/ olur. systemctl status mariadb.service çıktısındaki "Drop-In" satırı hem dizini hem de yüklenen dosyaları gösterir. Dosyalar .conf uzantılıdır ve ayarlar genellikle [Service] bölümüne yazılır. En kolay yol systemctl edit kullanmaktır:

sudo systemctl edit mariadb.service

Açılan düzenleyiciye istediğiniz ayarı [Service] başlığı altında yazarsınız. systemd'de bazı seçenekler liste niteliğindedir; bunları değiştirirken önce boş bir değer atayıp sonra yenisini yazmanız gerekebilir. Belgelerin ExecStart örneği bunu gösterir:

[Service]

ExecStart=
ExecStart=/usr/bin/numactl --interleave=all  /usr/sbin/mariadbd $MYSQLD_OPTS $_WSREP_NEW_CLUSTER $_WSREP_START_POSITION

Herhangi bir yapılandırma değişikliğinden sonra değişikliğin geçerli olması için systemd'ye birimleri yeniden okutun, ardından gerekiyorsa servisi yeniden başlatın:

sudo systemctl daemon-reload
sudo systemctl restart mariadb.service

mariadbd-safe seçeneklerinin systemd karşılıkları

Eskiden [mariadbd-safe] grubunda tuttuğunuz ayarların systemd altında birim seçeneği olarak yazılması gerekir. Belgelerdeki karşılık tablosunun en sık kullanılan satırları:

Paketlerle gelen mariadb-service-convert betiği, paket yöneticisi tarafından [mariadbd-safe] grubundaki açık ayarları okuyup systemd seçeneklerine dönüştürmek için kullanılır ve çıktısını /etc/systemd/system/mariadb.service.d/migrated-from-my.cnf-settings.conf dosyasına yazar. Belgeler, açık dosya sınırının örtük yüksek varsayılanlarının bu dönüşümde atlanabileceğini ve açıkça yapılandırılması gerekebileceğini not eder.

Başlangıç zaman aşımı

Birim dosyasının varsayılan başlangıç zaman aşımı çoğu sistemde yaklaşık 90 saniyedir. Çökme sonrası kurtarma gibi bir başlangıç işi bundan uzun sürerse systemd, mariadbd'nin başlayamadığını varsayar ve süreci sonlandırır. Benzer bir sorun durdurma sırasında da yaşanabilir. Belgelere göre systemd 236 ile gelen EXTEND_TIMEOUT_USEC desteği sayesinde MariaDB, ana sürüm yükseltmesi ya da çok büyük bir işlemin geri alındığı kurtarma gibi uzun sürebilecek adımlarda zaman aşımını kendisi uzatır; dolayısıyla systemd 236 ve sonrasında genellikle TimeoutStartSec'i elle değiştirmeniz gerekmez. Daha eski sistemlerde sınırsız zaman aşımı için systemctl edit mariadb.service ile şunu yazarsınız (systemd 229 ve sonrası infinity değerini kabul eder; 228 ve öncesinde 0 kullanılır):

[Service]

TimeoutStartSec=infinity
TimeoutStopSec=infinity

Açık dosya sınırı: LimitNOFILE

systemd kullanırken açık dosya sınırını mariadbd-safe'in open-files-limit seçeneği ya da open_files_limit sistem değişkeni yerine birimin LimitNOFILE seçeneğiyle değiştirirsiniz. Belgelere göre mariadb.service içindeki varsayılan LimitNOFILE=16364'tür. Çok sayıda tablo ve bağlantı kullanan sunucularda bu değeri büyütmek gerekebilir:

[Service]
LimitNOFILE=1048576

infinity değeri gerçekten sınırsız anlamına gelmez. systemd 234 ve sonrasında LimitNOFILE=infinity, çekirdeğin fs.nr_open parametresinin değerine eşitlenir; systemd 233 ve öncesinde ise 65536 olur. Bu yüzden belgeler eski sürümlerde infinity yerine büyük bir tam sayı yazmayı önerir. Değişiklikten sonra servisi yeniden başlatmanız gerekir.

Benzer şekilde çekirdek dökümü (core dump) almak isterseniz LimitCORE=infinity, --memlock kullanıyorsanız ya da Linux çekirdeği 5.12'den eskiyse ve InnoDB'nin io_uring eşzamansız G/Ç desteğini kullanıyorsanız LimitMEMLOCK ayarlanır; belgelerin örnek değeri LimitMEMLOCK=2M'dir.

Dizin kısıtları: ProtectHome, ProtectSystem, ReadWritePaths

Varsayılan birim dosyası güvenlik için bazı dizinlere erişimi kısıtlar. Başlatma sorunları sayfasına göre birim ProtectHome=true ayarlar; MariaDB /home, /root ya da /run/user altındaki dosyalara erişmeye çalışırsa "Permission Denied" hatası alır. Birim ayrıca ProtectSystem=full ayarlayarak birkaç dizine yazmayı kısıtlar. Veri dizinini ya da bir yapılandırma dosyasını bu konumlara taşıdıysanız ilgili kısıtı drop-in ile gevşetirsiniz:

[Service]

ProtectHome=false

İkili tar arşiviyle kurulumda veri dizini /usr/local altında olabilir; varsayılan birim ise bütün /usr ağacını yazmaya kapatır ve sunucu "Read-only file system" hatasıyla açılmaz. Belgelerin çözümü, yalnızca o dizini yazılabilir yapmaktır:

[Service]
ReadWritePaths=/usr/local/mysql/data

Kısıtı tamamen kaldırmak yerine yalnızca gereken dizine izin vermek, birimin sağladığı korumanın geri kalanını korur. RHEL ailesinde SELinux, Ubuntu ve Debian'ın yeni sürümlerinde AppArmor da varsayılan dışı yollara erişimi engelleyebilir; başlatma sorunları sayfası bu durumlar için ayrı bölümler içerir.

Dosya izinleri için birimin UMASK ve UMASK_DIR ortam değişkenleri kullanılır; belgelere göre bunlar umask'ı değil, varsayılan dosya sistemi izinlerini belirler ve yalnızca systemd'nin yönettiği mariadbd sürecinin oluşturduğu dosyaları etkiler.

Günlükler: systemd journal

systemd'nin kendi günlük sistemi olan journal, servisin başlatma süreciyle ilgili bilgileri tutar ve bir arıza olduğunda ilk bakılacak yerlerden biridir. MariaDB servisinin kayıtlarını journalctl ile okursunuz:

sudo journalctl -u mariadb.service

Belgelerdeki örnek çıktıda başlangıç adımlarının zaman aşımına uğradığı bir durum görülür: "start-pre operation timed out. Terminating." ve ardından "Failed to start" satırları. Böyle bir kayıt gördüğünüzde zaman aşımı bölümüne dönün. systemd altında log_error sistem değişkeni ayarlanmamışsa sunucunun hata günlüğü stderr üzerinden journal'a yazılır. Hata günlüğünü dosyaya yazmak, yavaş sorgu günlüğü ve günlük döndürme error log ve slow query log yazısında anlatılıyor.

Aynı makinede birden fazla örnek: mariadb@.service

Bazı işletim sistemlerinde mariadb@.service adlı bir systemd şablon birimi de kurulur. Bu şablonla aynı sistemde birden fazla MariaDB örneğini yönetirsiniz; her komutta örnek adını son ek olarak verirsiniz:

sudo systemctl start mariadb@node1.service

systemd, örneğe özel bir yapılandırma dosyası da arar ve örnek adını (%I) varsayılan olarak dahil edilen dosyalardaki her sunucu grubuna .%I biçiminde bir özel grup son eki olarak ekler. Belgelere göre node1 örneği için kullanılan yapılandırma dosyası /etc/mynode1.cnf yolundadır. Her örneğin kendi datadir, socket ve port değerleri olmalıdır (skip_networking kullanılmıyorsa). Servis başlarken mariadb-install-db çalıştırıldığı için yeterli yetki varsa örneklerin veri dizinleri otomatik olarak oluşturulur. Gruplar ve son ekler hakkında ayrıntı my.cnf yazısında.

Daha esnek bir düzen için MYSQLD_MULTI_INSTANCE ortam değişkenine mariadbd ve mariadb-install-db'nin tanıdığı seçenekleri yazabilirsiniz. Belgelerdeki barındırma örneğinde her Unix kullanıcısının kendi örneği vardır, örnek adı kullanıcı adıdır ve örnekler ağ yerine yalnızca soket kullanır:

[Service]
ProtectHome=false
Environment='MYSQLD_MULTI_INSTANCE=--defaults-file=/home/%I/my.cnf \
                        --user=%I \
                        --socket=/home/%I.sock \
                        --datadir=/home/%I/mariadb_data \
                        --skip-networking'

Bu dosya sudo systemctl edit mariadb@.service ile oluşturulur. RPM paketlerinde şablon dosyası, eski cmake sürümlerindeki bir hata nedeniyle bazı platformlarda pakete dahil edilemeyebilir; belgeler bu durumda dosyayı onu içeren bir paketten kopyalamanızı söyler.

İsteğe bağlı başlatma: mariadb.socket

Belgelere göre MariaDB 10.6'dan itibaren systemd soket etkinleştirmesi kullanılabilir. Bu düzende mariadb.socket tanım dosyası bir dizi Unix ve TCP soketi tanımlar; bu soketleri systemd dinler ve biri bağlandığında mariadb.service'i başlatıp soket tanımlayıcılarını MariaDB'ye devreder. Sunucu kapatıldığında soket etkin kalır ve yeni bir bağlantı servisi yeniden başlatır. Kullanmak için mariadb.service yerine soket birimini etkinleştirirsiniz:

systemctl start mariadb.socket
systemctl enable mariadb.socket

Bu düzende sunucunun socket, port ve back_log sistem değişkenleri yok sayılır; çünkü bu ayarlar systemd soket tanımındadır ve değişiklikler systemctl edit mariadb.socket ile yapılır. Belgeler en uygun kullanımı, her kullanıcıya ayrı örnek çalıştıran altyapı sağlayıcıları olarak tanımlar. Dezavantajı da açıktır: bağlanan istemci, MariaDB tamamen hazır olana kadar bekler; sunucu daha önce sert biçimde kapandıysa ve uzun bir InnoDB geri alma işlemi gerekiyorsa bu bekleme istemcinin tahammül süresini aşabilir. Tek bir uygulama sunucusunda klasik mariadb.service düzeni genellikle daha öngörülebilirdir.

Sık yapılan hatalar

• Paketle gelen birim dosyasını doğrudan düzenlemek: Paket güncellemesi dosyanın üzerine yazabilir. Değişiklikleri systemctl edit ile drop-in dosyasına yazın.
• daemon-reload'u unutmak: Drop-in dosyasını elle oluşturduysanız systemd yeniden okutulmadan değişiklik etkili olmaz.
• [mariadbd-safe] grubuna ayar yazmak: systemd altında bu grup okunmaz; karşılık gelen birim seçeneğini kullanın.
• Açık dosya sınırını open_files_limit ile büyütmeye çalışmak: Belgeler systemd altında bu sınırın LimitNOFILE ile değiştirileceğini söyler.
• Veri dizinini /home altına taşıyıp ProtectHome'u unutmak: Sunucu "Permission Denied" ile açılmaz.
• Uzun kurtarmayı arıza sanmak: Eski systemd sürümlerinde 90 saniyelik zaman aşımı kurtarma devam ederken süreci öldürebilir; journal'daki "timed out" satırlarına bakın.
• Çoklu örnekte port ve soketi ayırmamak: İki örnek aynı portu ya da soket dosyasını kullanmaya çalışırsa ikincisi açılamaz.

Sık Sorulan Sorular

Servis başlamıyor, ilk neye bakmalıyım?

Önce systemctl status mariadb.service ve journalctl -u mariadb.service çıktısına, sonra hata günlüğüne bakın. Başlatma sorunları sayfasına göre nedenin neredeyse her zaman hata günlüğünde yazdığını, yaygın nedenler arasında geçersiz yapılandırma seçenekleri, dizin izinleri, systemd kısıtları, SELinux ve AppArmor bulunduğunu unutmayın. Hata kodlarının özeti sık hatalar yazısında.

mariadb.service ile mysql.service aynı şey mi?

Belgeler MariaDB'nin systemd servis adını mariadb.service olarak verir. Dağıtımların eski adlarla uyumluluk için takma ad sağlayıp sağlamadığı dağıtıma bağlıdır; belirsizlik yaşamamak için komutlarda mariadb adını kullanın.

Sunucuyu systemd olmadan elle başlatabilir miyim?

Evet. Başlatma ve durdurma sayfası sunucunun elle başlatılabileceğini, mariadbd'nin asıl sunucu programı olduğunu, mariadbd-safe'in çöken süreci yeniden başlatan bir sarmalayıcı, mariadbd-multi'nin ise birden fazla süreci yönetmek için bir sarmalayıcı olduğunu anlatır. Root parolası sıfırlama gibi geçici işler için sunucuyu özel seçeneklerle elle başlatmanın adımları root parolası sıfırlama yazısında.

Sunucu çöktüğünde systemd yeniden başlatır mı?

Bu birimdeki Restart= ayarına bağlıdır; belgeler mariadbd-safe'in no-auto-restart seçeneğinin systemd karşılığı olarak bu seçeneği gösterir. Kendi biriminizdeki değeri systemctl show mariadb.service çıktısında görebilirsiniz.

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 · systemd servis yönetimi · my.cnf dosyaları · error log ve slow query log · MariaDB kurulumu · sık hatalar