Canlı sunucuda yapılandırma değişikliğini güvenli uygulamak için restart, graceful restart ve daemon-reload ne zaman kullanılır?

Bunu doğru ayırmanın nedeni​

Canlı sunucuda en sık karışan nokta şudur: Bir değişikliği uygulamak için her zaman tam yeniden başlatma gerekmez. Bazı değişiklikler yalnızca servis yapılandırmasını yeniden okumayı ister, bazıları ise systemd unit dosyasını yenilemek için daemon-reload gerektirir. Apache örneğinde daemon-reload, web sunucusunun kendi yapılandırmasını değil service biriminin tanımını yeniler; yapılandırmanın yeniden okunması içinse servis tarafında uygun reload veya graceful davranışı gerekir.

Daemon-reload ne için kullanılır?​

Systemd altında bir servis dosyasında değişiklik yaptıysanız, örneğin unit dosyasına yeni bir seçenek eklediyseniz ya da servis tanımını değiştirdiyseniz önce daemon-reload kullanılır. Bu işlem systemd’nin birim tanımını tekrar okumasını sağlar. Servisin içinde çalışan uygulamanın ayar dosyasını değiştirmek ise başka bir konudur; onu daemon-reload çözmez.

Graceful restart ne zaman daha güvenlidir?​

Web sunucusu zaten çalışıyorsa ve yalnızca uygulama ya da sanal host yapılandırması değiştiyse, mümkün olduğunda graceful restart tercih edilir. Apache’de bu yöntem mevcut bağlantıları aniden kesmeden, çocuk süreçlerin mevcut isteklerini bitirip yeni yapılandırmayla devam etmesine izin verir. Bu yüzden kısa kesinti istemeyen sitelerde, özellikle yoğun trafikte, tam restart yerine daha uygun olabilir.

Tam restart ne zaman gerekir?​

Servis kararlı davranmıyorsa, yapılandırma değişikliği graceful ile güvenli uygulanamıyorsa veya yeni ortamın temiz bir başlangıçla açılması gerekiyorsa tam restart kullanılır. Apache dokümantasyonu, restart öncesinde söz dizimi kontrolü yapıldığını ve hata varsa işlemin iptal edilebildiğini belirtir; bu, yanlış yapılandırmayla servisi tamamen kapatıp açma riskini azaltır. Yine de tam restart, aktif bağlantıları kesebileceği için son seçenek olarak düşünülmelidir.

Bakım sırasında pratik karar sırası​

1. Unit dosyası değiştiyse önce daemon-reload.
2. Uygulama veya web sunucusu konfigürasyonu değiştiyse önce uygun config testini çalıştır.
3. Kesinti istemiyorsanız graceful reload/restart tercih et.
4. Davranış sorunluysa tam restart yap.

Bu sıra özellikle “hangi değişiklik nerede yapıldı?” sorusunu netleştirir. Unit dosyasını değiştirdiğiniz halde yalnızca servis reload etmek, ya da yalnızca Apache konfigürasyonu değiştiği halde systemd tarafında işlem aramak, en yaygın karışıklıklardan biridir.

Yedekleme tarafında aynı düşünme biçimi neden önemlidir?​

Değişikliği güvenli yapmak kadar, geri dönüşü güvenli yapmak da önemlidir. CISA’nın yedek rehberleri 3-2-1 yaklaşımını, yani birincil kopya ile birlikte iki yedek, iki farklı ortam ve bir offsite kopya fikrini öne çıkarır. Bu sayede yapılandırma denemesi başarısız olursa yalnız servisi yeniden başlatmaya değil, geri yükleme planına da güvenebilirsiniz.

Sık yapılan hata​

En yaygın hata, her değişikliği aynı tür işlem sanmaktır. Unit dosyası değişikliğine restart, uygulama konfigürasyonuna daemon-reload, aktif trafik varken de zorunlu tam restart uygulamak gereksiz kesinti çıkarır. Ayrıca reload sonrası servis ayağa kalktı diye konfigürasyonun doğru çalıştığını varsaymak da yanlıştır; özellikle web uygulamalarında sözdizimi kontrolü ve kısa bir işlev testi yapmak daha güvenlidir.