Kuamsha Database Bila Miunganisho Iliyokufa

Apps zilizochapishwa kwenye Mythex, pamoja na database zao, huenda kulala wakati hakuna anayezitumia. App ilipoamka, ingeweza kushikilia ombi lake la kwanza kwa sekunde 10–12, kwa sababu ilijaribu kutumia tena miunganisho ya database iliyokufa wakati kila kitu kilikuwa kimelala. Sasa tunapa apps za Spring Boot mipangilio ya database iliyo salama baada ya kulala, na tunamwambia agent ajenge apps za stack yoyote kwa namna hiyo hiyo. Kwenye jukwaa la hosting, ombi la kwanza baada ya kuamka lilitoka sekunde 12.7 hadi sekunde 2.3.

Kwa nini apps na databases hulala

App iliyochapishwa ya Mythex inaendeshwa kwenye mashine inayosimama baada ya dakika chache za kutotumika, na database yake ni Postgres ya serverless inayolala baada ya dakika tano za kutotumika na kuamka kwenye ombi linalofuata. Hiyo ndiyo inayofanya app tulivu iwe nafuu: unalipia kile database ilichotumia kweli, na app iliyolala haitumii chochote kwenye compute. Tuliandika kuhusu upande wa bili katika kutoza database kwa kile zinachotumia kweli.

Tatizo ni kwamba zinalala kila moja kivyake, na hazikubaliani kuhusu maana ya muunganisho.

Dalili: ziara ya kwanza ya polepole

Seva nyingi za app huhifadhi connection pool: idadi ndogo ya miunganisho wazi ya database iliyoandaliwa, ili kila ombi lisilipe gharama ya kufungua mpya. Hiyo ndiyo muundo sahihi kwa app inayowashwa muda wote.

Hivi ndivyo kinachotokea na usingizi:

1. App inaendeshwa, na miunganisho michache isiyotumika kwenye pool yake.
2. Hakuna anayetembelea. Mashine ya app inasimama — imegandishwa, pool yake ikiwa bado ipo.
3. Database inalala na kuachilia upande wake wa kila muunganisho.
4. Mgeni anafika. App inaamka kama ilivyokuwa, bado ikishikilia miunganisho ambayo database haiijui tena.
5. Pool inatoa mojawapo ya miunganisho hiyo. Lazima ijue kwamba imekufa — kwa kuijaribu na kusubiri — kabla ya kuiachilia.

Kwenye app ya Spring Boot, kuthibitisha miunganisho hiyo iliyokufa kulizuia ombi la kwanza kwa takriban sekunde 10 kabla ya kushindwa na “Connection is not available”. Kwa mgeni, tovuti ilionekana tu imeganda, kisha labda ikaonyesha hitilafu.

Kwa nini apps za Spring ziliathirika zaidi

Spring Boot ni framework maarufu ya Java, na inatumia pool ya miunganisho inayoitwa HikariCP kwa chaguo-msingi. Spring inaweza kusanidi pool hiyo kutoka kwenye mipangilio, ikiwemo miunganisho mingapi ya kutotumika ya kuweka wazi.

Lakini Mythex inampa kila app database yake kama DATABASE_URL moja katika umbo la postgresql://user:pass@host/db. Spring haiwezi kusoma muundo huo moja kwa moja. Kwa hiyo apps za Spring zilizojengwa kwenye Mythex zilikuwa zikijenga pool yao wenyewe kwenye msimbo kwa kuchambua URL hiyo — na pool iliyojengwa kwa mkono inapuuza mipangilio yote ya Spring ya spring.datasource.*. Hata kama mtu alijua mipangilio sahihi ya pool, hapakuwa na mahali ambapo ingetumika.

Suluhisho, sehemu ya 1: mipangilio ambayo Spring inaweza kuitumia

Mradi ukiwa na database, sasa pia unapewa vigezo vya mazingira ambavyo Spring inavisoma moja kwa moja:

