Miklix

Kufuta akiba ya NGINX huweka makosa muhimu ya kutenganisha katika logi ya kosa

Iliyochapishwa: 15 Februari 2025, 11:25:18 UTC

Makala hii inaelezea jinsi ya kufuta vipengee kutoka kwa akiba ya NGINX bila kuwa na faili zako za kumbukumbu zilizojaa ujumbe wa makosa. Ingawa sio njia inayopendekezwa, inaweza kuwa na manufaa katika hali zingine za makali.


Ukurasa huu ulitafsiriwa kwa mashine kutoka kwa Kiingereza ili kuifanya iweze kupatikana kwa watu wengi iwezekanavyo. Kwa bahati mbaya, utafsiri wa mashine bado sio teknolojia iliyokamilishwa, kwa hivyo makosa yanaweza kutokea. Ukipenda, unaweza kutazama toleo asili la Kiingereza hapa:

Deleting NGINX Cache Puts Critical Unlink Errors in Error Log

Maelezo katika chapisho hili yanategemea caching ya FastCGI kwenye NGINX 1.4.6 inayoendesha kwenye Ubuntu Server 14.04 x64. Inaweza au haiwezi kuwa halali kwa matoleo mengine.

(Sasisha 2025: Katika wakati kati ya niliandika chapisho la awali na sasa, mengi yamebadilika. Seva ni za haraka na za bei rahisi, kwa hivyo kwa kweli singependekeza njia iliyoelezwa katika chapisho hili ambapo ninajaribu kumaliza cache ndogo ili kuokoa vizazi vichache vya ziada vya maudhui yenye nguvu. Nitaacha yaliyomo hapa kwa kumbukumbu ya baadaye na ikiwa mtu anahitaji kwa sababu yoyote. Sijathibitisha kuwa hii bado inafanya kazi kwa matoleo ya sasa ya NGINX, ingawa, lakini nadhani inafanya hivyo).

Baada ya kuhamia tovuti kadhaa kutoka Apache hadi NGINX nimekua nikipenda sana uwezo wake wa kuweka akiba, ambayo inafanya kazi vizuri sana chini ya hali nyingi bila kuingiliwa sana kutoka kwangu.

Hata hivyo, kwa moja ya tovuti, nilihitaji sana uwezo wa kufuta akiba (wote kikamilifu na kuondoa maingizo ya mtu binafsi) mwenyewe. Toleo la bure la jamii ya NGINX inasaidia tu kumalizika kwa akiba ya wakati (yaani unaweza kuiweka ili kuangalia ikiwa kitu kimebadilika baada ya saa, siku, nk). Lakini vipi ikiwa hakuna njia ya kuaminika ya kuamua kabla ya wakati rasilimali fulani itabadilika? Kwa mfano, sijui kama itakuwa saa, siku moja au mwaka kabla ya kurudi na kuhariri kitu katika chapisho hili - na kwa nini akiba tu kwa saa ikiwa caching kwa siku ingekuwa sawa?

Hapa ndipo uwezo wa kufuta akiba kwa mikono (au kwa kuwa na programu yako ya wavuti kuwajulisha NGINX kwamba kitu kinapaswa kusafishwa) inahitajika. Watu nyuma ya NGINX wanajua wazi hitaji la hii kwani kipengele kinaungwa mkono katika toleo la kulipwa la bidhaa zao - lakini wakati wana haki ya kuanzisha leseni yao kwa njia yoyote wanayotaka, bei ni mwinuko kidogo kwangu wakati kazi hii ndio kipengele pekee cha kulipwa ninachohitaji.

Kwa bahati nzuri, inageuka kuwa unaweza kufuta faili kutoka kwa saraka ya kache mwenyewe na NGINX itachukua hii na kupata nakala mpya kutoka kwa mwisho wako wa nyuma bila hitch. Hata hivyo, ikiwa utafanya hivyo bila kurekebisha usanidi wako unaweza kuona kundi zima la ujumbe sawa na huu kwenye kumbukumbu yako ya kosa baada ya muda:

2015/03/04 17:35:24 [crit] 16665#0: unlink() \"/path/to/nginx/cache/9/a0/53eb903773998c16dcc570e6daebda09\" failed (2: No such file or directory)

Inaonekana kwamba makosa haya hutokea wakati NGINX yenyewe inajaribu kufuta maingizo ya kache baada ya muda uliobainishwa na parameta isiyotumika ya maagizo ya fastcgi_cache_path . Chaguo-msingi kwa hii ni dakika 10 tu, lakini unaweza kuiweka kwa thamani yoyote unayotaka. Ikiwa utaiweka, sema, miaka 10, labda haiwezekani kwamba haujaanzisha upya seva kwa wakati huo huo kwa hivyo index muhimu katika kumbukumbu ingekuwa imesafishwa wakati huo huo. Ikiwa unafanya hivyo, unahitaji kuhakikisha kuwa unasafisha kashe mwenyewe, NGINX haitakufanyia tena.

Ninaona ni ajabu sana kwamba inachukuliwa kuwa kosa muhimu kwamba ingizo la kache haliwezi kufutwa kwa sababu haipo. Ukweli kwamba uainishaji wake wa ukali ni wa juu sana inamaanisha kuwa haiwezekani kuondoa tu kwa kupuuza maingizo ya kumbukumbu chini ya kizingiti fulani. Mara tu nakala mpya inapotolewa kutoka mwisho wa nyuma kuingia itakuwepo tena, kwa hivyo hii inapaswa kuwa onyo zaidi, kwa maoni yangu.

Sasa, ikiwa ingizo la kache halingeweza kufutwa kwa sababu ya matatizo na ruhusa au kitu cha tatu, hiyo itakuwa kosa muhimu, kwa sababu inaweza kufanya NGINX kuendelea kutumikia maudhui yaliyohifadhiwa muda mrefu baada ya muda wake wa kumalizika, lakini mchakato wa kusafisha hauonekani kufanya tofauti hii.

Shiriki kwenye BlueskyShiriki kwenye FacebookShiriki kwenye LinkedInShiriki kwenye TumblrShiriki kwenye XShiriki kwenye LinkedInBandika kwenye Pinterest

Mikkel Bang Christensen

Kuhusu Mwandishi

Mikkel Bang Christensen
Mikkel ndiye muundaji na mmiliki wa miklix.com. Ana uzoefu wa zaidi ya miaka 20 kama mtaalamu wa kupanga programu/programu za kompyuta na kwa sasa ameajiriwa muda wote kwa shirika kubwa la IT la Ulaya. Wakati si kublogi, yeye hutumia wakati wake wa ziada kwenye safu nyingi za mapendeleo, vitu vya kufurahisha, na shughuli, ambazo zinaweza kuonyeshwa kwa kadiri fulani katika mada anuwai zinazozungumziwa kwenye wavuti hii.