[{"data":1,"prerenderedAt":40},["ShallowReactive",2],{"blog-akaunting-guncelleme-hatasi":3},{"html":4,"toc":5,"faq":27},"\u003Cp>Akaunting güncellemesi bir yüzdede takıldıysa ya da güncelleme sonrası sayfalar 500 hatası veriyorsa, ilk yapılacak şey tekrar denemek değil, durmaktır. Sorunların çoğu PHP sürümü uyumsuzluğu, bellek ve süre sınırları, dosya izinleri, uyumsuz bir uygulama ya da akaunting.com'dan yarım inen bir paketten kaynaklanır ve veriniz büyük ihtimalle yerindedir. Güvenli kurtarma, mevcut bozuk durumun yedeğini almakla ve \u003Ccode>storage\u002Flogs\u003C\u002Fcode> altındaki günlükleri okumakla başlar.\u003C\u002Fp>\n\u003Ch2 id=\"guncelleme-sirasinda-arka-planda-ne-oluyor\">Güncelleme sırasında arka planda ne oluyor?\u003C\u002Fh2>\n\u003Cp>Tek tuşla güncelleme bir dizi adımdan oluşuyor ve ilerleme çubuğundaki yüzde, kabaca hangi adımda olduğunuzu söylüyor:\u003C\u002Fp>\n\u003Col>\n\u003Cli>\u003Cstrong>İndirme:\u003C\u002Fstrong> yeni çekirdek ya da uygulama paketi akaunting.com'dan indiriliyor.\u003C\u002Fli>\n\u003Cli>\u003Cstrong>Açma:\u003C\u002Fstrong> paket sunucuda geçici bir klasöre açılıyor.\u003C\u002Fli>\n\u003Cli>\u003Cstrong>Kopyalama:\u003C\u002Fstrong> yeni dosyalar mevcut dosyaların üzerine yazılıyor.\u003C\u002Fli>\n\u003Cli>\u003Cstrong>Veritabanı değişiklikleri:\u003C\u002Fstrong> yeni sürümün migration'ları çalışıyor, tablolar ve kolonlar güncelleniyor.\u003C\u002Fli>\n\u003Cli>\u003Cstrong>Bitiş:\u003C\u002Fstrong> önbellekler temizleniyor, sürüm bilgisi güncelleniyor, son işler yapılıyor.\u003C\u002Fli>\n\u003C\u002Fol>\n\u003Cp>Bu sıralama önemli, çünkü sorunun nerede olduğunu ve ne kadar ciddi olduğunu belirliyor. İndirme aşamasında takılan bir güncelleme genellikle hiçbir şeyi değiştirmemiştir. Veritabanı aşamasında kesilen bir güncelleme ise veritabanını iki şema arasında bırakmış olabilir.\u003C\u002Fp>\n\u003Ch2 id=\"en-sik-karsilasilan-nedenler\">En sık karşılaşılan nedenler\u003C\u002Fh2>\n\u003Cdiv class=\"table-scroll\">\u003Ctable>\n\u003Cthead>\n\u003Ctr>\n\u003Cth>Belirti\u003C\u002Fth>\n\u003Cth>Olası neden\u003C\u002Fth>\n\u003Cth>İlk bakılacak yer\u003C\u002Fth>\n\u003C\u002Ftr>\n\u003C\u002Fthead>\n\u003Ctbody>\u003Ctr>\n\u003Ctd>Erken yüzdede "Not able to download" benzeri hata\u003C\u002Ftd>\n\u003Ctd>Sunucunun akaunting.com'a dışa erişimi yok ya da yanıt yarım geliyor\u003C\u002Ftd>\n\u003Ctd>Sunucudan dışa HTTPS erişimi, güvenlik duvarı, proxy\u003C\u002Ftd>\n\u003C\u002Ftr>\n\u003Ctr>\n\u003Ctd>Belirli bir yüzdede sessizce duruyor\u003C\u002Ftd>\n\u003Ctd>\u003Ccode>max_execution_time\u003C\u002Fcode> veya \u003Ccode>memory_limit\u003C\u002Fcode> sınırı\u003C\u002Ftd>\n\u003Ctd>PHP-FPM ve web sunucusu hata günlükleri\u003C\u002Ftd>\n\u003C\u002Ftr>\n\u003Ctr>\n\u003Ctd>Kopyalama sonrası hata\u003C\u002Ftd>\n\u003Ctd>Dosya sahipliği ya da izinleri yanlış\u003C\u002Ftd>\n\u003Ctd>Dosyaların sahibi olan kullanıcı ile web sunucusu kullanıcısı\u003C\u002Ftd>\n\u003C\u002Ftr>\n\u003Ctr>\n\u003Ctd>Güncelleme sonrası her sayfada 500\u003C\u002Ftd>\n\u003Ctd>Yarım kalmış migration, uyumsuz uygulama veya önbellek\u003C\u002Ftd>\n\u003Ctd>\u003Ccode>storage\u002Flogs\u003C\u002Fcode> içindeki son hata\u003C\u002Ftd>\n\u003C\u002Ftr>\n\u003Ctr>\n\u003Ctd>Komut satırından çalışıyor, tarayıcıdan çalışmıyor (ya da tersi)\u003C\u002Ftd>\n\u003Ctd>CLI PHP ile web PHP'si farklı sürüm ya da eklenti eksik\u003C\u002Ftd>\n\u003Ctd>İki tarafta ayrı ayrı \u003Ccode>php -v\u003C\u002Fcode> ve eklenti listesi\u003C\u002Ftd>\n\u003C\u002Ftr>\n\u003Ctr>\n\u003Ctd>Belirli bir menü 403 ya da 500 veriyor\u003C\u002Ftd>\n\u003Ctd>Çekirdeğe uyumsuz bir App Store uygulaması\u003C\u002Ftd>\n\u003Ctd>Uygulamanın yeni çekirdeğe uygun sürümü var mı\u003C\u002Ftd>\n\u003C\u002Ftr>\n\u003C\u002Ftbody>\u003C\u002Ftable>\u003C\u002Fdiv>\n\u003Cp>Bunlara iki madde daha eklemek gerekiyor. Birincisi, yeni sürümün daha yüksek bir PHP sürümü istemesi: sunucunuz eski sürümdeyse güncelleme yeni dosyaları kopyalar ama uygulama açılmaz. İkincisi, çekirdek dosyalarda elle yapılmış değişiklikler: güncelleme bu dosyaların üzerine yazar ve değişiklik ya kaybolur ya da yeni kodla çakışır.\u003C\u002Fp>\n\u003Ch3 id=\"uyumsuz-bir-uygulamayi-nasil-anlarsiniz\">Uyumsuz bir uygulamayı nasıl anlarsınız?\u003C\u002Fh3>\n\u003Cp>Akaunting'de App Store uygulamaları çekirdekten bağımsız sürümlenir, ama çekirdeğe sıkı bağlıdır. Çekirdek yeni bir sürüme geçtiğinde, uygulamanın da o sürümle birlikte yayımlanmış sürümüne geçmesi gerekir. Geliştiricisi güncelleme çıkarmamış bir uygulama, çekirdeğin artık sağlamadığı bir sınıfı ya da metodu çağırabilir.\u003C\u002Fp>\n\u003Cp>Belirtisi genellikle seçicidir: uygulamanın kendi ekranları 500 verir, diğer ekranlar çalışır. Günlükte hata satırının yolu \u003Ccode>modules\u002F\u003C\u002Fcode> altındaki bir klasörü gösteriyorsa, şüpheli büyük ihtimalle o uygulamadır. Bu durumda uygulamayı yönetim panelinden devre dışı bırakmak, sistemi geçici olarak kullanılabilir hale getirebilir; ancak uygulamayı silmek, ona ait verileri de götürebileceği için ilk hamle olmamalı.\u003C\u002Fp>\n\u003Cp>Kurulumunuzun bu maddelere ne kadar hazır olduğunu görmek isterseniz, \u003Ca href=\"\u002Fblog\u002Fakaunting-kurulum-gereksinimleri\">Akaunting kurulum gereksinimleri yazımızdaki\u003C\u002Fa> kontrol listesi iyi bir başlangıç.\u003C\u002Fp>\n\u003Ch2 id=\"yapmamaniz-gerekenler\">Yapmamanız gerekenler\u003C\u002Fh2>\n\u003Cp>Panik anında yapılan müdahaleler, çoğu zaman sorunu asıl nedeninden daha büyük hale getiriyor. Kaçınılması gerekenler:\u003C\u002Fp>\n\u003Cul>\n\u003Cli>\u003Cstrong>Güncellemeyi defalarca yeniden başlatmak.\u003C\u002Fstrong> Yarım çalışmış bir migration varken ikinci deneme genellikle "tablo zaten var" ya da benzeri bir hata verir. Bu yeni hata, ilk sorunun üstünü örter.\u003C\u002Fli>\n\u003Cli>\u003Cstrong>Klasör silmek.\u003C\u002Fstrong> \u003Ccode>vendor\u003C\u002Fcode>, \u003Ccode>modules\u003C\u002Fcode> ya da \u003Ccode>storage\u003C\u002Fcode> klasörlerini "temizlemek" için silmek, kurulu uygulamaları ve fatura eklerini geri dönüşü zor şekilde kaybettirebilir.\u003C\u002Fli>\n\u003Cli>\u003Cstrong>Bütün dosyalara 777 izni vermek.\u003C\u002Fstrong> Bir izin sorununu çözer gibi görünür, ama sunucuyu açık bırakır ve asıl sahiplik sorununu gizler.\u003C\u002Fli>\n\u003Cli>\u003Cstrong>Yedeği almadan eski bir yedeği geri yüklemek.\u003C\u002Fstrong> Son yedekten bu yana kesilen faturalar varsa onları kaybedersiniz. Önce mevcut durumu, bozuk da olsa, yedekleyin.\u003C\u002Fli>\n\u003Cli>\u003Cstrong>Veritabanında elle tablo silmek ya da kolon eklemek.\u003C\u002Fstrong> Migration geçmişiyle tablo yapısı uyumsuz hale gelir ve sonraki her güncelleme risk taşır.\u003C\u002Fli>\n\u003Cli>\u003Cstrong>Yalnızca veritabanını geri yüklemek.\u003C\u002Fstrong> \u003Ccode>storage\u003C\u002Fcode> klasörü dahil edilmezse ekler kaybolur; dosya ve veritabanı farklı sürümlerde kalırsa uygulama açılmaz.\u003C\u002Fli>\n\u003C\u002Ful>\n\u003Ch2 id=\"guvenli-kurtarma-sirasi\">Güvenli kurtarma sırası\u003C\u002Fh2>\n\u003Cp>Aşağıdaki sıra, her durumda işe yarayan bir çerçeve. Hangi adımda ne yapılacağı, günlükte gördüğünüz hataya göre değişiyor.\u003C\u002Fp>\n\u003Col>\n\u003Cli>\u003Cstrong>Durun ve kullanıcıları bilgilendirin.\u003C\u002Fstrong> Sisteme yeni kayıt girilmesini durdurun. Mümkünse uygulamayı bakım moduna alın.\u003C\u002Fli>\n\u003Cli>\u003Cstrong>Mevcut durumu yedekleyin.\u003C\u002Fstrong> Veritabanının tam dökümünü, uygulama klasörünün tamamını (özellikle \u003Ccode>storage\u003C\u002Fcode>, \u003Ccode>modules\u003C\u002Fcode> ve \u003Ccode>.env\u003C\u002Fcode>) olduğu gibi kopyalayın. Sunucu sağlayıcınız destekliyorsa bir disk snapshot'ı alın. Bozuk bir durum da üzerinde çalışılabilecek bir durumdur; kaybolmuş bir durum değildir.\u003C\u002Fli>\n\u003Cli>\u003Cstrong>Hangi sürümden hangi sürüme gittiğinizi not edin.\u003C\u002Fstrong> Ayrıca hangi uygulamaların kurulu olduğunu ve güncellemenin hangi yüzdede durduğunu yazın.\u003C\u002Fli>\n\u003Cli>\u003Cstrong>Günlükleri okuyun.\u003C\u002Fstrong> \u003Ccode>storage\u002Flogs\u003C\u002Fcode> altındaki en son günlük dosyasında, güncelleme saatine denk gelen ilk hata satırını bulun. Ardından web sunucusu ve PHP-FPM hata günlüklerine bakın. Aradığınız şey son hata değil, \u003Cem>ilk\u003C\u002Fem> hata.\u003C\u002Fli>\n\u003Cli>\u003Cstrong>Aşamayı belirleyin.\u003C\u002Fstrong> Hata indirme ya da açma aşamasındaysa dosyalar büyük ihtimalle değişmemiştir. Kopyalama ya da migration aşamasındaysa, kurulum iki sürüm arasında kalmıştır.\u003C\u002Fli>\n\u003Cli>\u003Cstrong>Tamamlamaya mı geri almaya mı karar verin.\u003C\u002Fstrong> Neden belliyse ve giderilebiliyorsa (örneğin süre sınırı), güncellemeyi bilinen bir noktadan tamamlamak mümkün olabilir. Neden belirsizse, güncelleme öncesi yedeğe geri dönüp sorunu bir kopya ortamda yeniden üretmek daha güvenli.\u003C\u002Fli>\n\u003Cli>\u003Cstrong>Önce bir kopyada deneyin.\u003C\u002Fstrong> Aldığınız yedeği ayrı bir ortama açın ve düzeltmeyi orada uygulayın. Aynı adımlar kopyada çalışmadan canlı sisteme dokunmayın.\u003C\u002Fli>\n\u003Cli>\u003Cstrong>Canlıda uygulayın ve doğrulayın.\u003C\u002Fstrong> Düzeltmeden sonra önbellekleri temizleyin; ardından faturaları, raporları, ekleri, cron'u ve e-posta gönderimini kontrol edin.\u003C\u002Fli>\n\u003C\u002Fol>\n\u003Cp>Komut satırına erişiminiz varsa, takılan güncellemeyi tarayıcı yerine artisan komutlarıyla ilerletmek çoğu zaman süre sınırlarını devreden çıkarır. Ancak bu komutları, hangi durumda olduğunuzu bilmeden çalıştırmak, kurtarma yerine yeni bir sorun yaratabilir.\u003C\u002Fp>\n\u003Ch2 id=\"guncellemeden-sonra-neyi-kontrol-etmelisiniz\">Güncellemeden sonra neyi kontrol etmelisiniz?\u003C\u002Fh2>\n\u003Cp>Uygulamanın açılması, güncellemenin başarılı olduğu anlamına gelmiyor. Bir sonraki iş gününden önce şunlara bakın:\u003C\u002Fp>\n\u003Cul>\n\u003Cli>\u003Cinput disabled=\"\" type=\"checkbox\"> Gelir tablosu ve vergi özeti açılıyor ve toplamlar önceki dönemle tutarlı\u003C\u002Fli>\n\u003Cli>\u003Cinput disabled=\"\" type=\"checkbox\"> Yeni bir fatura kesilebiliyor, numara otomatik artıyor\u003C\u002Fli>\n\u003Cli>\u003Cinput disabled=\"\" type=\"checkbox\"> Mevcut bir faturanın eki açılıyor, düzenleyip kaydedince ek kaybolmuyor\u003C\u002Fli>\n\u003Cli>\u003Cinput disabled=\"\" type=\"checkbox\"> PDF çıktısında Türkçe karakterler doğru görünüyor\u003C\u002Fli>\n\u003Cli>\u003Cinput disabled=\"\" type=\"checkbox\"> Tekrarlayan faturalar ve ödeme hatırlatmaları tetikleniyor\u003C\u002Fli>\n\u003Cli>\u003Cinput disabled=\"\" type=\"checkbox\"> Her uygulamanın menüsü açılıyor, yetki hatası vermiyor\u003C\u002Fli>\n\u003Cli>\u003Cinput disabled=\"\" type=\"checkbox\"> Giden e-posta gerçek bir gelen kutusuna ulaşıyor\u003C\u002Fli>\n\u003C\u002Ful>\n\u003Ch2 id=\"bir-dahaki-sefere-onleme\">Bir dahaki sefere: önleme\u003C\u002Fh2>\n\u003Cp>Güncelleme hatalarının neredeyse hepsi önceden yakalanabilir. Önerdiğimiz düzen:\u003C\u002Fp>\n\u003Cul>\n\u003Cli>\u003Cstrong>Önce kopya ortam.\u003C\u002Fstrong> Canlı veritabanının ve \u003Ccode>storage\u003C\u002Fcode> klasörünün bir kopyasını ayrı bir ortama açın; güncellemeyi ilk kez orada yapın. Kopyanın da akaunting.com'a erişimi olmalı.\u003C\u002Fli>\n\u003Cli>\u003Cstrong>Sıra: önce çekirdek, sonra uygulamalar.\u003C\u002Fstrong> Her uygulamayı, yeni çekirdek sürümüyle uyumlu sürümüne getirin. Uyumlu sürümü olmayan bir uygulama varsa, bunu güncellemeden önce bilin.\u003C\u002Fli>\n\u003Cli>\u003Cstrong>Sürüm notlarını okuyun.\u003C\u002Fstrong> Yeni sürümün PHP gereksinimi değiştiyse, önce sunucuyu hazırlayın.\u003C\u002Fli>\n\u003Cli>\u003Cstrong>Geri alma provası yapın.\u003C\u002Fstrong> Yedeğinizi bir kez gerçekten geri yükleyin. Geri yüklenmemiş bir yedek bir plan değil, bir umuttur.\u003C\u002Fli>\n\u003Cli>\u003Cstrong>Bir zaman penceresi seçin.\u003C\u002Fstrong> Ay sonu kapanışına ya da yoğun fatura dönemine denk gelmeyen, sorun çıkarsa müdahale edebileceğiniz bir zaman.\u003C\u002Fli>\n\u003Cli>\u003Cstrong>Uygulama envanteri tutun.\u003C\u002Fstrong> Kurulu her uygulamanın adını, sürümünü, ne işe yaradığını ve geliştiricisinin hâlâ güncelleme yayımlayıp yayımlamadığını bir yerde yazılı tutun. Güncelleme öncesi kontrolün yarısı bu listeden yapılır.\u003C\u002Fli>\n\u003Cli>\u003Cstrong>Çekirdek dosyalara dokunmayın.\u003C\u002Fstrong> Gereken özelleştirmeleri \u003Ca href=\"\u002Fakaunting\u002Fmodul-gelistirme\">güncellemeden etkilenmeyen bir modül\u003C\u002Fa> olarak yapın; güncelleme modülün üzerine yazmaz.\u003C\u002Fli>\n\u003C\u002Ful>\n\u003Ch2 id=\"nereden-baslamali\">Nereden başlamalı?\u003C\u002Fh2>\n\u003Cp>Şu anda takılmış bir güncellemeyle karşı karşıyaysanız: tıklamayı bırakın, mevcut durumu yedekleyin ve günlükteki ilk hatayı bulun. Bu üç adım, kendiniz devam etseniz de birinden yardım alsanız da işin en değerli kısmı. Teknik ekibiniz varsa yukarıdaki sıra, kurtarmayı kendi başınıza yapmanız için yeterli bir çerçeve sunuyor.\u003C\u002Fp>\n\u003Cp>Destek isterseniz, \u003Ca href=\"\u002Fakaunting\u002Fsurum-yukseltme\">Akaunting sürüm yükseltme ve kurtarma\u003C\u002Fa> hizmetimizde önce kurulumunuzun bugün kullanılabilir hale gelip gelemeyeceğine bakıyor, sonra güncellemeyi kopya ortamda tamamlıyor ya da geri alıyoruz. \u003Ca href=\"\u002Filetisim\">Bize yazarken\u003C\u002Fa> hangi sürümde olduğunuzu, hangi sürüme gittiğinizi ve güncellemenin nerede durduğunu ilk satıra eklemeniz yeterli.\u003C\u002Fp>\n",[6,9,12,15,18,21,24],{"id":7,"text":8},"guncelleme-sirasinda-arka-planda-ne-oluyor","Güncelleme sırasında arka planda ne oluyor?",{"id":10,"text":11},"en-sik-karsilasilan-nedenler","En sık karşılaşılan nedenler",{"id":13,"text":14},"yapmamaniz-gerekenler","Yapmamanız gerekenler",{"id":16,"text":17},"guvenli-kurtarma-sirasi","Güvenli kurtarma sırası",{"id":19,"text":20},"guncellemeden-sonra-neyi-kontrol-etmelisiniz","Güncellemeden sonra neyi kontrol etmelisiniz?",{"id":22,"text":23},"bir-dahaki-sefere-onleme","Bir dahaki sefere: önleme",{"id":25,"text":26},"nereden-baslamali","Nereden başlamalı?",[28,31,34,37],{"q":29,"a":30},"Güncelleme %20'de takıldı, tekrar denesem olur mu?","Önce denemeyin. Güncelleme yarıda kaldıysa veritabanı ve dosyalar iki sürüm arasında kalmış olabilir; ikinci deneme çoğu zaman daha anlaşılmaz bir hata üretir. Önce veritabanının ve dosyaların olduğu haliyle yedeğini alın, sonra günlük dosyalarını okuyun.",{"q":32,"a":33},"Akaunting güncelleme hatalarının günlüğü nerede?","Uygulama hataları genellikle storage\u002Flogs klasöründeki günlük dosyalarına yazılır. Buna ek olarak web sunucusunun ve PHP-FPM'in hata günlüklerine bakmak, bellek ya da süre sınırına takılan istekleri görmenizi sağlar.",{"q":35,"a":36},"Sadece çekirdeği güncelleyip uygulamaları sonra güncelleyebilir miyim?","Önerilmez. Akaunting'de uygulamaların çekirdek sürümüyle uyumlu sürümleri yayımlanır ve modül geliştiricilerinin eski çekirdeklerle geriye dönük uyumluluk tutması beklenmez. Çekirdeği güncelledikten hemen sonra uygulamaları eşleşen sürümlere getirmek gerekir.",{"q":38,"a":39},"Güncelleme sonrası 500 hatası alıyorum, veriler kayıp mı?","Çoğu zaman hayır. 500 hatası genellikle yarım kalmış bir veritabanı değişikliği, önbellek, uyumsuz bir uygulama ya da PHP sürümü kaynaklıdır ve veri yerindedir. Kesin cevap için günlük dosyasındaki hata satırına bakmak gerekir; tahminle müdahale etmek riski artırır.",1793978421341]