• SPRING_DATASOURCE_URL, SPRING_DATASOURCE_USERNAME na SPRING_DATASOURCE_PASSWORD, vinavyobadilishwa kutoka DATABASE_URL (ikiwa na SSL inayohitajika isipokuwa URL inasema vinginevyo).
• Mipangilio ya pool inayonusurika usingizi:

Bila miunganisho ya kutotumika iliyoshikiliwa, app iliyoamka hufungua muunganisho mmoja mpya badala ya kupitia miunganisho iliyokufa.

Vigezo hivi vikiwepo, Spring inasanidi pool yenyewe, na mipangilio inatumika. Chochote ambacho mradi umekiweka wenyewe daima kinashinda; sisi tunajaza tu kile kinachokosekana. Apps zisizo za Spring zinapuuza vigezo hivi.

Maelezo yaliyokaribia kuifanya isifanye kitu

Spring inaweka vigezo vya mazingira kwenye mipangilio yake kwa kanuni ambayo ni rahisi kuikosea. Mpangilio minimum-idle lazima uandikwe kama SPRING_DATASOURCE_HIKARI_MINIMUMIDLE — dashi zimeondolewa, maneno yameungana. Kuuandika kama SPRING_DATASOURCE_HIKARI_MINIMUM_IDLE, ambayo inaonekana ya asili zaidi, inaelekeza kwenye mpangilio mwingine usiokuwepo (minimum.idle) na inapuuzwa kimya kimya.

Huu ni aina ya kosa linalopita kila ukaguzi na lisifanye chochote kwenye uzalishaji. Kwa hiyo jaribio linakagua mambo mawili: kwamba thamani zimewekwa, na kwamba hakuna kigezo kinachotumia umbo lenye mistari ya chini.

Suluhisho, sehemu ya 2: stack zote nyingine

Spring si framework pekee yenye pool, na hatuwezi kusanidi kila maktaba katika kila lugha mapema. Kwa hiyo agent wa Mythex — AI inayoandika app yako — sasa ana maelekezo ya kudumu kwa stack yoyote: apps zilizochapishwa na database zao hulala zikiwa hazitumiki, kwa hiyo muunganisho uliowekwa wazi unaweza kuwa umekufa kwenye ombi linalofuata. Inapaswa:

• kutoweka miunganisho ya database ya kutotumika wazi, au kuthibitisha kila moja kabla ya matumizi,
• kujaribu tena mara moja kwenye hitilafu ya muunganisho, na
• kutumia mipangilio ya database ambayo jukwaa linatoa kwenye mazingira, badala ya kujenga pool yake kwa kuchambua DATABASE_URL.

Nukta ya mwisho inafunga mzunguko na sehemu ya 1: app iliyojengwa kwa mipangilio iliyotolewa inachukua usanidi salama wa usingizi kiotomatiki.

Matokeo

Kwa kupima kwenye jukwaa la hosting tunalotumia kwa apps zilizochapishwa, ombi la kwanza baada ya kuamka lilitoka sekunde 12.7 hadi sekunde 2.3.

Tulichojifunza

• Kila tabaka linalolala linapaswa kukubaliana kile kinachonusurika. App iliyogandishwa na database iliyolala kila moja ilifanya uchaguzi wa busara. Pamoja, app iliamka ikishikilia hali ambayo haikuwa kweli tena.
• Chaguo-msingi zilizoundwa kwa seva zinazowashwa muda wote hazifai apps zinazopunguzwa hadi sifuri. Kuweka miunganisho joto ni wazo zuri hadi kila kitu kinachoizunguka kipoe.
• Wape frameworks data yao katika umbo lao wenyewe. URL moja ilikuwa rahisi kwetu na ililazimisha kila app ya Spring kujenga pool kwa mkono iliyopuuza usanidi wake wenyewe.
• Jaribu kwamba mpangilio umeandikwa kwa namna framework inavyoisoma. Thamani sahihi chini ya jina lisilo sahihi haifanyi chochote, kimya kimya.

Ikiwa ni mgeni katika jinsi databases zinavyofanya kazi kwenye Mythex, angalia nyaraka za database na maelezo yetu kuhusu Postgres ni nini.