Login Sorunu Çözüm Planı

Detaylı Teknik Açıklamalar + Oturum Koruma

v3 Beklemede

Kritik Kural: Oturum Silme YOK!

Bu plandaki hiçbir adım kullanıcı oturumlarını silmez. Tüm işlemler oturumları koruyarak yapılacak.

İçindekiler

1. Teknik Terimlerin Açıklamaları 2. Mevcut Durum ve Sorunun Kaynağı 3. Çözüm Planı (6 Adım) 4. Yapılmayacaklar

Bölüm 1: Teknik Terimlerin Detaylı Açıklamaları

Redis Nedir?

🧑 Basit Anlatım

Redis, kullanıcı oturumlarını hafızada tutan bir depodur. Siteye giriş yaptığınızda Redis sizi hatırlar ve her sayfada tekrar şifre sorulmaz.

Gerçek Hayat Örneği:

Otele giriş yaptığınızda aldığınız oda kartı gibi. Kart sizdeyken istediğiniz zaman odanıza girebilirsiniz. Redis = otel resepsiyonu, oturum = oda kartı.

🔧 Teknik Detay

  • In-memory database: Verileri RAM'de tutar, çok hızlıdır
  • Key-value store: Her oturum bir "anahtar" ile saklanır
  • Persistence: RDB/AOF ile diske yedek alabilir

Örnek session key:

session_HXqFOACQ6MlX0EIIaHI8...

Şu an: Redis 34 gündür çalışıyor, 253 aktif oturum tutuyor, 18.7 milyon eski kaydı temizlemiş.

Memory Fragmentation (Hafıza Parçalanması)

🧑 Basit Anlatım

Hafızanın "delik deşik" olması. Uzun süre açık kalan sistemlerde veri ekleme/silme işlemleri hafızada boşluklar bırakır.

Gerçek Hayat Örneği:

Bir dolaba sürekli eşya koyup çıkarınca arada boşluklar kalır. Dolap dolu görünür ama az eşya alır. Çözüm: Her şeyi çıkarıp yeniden düzenlemek.

Normal değer: 1.0 - 1.5
Bizim değer: 16.18 (10 kat fazla!)

🔧 Teknik Detay

  • Formül: used_memory_rss / used_memory
  • RSS: İşletim sisteminin Redis'e ayırdığı gerçek RAM
  • used_memory: Redis'in aktif kullandığı hafıza

mem_fragmentation_ratio: 16.18

26MB veri için 420MB RAM kullanılıyor!

Etki: Yüksek fragmentation, oturum okuma/yazma işlemlerini yavaşlatır. Bazı kullanıcılar giriş yaparken timeout alabilir.

Expired Keys (Süresi Dolmuş Anahtarlar)

🧑 Basit Anlatım

Her oturum ve önbellek verisinin bir son kullanma tarihi vardır. Kullanıcı 30 gün siteye girmezse oturumu otomatik silinir.

Gerçek Hayat Örneği:

Marketteki ürünlerin son kullanma tarihi gibi. Tarihi geçen ürünler raftan kaldırılır. 34 günde 18.7 milyon "ürün" süresini doldurmuş!

🔧 Teknik Detay

  • TTL (Time To Live): Her key'in yaşam süresi
  • Lazy expiration: Key'e erişildiğinde kontrol edilir
  • Active expiration: Arka planda periyodik temizlik

expired_keys: 18,723,609

34 günde bu kadar key expire olmuş

Bu normal! Expire olan key'ler eski/kullanılmayan oturumlar. Ama bu kadar çok olması Redis'in yorulduğunu gösterir.

Debug Logları (Gereksiz Kayıtlar)

🧑 Basit Anlatım

Sistem her işlemde "şunu yaptım, bunu yaptım" diye kayıt tutuyor. Geliştirme aşamasında faydalı ama canlı sistemde gereksiz.

Gerçek Hayat Örneği:

Bir çalışanın her adımda "şimdi kaleme uzandım, şimdi yazmaya başladım" demesi gibi. İşi yavaşlatır ve gereksiz kağıt harcar!

🔧 Teknik Detay

  • Kaynak: SetTenantSessionConfig middleware
  • Her request'te: Log::debug() çağrılıyor
  • Sonuç: Günde 300-450 MB log dosyası

🍪 SetTenantSessionConfig applied {"host":"www.muzibu.com"...}

Bu satır saniyede onlarca kez yazılıyor!

Etki: Disk I/O yükü, disk dolması riski, log dosyalarında arama zorluğu. Son 1 hafta: ~3 GB gereksiz log!

BGSAVE (Background Save - Arka Plan Kaydetme)

🧑 Basit Anlatım

Redis'in hafızasındaki tüm verileri diske kaydetmesi. Bilgisayarı kapatmadan önce "Kaydet" demek gibi.

Gerçek Hayat Örneği:

Word'de çalışırken Ctrl+S yapmak gibi. Elektrik gitse bile belgeniz kaybolmaz. BGSAVE = Redis'in Ctrl+S'i

🔧 Teknik Detay

  • RDB Snapshot: Tüm verilerin anlık görüntüsü
  • Fork: Arka planda ayrı process olarak çalışır
  • Non-blocking: Site çalışmaya devam eder

redis-cli BGSAVE

Dosya: /var/lib/redis/dump.rdb

Neden önemli? BGSAVE yapılmadan Redis restart edilirse, son kayıttan sonraki TÜM VERİLER KAYBOLUR (oturumlar dahil)!

Graceful Restart (Zarif Yeniden Başlatma)

🧑 Basit Anlatım

Sistemi düzgün şekilde kapatıp açmak. Önce işleri bitir, verileri kaydet, sonra kapat, sonra aç.

Gerçek Hayat Örneği:

Bilgisayarı kapatmak yerine "Kapat" butonuna basmak. Programlar düzgün kapanır, veriler kaydedilir. Fişi çekmek ≠ Graceful!

🔧 Teknik Detay

  • SIGTERM: Redis'e "düzgün kapan" sinyali
  • RDB save: Kapanmadan önce veri kaydeder
  • Startup: Açılırken RDB'den yükler

sudo systemctl restart redis

systemd graceful restart yapar

Ne Olur? (Adım Adım)

1 BGSAVE ile veriler diske kaydedilir
2 Redis servisi kapatılır (1 saniye)
3 Hafıza tamamen temizlenir (fragmentation = 0)
4 Redis açılır ve RDB dosyasından verileri yükler
5 Tüm oturumlar geri gelir, kullanıcılar fark etmez!

Kesinti süresi: Sadece 1-2 saniye. Bu sürede giriş yapan kullanıcılar "Bağlantı hatası" alabilir ama sayfa yenileyince düzelir.

Bölüm 2: Mevcut Durum ve Sorunun Kaynağı

Sistem Metrikleri

Redis Uptime 34 gün
Memory Fragmentation 16.18
Aktif Session 253
Expired Keys 18.7M
Bugünkü Log 321 MB

Sorunun Kaynağı

1. Hafıza Parçalanması: Redis 34 gündür çalışıyor ve hafızası verimsiz hale gelmiş. 26MB veri için 420MB RAM kullanılıyor.

2. Gereksiz Loglar: Her HTTP isteğinde debug log yazılıyor. Disk I/O yükü artmış.

3. Cookie Geçişi: Eski muzibu_session → Yeni tenant_1001_session

Bölüm 3: Çözüm Planı (6 Adım)

1

Debug Logları Kapat

Güvenli

Her HTTP isteğinde yazılan gereksiz "session config" loglarını kapatacağız. Günde 300MB+ log azalacak.

✅ Etkilenenler

Log dosya boyutu azalır, disk I/O düşer

❌ Etkilenmeyenler

Oturumlar, kullanıcılar, site işleyişi

2

Eski Log Dosyalarını Temizle

Güvenli

7 günden eski log dosyalarını sileceğiz. ~3GB disk alanı açılacak.

✅ Etkilenenler

Eski log dosyaları (geri alınamaz)

❌ Etkilenmeyenler

Oturumlar, veritabanı, site

3

Laravel Cache Temizle

Güvenli

Config, route, view ve response cache temizlenecek. Session'lar ayrı DB'de olduğu için ETKİLENMEZ.

✅ Etkilenenler

Cache (Redis DB1), compiled views, config cache

❌ Etkilenmeyenler

Session'lar (Redis DB0), veritabanı

Neden güvenli? .env'de SESSION_DB=0, CACHE_DB=1 ayarlı. cache:clear sadece DB1'i temizler.
4

Redis BGSAVE + Graceful Restart

Dikkatli

Redis'i yeniden başlatarak hafıza parçalanmasını sıfırlayacağız. Önce BGSAVE ile yedek alınacak, sonra restart yapılacak.

✅ Etkilenenler

  • • Fragmentation: 16 → 1 olur
  • • 1-2 sn kesinti olur
  • • Hafıza optimize olur

❌ Etkilenmeyenler

  • • Oturumlar (RDB'den yüklenir)
  • • Veritabanı
  • • Dosyalar
KRİTİK: BGSAVE bitmeden restart YAPMA! LASTSAVE timestamp'inin değiştiğini kontrol et.
5

Horizon Restart

Güvenli

Queue işlemcisini yenileyeceğiz. Bekleyen işler kuyrukta kalır, kaybolmaz.

✅ Etkilenenler

Horizon worker'ları yeniden başlar

❌ Etkilenmeyenler

Oturumlar, queue job'ları, site

6

Doğrulama ve Test

Kontrol

Her şeyin düzgün çalıştığını doğrulayacağız.

Beklenen Sonuçlar

  • ✓ Fragmentation: < 2
  • ✓ Session sayısı: ~253 (aynı)
  • ✓ Site durumu: 200 OK
  • ✓ Login testi: Başarılı

Bölüm 4: Kesinlikle Yapılmayacaklar

Aşağıdaki komutlar TÜM OTURUMLARI SİLER:

🚫 Yasak Redis Komutları

  • FLUSHALL

    Tüm DB'leri siler (session + cache)

  • FLUSHDB

    Aktif DB'yi siler

  • BGSAVE'siz restart

    Son kayıttan sonraki veriler kaybolur

🚫 Yasak Laravel Komutları

  • session:clear

    Tüm oturumları siler

  • auth:clear-resets

    Şifre sıfırlama token'larını siler

Özet Kontrol Listesi