Iminumungkahi kong basahin mo ang transcript ng ulat mula sa simula ng 2016 ni Andrey Salnikov "Mga karaniwang error sa mga application na humahantong sa bloat sa postgresql"
Sa ulat na ito, susuriin ko ang mga pangunahing error sa mga application na lumitaw sa yugto ng pagdidisenyo at pagsulat ng code ng aplikasyon. At kukunin ko lamang ang mga error na humahantong sa bloat sa Postgresql. Bilang isang patakaran, ito ang simula ng pagtatapos ng pagganap ng iyong system sa kabuuan, kahit na sa una ay walang nakikitang mga kinakailangan para dito.
Malugod na tinatanggap ang lahat! Ang ulat na ito ay hindi kasing teknikal ng nauna mula sa aking kasamahan. Ang ulat na ito ay pangunahing nakatuon sa mga backend system developer dahil mayroon kaming medyo malaking bilang ng mga kliyente. At lahat sila ay gumagawa ng parehong mga pagkakamali. Sasabihin ko sa iyo ang tungkol sa kanila. Ipapaliwanag ko kung ano ang mga nakamamatay at masamang bagay na dulot ng mga pagkakamaling ito.
Bakit nagkakamali? Ginagawa ang mga ito para sa dalawang kadahilanan: nang random, marahil ito ay gagana at dahil sa kamangmangan ng ilang mga mekanismo na nangyayari sa antas sa pagitan ng database at ng application, pati na rin sa database mismo.
Bibigyan kita ng tatlong halimbawa na may kakila-kilabot na mga larawan kung gaano kasama ang nangyari. Sasabihin ko sa iyo ang tungkol sa mekanismo na nangyayari doon. At kung paano haharapin ang mga ito, kapag nangyari ang mga ito, at kung anong mga paraan ng pag-iwas ang gagamitin upang maiwasan ang mga pagkakamali. Sasabihin ko sa iyo ang tungkol sa mga pantulong na tool at magbibigay ng mga kapaki-pakinabang na link.
Gumamit ako ng isang database ng pagsubok kung saan mayroon akong dalawang talahanayan. Ang isang plato ay may mga account ng customer, ang isa ay may mga transaksyon sa mga account na ito. At sa ilang dalas ay ina-update namin ang mga balanse sa mga account na ito.
Paunang data ng plato: ito ay medyo maliit, 2 MB. Ang oras ng pagtugon para sa database at partikular para sa sign ay napakahusay din. At isang medyo magandang pagkarga - 2 na operasyon bawat segundo ayon sa plato.
At sa pamamagitan ng ulat na ito ay magpapakita ako sa iyo ng mga graph upang malinaw mong maunawaan ang mga nangyayari. Palaging mayroong 2 slide na may mga graph. Ang unang slide ay kung ano ang nangyayari sa pangkalahatan sa server.
At sa ganitong sitwasyon, nakikita natin na mayroon tayong maliit na palatandaan. Ang index ay maliit sa 2 MB. Ito ang unang graph sa kaliwa.
Ang average na oras ng pagtugon sa server ay matatag at maikli din. Ito ang kanang itaas na graph.
Ipinapakita ng graph sa kaliwang ibaba ang pinakamahabang transaksyon. Nakikita namin na ang mga transaksyon ay mabilis na nakumpleto. At ang autovacuum ay hindi pa gumagana dito, dahil ito ay isang panimulang pagsubok. Patuloy itong gagana at magiging kapaki-pakinabang sa amin.
Ang pangalawang slide ay palaging nakatuon sa plate na sinusuri. Sa sitwasyong ito, patuloy naming ina-update ang mga balanse sa account ng kliyente. At nakikita namin na ang average na oras ng pagtugon para sa isang operasyon ng pag-update ay medyo maganda, mas mababa sa isang millisecond. Nakikita namin na ang mga mapagkukunan ng processor (ito ang kanang itaas na graph) ay natupok din nang pantay-pantay at medyo maliit.
Ang kanang ibabang graph ay nagpapakita kung gaano karaming operating at disk memory ang pinagdadaanan namin sa paghahanap ng aming gustong linya bago ito i-update. At ang bilang ng mga operasyon ayon sa tanda ay 2 bawat segundo, tulad ng sinabi ko sa simula.
At ngayon ay mayroon tayong trahedya. Para sa ilang kadahilanan mayroong isang mahabang nakalimutang transaksyon. Ang mga dahilan ay karaniwang lahat ay banal:
- Isa sa pinakakaraniwan ay nagsimula kaming mag-access ng isang panlabas na serbisyo sa code ng aplikasyon. At ang serbisyong ito ay hindi sumasagot sa amin. Iyon ay, nagbukas kami ng isang transaksyon, gumawa ng pagbabago sa database at nagpunta mula sa application upang magbasa ng mail o sa isa pang serbisyo sa loob ng aming imprastraktura, at sa ilang kadahilanan ay hindi ito tumugon sa amin. At ang aming session ay natigil sa isang estado kung saan hindi alam kung kailan ito malulutas.
- Ang pangalawang sitwasyon ay kapag may naganap na pagbubukod sa aming code para sa ilang kadahilanan. At maliban sa hindi namin naproseso ang pagsasara ng transaksyon. At nauwi kami sa isang hanging session na may bukas na transaksyon.
- At ang huli ay medyo karaniwang kaso din. Ito ay mababang kalidad na code. Ang ilang mga framework ay nagbubukas ng isang transaksyon. Nakabitin ito, at maaaring hindi mo alam sa application na nakabitin ito.
Saan humahantong ang mga ganitong bagay?
Hanggang sa punto na ang aming mga talahanayan at index ay nagsimulang lumaki nang husto. Ito ay eksaktong parehong bloat effect. Para sa database, ito ay nangangahulugan na ang oras ng pagtugon sa database ay tataas nang husto at ang pagkarga sa database server ay tataas. At bilang isang resulta, ang aming aplikasyon ay magdurusa. Dahil kung gumugol ka ng 10 millisecond sa iyong code sa isang kahilingan sa database, 10 milliseconds sa iyong logic, pagkatapos ang iyong function ay tumagal ng 20 milliseconds upang makumpleto. At ngayon ang iyong sitwasyon ay magiging napakalungkot.
At tingnan natin kung ano ang mangyayari. Ipinapakita ng graph sa kaliwang ibaba na mayroon kaming mahabang transaksyon. At kung titingnan natin ang itaas na kaliwang graph, makikita natin na ang laki ng table natin ay biglang tumalon mula dalawang megabytes hanggang 300 megabytes. Kasabay nito, ang dami ng data sa talahanayan ay hindi nagbago, ibig sabihin, mayroong isang medyo malaking halaga ng basura doon.
Ang pangkalahatang sitwasyon tungkol sa average na oras ng pagtugon ng server ay nagbago din ng ilang mga order ng magnitude. Iyon ay, ang lahat ng mga kahilingan sa server ay nagsimulang ganap na bumaba. At sa parehong oras, ang mga panloob na proseso ng Postgres ay inilunsad sa anyo ng autovacuum, na sinusubukang gumawa ng isang bagay at kumonsumo ng mga mapagkukunan.
Ano ang nangyayari sa ating tanda? Pareho. Ang aming average na oras ng pagtugon ayon sa sign ay tumaas ng ilang mga order ng magnitude. Partikular sa mga tuntunin ng natupok na mga mapagkukunan, nakikita namin na ang pag-load sa processor ay tumaas nang malaki. Ito ang kanang itaas na graph. At ito ay nadagdagan dahil ang processor ay kailangang mag-uri-uriin sa isang grupo ng mga walang kwentang linya sa paghahanap ng kailangan. Ito ang ibabang kanang graph. At bilang isang resulta, ang aming bilang ng mga tawag sa bawat segundo ay nagsimulang bumaba nang malaki, dahil ang database ay walang oras upang iproseso ang parehong bilang ng mga kahilingan.
Kailangan nating bumalik sa buhay. Nag-online kami at nalaman na ang mahabang transaksyon ay humahantong sa mga problema. Hinahanap at pinapatay namin ang transaksyong ito. At nagiging normal na ang lahat para sa amin. Lahat ay gumagana ayon sa nararapat.
Kami ay huminahon, ngunit pagkaraan ng ilang sandali ay nagsisimula kaming mapansin na ang aplikasyon ay hindi gumagana sa parehong paraan tulad ng bago ang emergency. Pinoproseso pa rin ang mga kahilingan nang mas mabagal, at mas mabagal. Isa at kalahati hanggang dalawang beses na mas mabagal partikular sa aking halimbawa. Mas mataas din ang load sa server kumpara sa nangyari bago ang aksidente.
At ang tanong: "Ano ang nangyayari sa base sa sandaling ito?" At ang sumusunod na sitwasyon ay nangyayari sa base. Sa transaction chart makikita mo na huminto na at wala talagang pangmatagalang transaksyon. Ngunit ang laki ng karatula ay nakamamatay na tumaas sa panahon ng aksidente. At mula noon ay hindi na sila nabawasan. Ang average na oras sa base ay nagpapatatag. At ang mga sagot ay tila darating nang sapat sa bilis na katanggap-tanggap sa amin. Naging mas aktibo ang autovacuum at nagsimulang gumawa ng isang bagay sa sign, dahil kailangan nitong magsala sa mas maraming data.
Sa partikular, ayon sa test plate na may mga account, kung saan kami nagbabago ng mga balanse: ang oras ng pagtugon para sa isang kahilingan ay tila bumalik sa normal. Ngunit sa katotohanan ito ay isa at kalahating beses na mas mataas.
At mula sa pag-load sa processor, nakita namin na ang pag-load sa processor ay hindi bumalik sa kinakailangang halaga bago ang pag-crash. At ang mga dahilan doon ay tiyak na nasa kanang ibabang graph. Ito ay makikita na ang isang tiyak na halaga ng memory ay hinahanap doon. Iyon ay, upang mahanap ang kinakailangang linya, sinasayang namin ang mga mapagkukunan ng database server habang nag-uuri sa walang silbi na data. Ang bilang ng mga transaksyon sa bawat segundo ay naging matatag.
Sa pangkalahatan ay mabuti, ngunit ang sitwasyon ay mas masahol pa kaysa noon. I-clear ang pagkasira ng database bilang resulta ng aming application na gumagana sa database na ito.
At upang maunawaan kung ano ang nangyayari doon, kung wala ka sa nakaraang ulat, ngayon ay kumuha tayo ng isang maliit na teorya. Teorya tungkol sa panloob na proseso. Bakit ang vacuum ng kotse at ano ang ginagawa nito?
Literal na maikli para sa pag-unawa. Sa isang punto ng oras mayroon kaming isang mesa. Mayroon kaming mga hilera sa mesa. Ang mga linyang ito ay maaaring maging aktibo, buhay, at kung ano ang kailangan natin ngayon. Ang mga ito ay minarkahan ng berde sa larawan. At may mga dead lines na naayos na, na-update na, at may mga lumabas na bagong entry sa kanila. At sila ay minarkahan na hindi na sila kawili-wili sa database. Ngunit sila ay nasa talahanayan dahil sa isang tampok na Postgres.
Bakit kailangan mo ng vacuum ng kotse? Sa isang punto, darating ang autovacuum, ina-access ang database at itatanong ito: "Pakibigay sa akin ang id ng pinakalumang transaksyon na kasalukuyang bukas sa database." Ibinabalik ng database ang id na ito. At ang autovacuum, umaasa dito, ay nag-uuri sa mga linya sa talahanayan. At kung nakita niya na ang ilang linya ay binago ng mas lumang mga transaksyon, may karapatan siyang markahan ang mga ito bilang mga linya na magagamit natin muli sa hinaharap sa pamamagitan ng pagsulat ng bagong data doon. Ito ay isang proseso sa background.
Sa oras na ito, patuloy kaming nagtatrabaho sa database at patuloy na gumagawa ng ilang pagbabago sa talahanayan. At sa mga linyang ito, na maaari naming gamitin muli, nagsusulat kami ng bagong data. At sa gayon ay nakakakuha tayo ng isang cycle, ibig sabihin, sa lahat ng oras na lumilitaw doon ang ilang patay na lumang linya, sa halip na ang mga ito ay nagsusulat tayo ng mga bagong linya na kailangan natin. At ito ay isang normal na estado para gumana ang PostgreSQL.
Ano ang nangyari noong aksidente? Paano nangyari ang prosesong ito doon?
Nagkaroon kami ng karatula sa ilang kondisyon, ang ilan ay buhay, ang ilang mga patay na linya. Dumating na ang vacuum ng sasakyan. Tinanong niya ang database kung ano ang aming pinakamatandang transaksyon at kung ano ang id nito. Natanggap ko ang id na ito, na maaaring maraming oras ang nakalipas, marahil sampung minuto ang nakalipas. Depende ito sa kung gaano kabigat ang load mo sa iyong database. At naghanap siya ng mga linya na maaari niyang markahan bilang reused. At wala akong nakitang ganoong mga linya sa aming mesa.
Ngunit sa oras na ito patuloy kaming nagtatrabaho sa talahanayan. Mayroon kaming ginagawa dito, i-update ito, baguhin ang data. Ano ang dapat gawin ng database sa oras na ito? Wala siyang pagpipilian kundi magdagdag ng mga bagong linya sa dulo ng umiiral na talahanayan. At sa gayon ang laki ng aming mesa ay nagsisimulang lumaki.
Sa katotohanan, kailangan namin ng mga berdeng linya upang gumana. Ngunit sa panahon ng gayong problema, lumalabas na ang porsyento ng mga berdeng linya ay napakababa sa buong talahanayan.
At kapag nagsagawa kami ng isang query, ang database ay kailangang dumaan sa lahat ng mga linya: parehong pula at berde, upang mahanap ang nais na linya. At ang epekto ng pamumulaklak ng isang mesa na may walang kwentang data ay tinatawag na "bloat", na kumakain din ng aming disk space. Tandaan, ito ay 2 MB, naging 300 MB? Ngayon, baguhin ang megabytes sa gigabytes at mabilis mong mawawala ang lahat ng iyong mapagkukunan ng disk.
Ano ang maaaring maging kahihinatnan para sa atin?
- Sa aking halimbawa, ang talahanayan at index ay lumago ng 150 beses. Ang ilan sa aming mga kliyente ay nagkaroon ng mas maraming nakamamatay na mga kaso noong nagsimula silang maubusan ng espasyo sa disk.
- Ang laki ng mga talahanayan mismo ay hindi kailanman bababa. Ang autovacuum sa ilang mga kaso ay maaaring putulin ang buntot ng mesa kung mayroon lamang mga patay na linya. Ngunit dahil may patuloy na pag-ikot, ang isang berdeng linya ay maaaring mag-freeze sa dulo at hindi ma-update, habang ang lahat ng iba ay isusulat sa isang lugar sa simula ng plato. Ngunit ito ay isang hindi malamang na kaganapan na ang iyong talahanayan mismo ay lumiit sa laki, kaya hindi ka dapat umasa para dito.
- Ang database ay kailangang pag-uri-uriin sa isang buong grupo ng mga walang kwentang linya. At nag-aaksaya kami ng mga mapagkukunan ng disk, nag-aaksaya kami ng mga mapagkukunan ng processor at kuryente.
- At ito ay direktang nakakaapekto sa aming aplikasyon, dahil kung sa simula ay gumugol kami ng 10 millisecond sa kahilingan, 10 millisecond sa aming code, pagkatapos ay sa panahon ng pag-crash nagsimula kaming gumugol ng isang segundo sa kahilingan at 10 millisecond sa code, ibig sabihin, isang order ng nabawasan ang magnitude sa performance ng application. At nang malutas ang aksidente, nagsimula kaming gumugol ng 20 millisecond sa isang kahilingan, 10 millisecond sa isang code. Nangangahulugan ito na bumaba pa rin tayo ng isa at kalahating beses sa pagiging produktibo. At lahat ng ito ay dahil sa isang transaksyon na nag-freeze, marahil dahil sa aming kasalanan.
- At ang tanong: "Paano namin maibabalik ang lahat?" upang ang lahat ay maayos sa amin at ang mga kahilingan ay dumating nang mabilis tulad ng bago ang aksidente.
Para sa layuning ito mayroong isang tiyak na cycle ng trabaho na isinasagawa.
Una kailangan nating hanapin ang mga may problemang mga talahanayan na namamaga. Naiintindihan namin na sa ilang mga talahanayan ang pag-record ay mas aktibo, sa iba ay hindi gaanong aktibo. At para dito ginagamit namin ang extension . Sa pamamagitan ng pag-install ng extension na ito, maaari kang magsulat ng mga query na makakatulong sa iyong makahanap ng mga talahanayan na medyo bloated.
Kapag nahanap mo na ang mga talahanayang ito, kailangan mong i-compress ang mga ito. Mayroon nang mga kasangkapan para dito. Sa aming kumpanya ay gumagamit kami ng tatlong mga tool. Ang una ay ang built-in na VACUUM FULL. Siya ay malupit, malupit at walang awa, ngunit kung minsan siya ay lubhang kapaki-pakinabang. ΠΈ - Ito ay mga third-party na utility para sa pag-compress ng mga talahanayan. At mas maingat nilang tinatrato ang database.
Ginagamit ang mga ito depende sa kung ano ang mas maginhawa para sa iyo. Ngunit sasabihin ko sa iyo ang tungkol dito sa pinakadulo. Ang pangunahing bagay ay mayroong tatlong mga tool. Maraming mapagpipilian.
Matapos nating itama ang lahat at matiyak na maayos ang lahat, dapat nating malaman kung paano maiwasan ang sitwasyong ito sa hinaharap:
- Madali itong mapipigilan. Kailangan mong subaybayan ang tagal ng mga session sa Master server. Lalo na mapanganib na mga session sa idle sa estado ng transaksyon. Ito yung mga kakabukas lang ng transaction, may ginawa at umalis, o nag-hang, nawala sa code.
- At para sa iyo, bilang mga developer, mahalagang subukan ang iyong code kapag lumitaw ang mga sitwasyong ito. Hindi mahirap gawin. Ito ay magiging isang kapaki-pakinabang na tseke. Maiiwasan mo ang isang malaking bilang ng mga "pambata" na problema na nauugnay sa mahabang transaksyon.
Sa mga graph na ito, gusto kong ipakita sa iyo kung paano nagbago ang sign at gawi ng database pagkatapos kong dumaan sa sign na may VACUUM FULL sa kasong ito. Ito ay hindi produksyon para sa akin.
Agad na bumalik ang laki ng talahanayan sa normal nitong estado ng pagpapatakbo ng ilang megabytes. Hindi ito lubos na nakaapekto sa average na oras ng pagtugon para sa server.
Ngunit partikular para sa aming test sign, kung saan nag-update kami ng mga balanse ng account, nakita namin na ang average na oras ng pagtugon para sa isang kahilingang i-update ang data sa sign ay ibinaba sa mga antas bago ang emergency. Ang mga mapagkukunang ginagamit ng processor upang makumpleto ang kahilingang ito ay bumaba din sa mga antas bago ang pag-crash. At ang kanang ibabang graph ay nagpapakita na ngayon ay nakita namin ang eksaktong linya na kailangan namin kaagad, nang hindi dumadaan sa mga tambak ng mga patay na linya na naroon bago ang talahanayan ay na-compress. At ang average na oras ng kahilingan ay nanatili sa humigit-kumulang sa parehong antas. Ngunit narito, mayroon akong, sa halip, isang error sa aking hardware.
Dito nagtatapos ang unang kwento. Ito ang pinakakaraniwan. At nangyayari ito sa lahat, anuman ang karanasan ng kliyente at kung gaano ka kwalipikado ang mga programmer. Maaga o huli mangyayari ito.
Ang pangalawang kuwento, kung saan ipinamahagi namin ang pag-load at ino-optimize ang mga mapagkukunan ng server
- Lumaki na kami at naging seryoso na guys. At naiintindihan namin na mayroon kaming isang kopya at ito ay mabuti para sa amin na balansehin ang pagkarga: sumulat sa Guro, at magbasa mula sa replika. At kadalasan nangyayari ang sitwasyong ito kapag gusto nating maghanda ng ilang ulat o ETL. At ang negosyo ay napakasaya tungkol dito. Talagang gusto niya ng iba't ibang mga ulat na may maraming kumplikadong analytics.
- Ang mga ulat ay tumatagal ng maraming oras, dahil ang kumplikadong analytics ay hindi maaaring kalkulahin sa millisecond. Kami, tulad ng matatapang na lalaki, sumulat ng code. Sa insertion application ginagawa namin ang pag-record sa Master, at isinasagawa ang mga ulat sa replica.
- Pamamahagi ng load.
- Lahat ay gumagana nang perpekto. Ang galing namin.
At ano ang hitsura ng sitwasyong ito? Partikular sa mga graph na ito, idinagdag ko rin ang tagal ng mga transaksyon mula sa replica para sa tagal ng transaksyon. Ang lahat ng iba pang mga graph ay tumutukoy lamang sa Master server.
Sa oras na ito, lumaki na ang aking report board. Mas marami sila. Nakikita namin na ang average na oras ng pagtugon ng server ay stable. Nakikita namin na sa replica ay mayroon kaming matagal na transaksyon na tumatakbo sa loob ng 2 oras. Nakikita namin ang tahimik na operasyon ng autovacuum, na nagpoproseso ng mga patay na linya. At lahat ay maayos sa amin.
Sa partikular, ayon sa nasubok na plato, patuloy kaming nag-a-update ng mga balanse ng account doon. At mayroon din kaming matatag na oras ng pagtugon para sa mga kahilingan, matatag na pagkonsumo ng mapagkukunan. Maayos ang lahat sa amin.
Maayos ang lahat hanggang sa sandaling magsimulang bumagsak ang mga ulat na ito dahil sa isang salungatan sa pagtitiklop. At sila ay pumutok pabalik sa mga regular na pagitan.
Nag-online kami at nagsimulang magbasa kung bakit ito nangyayari. At nakahanap kami ng solusyon.
Ang unang solusyon ay ang pagtaas ng latency ng pagtitiklop. Alam namin na ang aming ulat ay tumatakbo nang 3 oras. Itinakda namin ang pagkaantala ng pagtitiklop sa 3 oras. Inilunsad namin ang lahat, ngunit patuloy pa rin kaming nagkakaroon ng mga problema sa mga ulat kung minsan ay nakansela.
Nais naming maging perpekto ang lahat. Umakyat pa kami. At nakakita kami ng cool na setting sa Internet - hot_standby_feedback. I-on natin ito. Binibigyang-daan kami ng Hot_standby_feedback na pigilan ang autovacuum sa Master. Kaya, ganap nating inaalis ang mga salungatan sa pagtitiklop. At lahat ay gumagana nang maayos para sa amin sa mga ulat.
At ano ang nangyayari sa Master server sa oras na ito? At kami ay nasa kabuuang problema sa Master server. Ngayon ay nakikita natin ang mga graph kapag pinagana ko ang parehong mga setting na ito. At nakita namin na ang session sa aming replica kahit papaano ay nagsimulang maimpluwensyahan ang sitwasyon sa Master server. May epekto nga siya dahil na-pause niya ang autovacuum, na nag-aalis ng mga patay na linya. Ang laki na naman ng table namin. Ang average na oras ng pagpapatupad ng query sa buong database ay tumaas din. Medyo humigpit ang mga autovacuum.
Sa partikular, mula sa aming plato, nakita namin na ang pag-update ng data dito ay tumalon din sa kalangitan. Ang pagkonsumo ng CPU ay tumaas din nang malaki. Muli tayong dumaraan sa maraming patay at walang kwentang linya. At ang oras ng pagtugon para sa sign na ito at ang bilang ng mga transaksyon ay bumaba.
Ano kaya ang itsura kung hindi natin alam ang pinag-uusapan ko kanina?
- Nagsisimula kaming maghanap ng mga problema. Kung kami ay nakatagpo ng mga problema sa unang bahagi, alam namin na ito ay maaaring dahil sa isang mahabang transaksyon at pumunta sa Master. May problema tayo kay Master. Sausages siya. Umiinit ito, ang Load Average nito ay halos isang daan.
- Mabagal ang mga kahilingan doon, ngunit wala kaming nakikitang anumang matagal nang transaksyon doon. At hindi namin maintindihan kung ano ang problema. Hindi namin maintindihan kung saan titingin.
- Sinusuri namin ang kagamitan ng server. Baka bumagsak yung raid namin. Baka masunog ang memory stick natin. Oo, kahit ano ay maaaring mangyari. Ngunit hindi, bago ang mga server, lahat ay gumagana nang maayos.
- Ang lahat ay tumatakbo: mga administrator, developer at direktor. Walang nakakatulong.
- At sa ilang mga punto ang lahat ay biglang nagsisimulang itama ang sarili.
Sa oras na ito, ang kahilingan sa aming replica ay naproseso at iniwan. Natanggap namin ang ulat. Masaya pa rin ang negosyo. Tulad ng nakikita mo, ang aming tanda ay lumaki muli at hindi na lumiliit. Sa graph na may mga session, nag-iwan ako ng isang piraso ng mahabang transaksyong ito mula sa isang replica para matantya mo kung gaano katagal ito hanggang sa maging matatag ang sitwasyon.
Tapos na ang session. At pagkatapos lamang ng ilang oras ang server ay dumating nang higit pa o mas kaunti sa pagkakasunud-sunod. At ang average na oras ng pagtugon para sa mga kahilingan sa Master server ay bumalik sa normal. Dahil, sa wakas, ang autovacuum ay may pagkakataon na linisin at markahan ang mga patay na linyang ito. At sinimulan niyang gawin ang kanyang trabaho. At kung gaano kabilis niya itong ginagawa, ganoon din kabilis tayo magkakaayos.
Ayon sa nasubok na tablet, kung saan nag-a-update kami ng mga balanse ng account, nakikita namin ang eksaktong parehong larawan. Ang average na oras ng pag-update ng account ay unti-unting nag-normalize. Ang mga mapagkukunan na natupok ng processor ay nabawasan din. At ang bilang ng mga transaksyon sa bawat segundo ay bumalik sa normal. Ngunit muli kami ay bumalik sa normal, hindi katulad noong bago ang aksidente.
Sa anumang kaso, nakakakuha kami ng drawdown ng pagganap, tulad ng sa unang kaso, ng isa at kalahati hanggang dalawang beses, at kung minsan ay higit pa.
Mukhang ginawa namin ang lahat ng tama. Ipamahagi ang load. Ang kagamitan ay hindi idle. Hinati namin ang mga kahilingan ayon sa aming mga isip, ngunit ang lahat ay naging masama.
- Huwag paganahin ang hot_standby_feedback? Oo, hindi inirerekomenda na i-on ito nang walang partikular na malakas na dahilan. Dahil ang twist na ito ay direktang nakakaapekto sa Master server at sinuspinde ang operasyon ng autovacuum doon. Sa pamamagitan ng pagpapagana nito sa ilang replika at paglimot dito, maaari mong patayin ang Master at makakuha ng malalaking problema sa application.
- Dagdagan ang max_standby_streaming_delay? Oo, para sa mga ulat ito ay totoo. Kung mayroon kang tatlong oras na ulat at ayaw mong mag-crash ito dahil sa mga salungatan sa pagtitiklop, dagdagan lang ang pagkaantala. Ang isang pangmatagalang ulat ay hindi kailanman nangangailangan ng data na dumating na sa database sa ngayon. Kung mayroon ka nito sa loob ng tatlong oras, pinapatakbo mo ito para sa ilang lumang panahon ng data. At para sa iyo, kung mayroong tatlong oras na pagkaantala o anim na oras na pagkaantala ay hindi magkakaroon ng anumang pagkakaiba, ngunit makakatanggap ka ng mga ulat nang tuluy-tuloy at hindi magkakaroon ng anumang mga problema sa pagbagsak ng mga ito.
- Naturally, kailangan mong kontrolin ang mahahabang session sa mga replika, lalo na kung magpasya kang paganahin ang hot_standby_feedback sa isang replika. Dahil kahit ano pwedeng mangyari. Ibinigay namin ang replica na ito sa developer para masubukan niya ang mga kahilingan. Sumulat siya ng isang nakakabaliw na kahilingan. Inilunsad niya ito at umalis upang uminom ng tsaa, at nakuha namin ang itinatag na Guro. O baka maling application ang inilagay namin doon. Iba-iba ang mga sitwasyon. Ang mga sesyon sa mga replika ay dapat na subaybayan nang maingat tulad ng sa Master.
- At kung mayroon kang mabilis at mahabang mga query sa mga replika, kung gayon sa kasong ito ay mas mahusay na hatiin ang mga ito upang maipamahagi ang pagkarga. Ito ay isang link sa streaming_delay. Para sa mga mabilis, magkaroon ng isang replika na may maliit na pagkaantala sa pagtitiklop. Para sa mga matagal nang kahilingan sa pag-uulat, magkaroon ng replica na maaaring ma-lag ng 6 na oras o isang araw. Ito ay isang ganap na normal na sitwasyon.
Tinatanggal namin ang mga kahihinatnan sa parehong paraan:
- Nakahanap kami ng mga bloated table.
- At i-compress namin ito gamit ang pinaka-maginhawang tool na nababagay sa amin.
Dito nagtatapos ang pangalawang kwento. Lumipat tayo sa ikatlong kuwento.
Medyo karaniwan din para sa atin kung saan tayo nagmigrate.
- Ang anumang produkto ng software ay lumalaki. Ang mga kinakailangan para dito ay nagbabago. Sa anumang kaso, gusto naming umunlad. At nangyayari na kailangan naming i-update ang data sa talahanayan, lalo na upang magpatakbo ng isang update sa mga tuntunin ng aming paglipat para sa bagong functionality na ipinapakilala namin bilang bahagi ng aming pag-unlad.
- Ang lumang format ng data ay hindi kasiya-siya. Sabihin nating bumaling tayo ngayon sa pangalawang talahanayan, kung saan mayroon akong mga transaksyon sa mga account na ito. At sabihin nating nasa rubles sila, at nagpasya kaming dagdagan ang katumpakan at gawin ito sa kopecks. At para dito kailangan nating gumawa ng pag-update: i-multiply ang field na may halaga ng transaksyon sa isang daan.
- Sa mundo ngayon, gumagamit kami ng mga awtomatikong tool sa pagkontrol ng bersyon ng database. Sabihin nating . Inirehistro namin ang aming migration doon. Sinusubukan namin ito sa aming base ng pagsubok. Maayos ang lahat. Ang pag-update ay nangyayari. Hinaharang nito ang trabaho nang ilang sandali, ngunit nakakakuha kami ng na-update na data. At maaari kaming maglunsad ng bagong pag-andar dito. Sinuri at nasuri ang lahat. Nakumpirma ang lahat.
- Nagsagawa kami ng nakaplanong gawain at nagsagawa ng migration.
Narito ang paglipat kasama ang pag-update na ipinakita sa harap mo. Dahil ito ang aking mga transaksyon sa account, ang plato ay 15 GB. At dahil ina-update namin ang bawat linya, dinoble namin ang laki ng talahanayan kasama ang pag-update, dahil muling isinulat namin ang bawat linya.
Sa panahon ng paglipat, wala kaming magagawa sa plate na ito, dahil ang lahat ng kahilingan dito ay nakapila at naghintay hanggang sa makumpleto ang update na ito. Ngunit dito gusto kong iguhit ang iyong pansin sa mga numero na nasa vertical axis. Iyon ay, mayroon kaming isang average na oras ng kahilingan bago ang paglipat ng mga 5 millisecond at ang pag-load ng processor, ang bilang ng mga block operation para sa pagbabasa ng memorya ng disk ay mas mababa sa 7,5.
Isinagawa namin ang migration at nagkaroon muli ng mga problema.
Ang paglipat ay matagumpay, ngunit:
- Mas matagal na ngayong makumpleto ang lumang functionality.
- Lumaki muli ang mesa.
- Ang load sa server ay muling naging mas malaki kaysa dati.
- At, siyempre, pinag-iisipan pa rin namin ang functionality na gumana nang maayos, pinabuti namin ito ng kaunti.
At ito na naman ang namamaga, na muling sumisira sa ating buhay.
Dito ko ipinapakita na ang talahanayan, tulad ng nakaraang dalawang kaso, ay hindi babalik sa mga dating sukat nito. Ang average na pag-load ng server ay tila sapat.
At kung babalik tayo sa talahanayan na may mga account, makikita natin na dumoble ang average na oras ng kahilingan para sa talahanayang ito. Ang pag-load sa processor at ang bilang ng mga linya na inayos sa memorya ay tumalon sa itaas ng 7,5, ngunit mas mababa. At tumalon ito ng 2 beses sa kaso ng mga processor, 1,5 beses sa kaso ng block operations, i.e. nagkaroon kami ng degradation sa performance ng server. At bilang isang resulta - pagkasira ng pagganap ng aming aplikasyon. Kasabay nito, ang bilang ng mga tawag ay nanatiling humigit-kumulang sa parehong antas.
At ang pangunahing bagay dito ay upang maunawaan kung paano gawin ang mga naturang migrasyon nang tama. At kailangan nilang gawin. Ginagawa namin ang mga paglilipat na ito nang medyo pare-pareho.
- Ang ganitong malalaking migrasyon ay hindi awtomatikong nangyayari. Dapat silang laging nasa ilalim ng kontrol.
- Ang pangangasiwa ng isang taong may kaalaman ay kinakailangan. Kung mayroon kang DBA sa iyong koponan, hayaan ang DBA na gawin ito. Trabaho niya ito. Kung hindi, hayaan ang pinaka may karanasan na tao na gawin ito, na nakakaalam kung paano magtrabaho sa mga database.
- Isang bagong database schema, kahit na mag-update kami ng isang column, palagi kaming naghahanda sa mga yugto, ibig sabihin, nang maaga bago ilunsad ang bagong bersyon ng application:
- Nagdaragdag ng mga bagong field kung saan ire-record namin ang na-update na data.
- Naglilipat kami ng data mula sa lumang field patungo sa bagong field sa maliliit na bahagi. Bakit natin ito ginagawa? Una, palagi naming kinokontrol ang proseso ng prosesong ito. Alam namin na marami na kaming nalipat na batch at marami na kaming natira.
- At ang pangalawang positibong epekto ay na sa pagitan ng bawat naturang batch ay isinasara natin ang transaksyon, nagbukas ng bago, at pinapayagan nito ang autovacuum na gumana ayon sa plato, markahan ang mga patay na linya para magamit muli.
- Para sa mga linyang lalabas habang tumatakbo ang application (mayroon pa kaming lumang application na tumatakbo), nagdaragdag kami ng trigger na nagsusulat ng mga bagong value sa mga bagong field. Sa aming kaso, ito ay multiplikasyon sa isang daan ng lumang halaga.
- Kung kami ay ganap na matigas ang ulo at gusto ang parehong field, pagkatapos ay matapos ang lahat ng paglilipat at bago ilunsad ang isang bagong bersyon ng application, pinapalitan lang namin ang pangalan ng mga field. Ang mga luma ay binibigyan ng ilang naimbentong pangalan, at ang mga bagong field ay pinalitan ng pangalan sa mga luma.
- At pagkatapos lamang nito ay naglulunsad kami ng bagong bersyon ng application.
At kasabay nito ay hindi tayo makakakuha ng bloat at hindi magdurusa sa mga tuntunin ng pagganap.
Dito nagtatapos ang ikatlong kwento.
At ngayon ng kaunti pang detalye tungkol sa mga tool na nabanggit ko sa pinakaunang kuwento.
Bago maghanap ng bloat, dapat mong i-install ang extension .
Upang hindi mo na kailangang gumawa ng mga query, naisulat na namin ang mga query na ito sa aming trabaho. Maaari mong gamitin ang mga ito. Mayroong dalawang kahilingan dito.
- Ang una ay tumatagal ng medyo mahabang oras upang gumana, ngunit ipapakita nito sa iyo ang eksaktong mga halaga ng bloat mula sa talahanayan.
- Ang pangalawa ay gumagana nang mas mabilis at napaka-epektibo kapag kailangan mong mabilis na masuri kung may bloat o wala ayon sa talahanayan. At dapat mo ring maunawaan na ang bloat ay palaging naroroon sa isang talahanayan ng Postgres. Ito ay isang tampok ng MVCC model nito.
- At 20% bloat ay normal para sa mga talahanayan sa karamihan ng mga kaso. Iyon ay, hindi ka dapat mag-alala at i-compress ang talahanayan na ito.
Naisip namin kung paano matukoy ang mga talahanayan na namamaga ng walang kwentang data.
Ngayon tungkol sa kung paano ayusin ang bloat:
- Kung mayroon kaming maliit na tablet at magagandang disk, iyon ay, sa isang tablet hanggang sa isang gigabyte, posible na gumamit ng VACUUM FULL. Kukunin niya ang isang eksklusibong lock mula sa iyo sa mesa sa loob ng ilang segundo at okay, ngunit gagawin niya ang lahat nang mabilis at malupit. Ano ang ginagawa ng VACUUM FULL? Ito ay nangangailangan ng isang eksklusibong lock sa talahanayan at muling isinusulat ang mga live na hilera mula sa mga lumang talahanayan patungo sa bagong talahanayan. At sa huli ay pinapalitan niya sila. Tinatanggal nito ang mga lumang file at pinapalitan ang mga luma ng mga bago. Ngunit para sa tagal ng trabaho nito, nangangailangan ito ng eksklusibong lock sa mesa. Nangangahulugan ito na wala kang magagawa sa talahanayang ito: huwag sumulat dito, o basahin ito, o baguhin ito. At ang VACUUM FULL ay nangangailangan ng karagdagang espasyo sa disk para makapagsulat ng data.
- Susunod na tool . Sa prinsipyo nito, ito ay halos kapareho sa VACUUM FULL, dahil isinusulat din nito ang data mula sa mga lumang file patungo sa mga bago at pinapalitan ang mga ito sa talahanayan. Ngunit sa parehong oras, hindi ito kumukuha ng isang eksklusibong lock sa mesa sa pinakadulo simula ng trabaho nito, ngunit tumatagal lamang ito sa sandaling mayroon na itong handa na data upang mapalitan ang mga file. Ang mga kinakailangan sa mapagkukunan ng disk nito ay katulad ng sa VACUUM FULL. Kailangan mo ng karagdagang espasyo sa disk, at kung minsan ay kritikal ito kung mayroon kang mga terabyte na talahanayan. At ito ay medyo gutom sa processor dahil ito ay aktibong gumagana sa I/O.
- Ang ikatlong utility ay . Mas maingat ito sa mga mapagkukunan dahil gumagana ito ayon sa bahagyang magkakaibang mga prinsipyo. Ang pangunahing ideya ng pgcompacttable ay ang paglipat ng lahat ng mga live na hilera sa simula ng talahanayan gamit ang mga update sa talahanayan. At pagkatapos ay nagpapatakbo ito ng vacuum sa talahanayang ito, dahil alam natin na mayroon tayong mga live na hilera sa simula at mga patay na hilera sa dulo. At ang vacuum mismo ay pinutol ang buntot na ito, ibig sabihin, hindi ito nangangailangan ng maraming karagdagang espasyo sa disk. At sa parehong oras, maaari pa rin itong pisilin sa mga tuntunin ng mga mapagkukunan.
Lahat ng gamit.
Kung sa tingin mo ay kawili-wili ang bloat na paksa sa mga tuntunin ng higit pang pag-alam sa loob, narito ang ilang mga kapaki-pakinabang na link:
- - Ito ay isang ulat mula sa aking kasamahan. Ito ay pangkalahatan tungkol sa kung saan napupunta ang espasyo ng Postgres sa panahon ng trabaho at buhay nito. At mayroong isang napakalaki at detalyadong teknikal na piraso para sa mga administrator ng database tungkol sa bloat.
- β ito ay isang link sa aming repository, kung saan kami ay nag-iimbak ng isang grupo ng mga kapaki-pakinabang na script para sa pagsuri sa estado ng database. Doon ka makakahanap ng mga script para maghanap ng bloat.
- ΠΈ mga link sa mga tool na makakatulong sa iyong pag-urong ng mga palatandaan.
- β ito ay isang post mula sa aking kasamahan. Doon ay seryoso at teknikal niyang sinusuri ang bloat nang detalyado sa antas na malapit sa mga administrator.
Mas sinubukan kong magpakita ng horror story para sa mga developer, dahil sila ang aming mga direktang kliyente ng mga database at dapat na maunawaan kung ano at kung ano ang mga aksyon na humahantong. Sana nagtagumpay ako. Salamat sa iyong atensyon!
mga katanungan
Salamat sa ulat! Napag-usapan mo kung paano mo matutukoy ang mga problema. Paano sila mabibigyang babala? Iyon ay, nagkaroon ako ng sitwasyon kung saan ang mga kahilingan ay nag-hang hindi lamang dahil na-access nila ang ilang mga panlabas na serbisyo. Ang mga ito ay ilang ligaw na pagsali lamang. Mayroong ilang maliliit at hindi nakakapinsalang mga kahilingan na umabot sa isang araw, at pagkatapos ay nagsimulang gumawa ng ilang kalokohan. Ibig sabihin, halos kapareho ng inilalarawan mo. Paano masubaybayan ito? Umupo at patuloy na panoorin kung aling kahilingan ang natigil? Paano ito mapipigilan?
Sa kasong ito, ito ay isang gawain para sa mga administrator ng iyong kumpanya, hindi kinakailangan para sa DBA.
Isa akong administrator.
Ang PostgreSQL ay may view na tinatawag na pg_stat_activity na nagpapakita ng mga nakalawit na query. At makikita mo kung gaano katagal ito nakabitin doon.
Kailangan ko bang pumasok at tumingin tuwing 5 minuto?
I-set up ang cron at suriin. Kung mayroon kang pangmatagalang kahilingan, magsulat ng liham at iyon na. Iyon ay, hindi mo kailangang tumingin gamit ang iyong mga mata, maaari itong awtomatiko. Makakatanggap ka ng sulat, magre-react ka dito. O maaari kang awtomatikong mag-shoot.
Mayroon bang anumang malinaw na dahilan kung bakit ito nangyayari?
Naglista ako ng ilan. Iba pang mas kumplikadong mga halimbawa. At maaaring magkaroon ng pag-uusap nang mahabang panahon.
Salamat sa ulat! Nais kong linawin ang tungkol sa pg_repack utility. Kung hindi siya gagawa ng eksklusibong lock, kung gayon...
Gumagawa siya ng eksklusibong lock.
... pagkatapos ay maaari akong mawalan ng data. Dapat bang walang naitala ang aking aplikasyon sa panahong ito?
Hindi, maayos itong gumagana sa talahanayan, ibig sabihin, inililipat muna ng pg_repack ang lahat ng live na linya na umiiral. Naturally, ang ilang uri ng pagpasok sa talahanayan ay nangyayari doon. Ibinabato lang niya itong nakapusod.
Ibig sabihin, gagawin niya talaga ito sa huli?
Sa huli, kukuha siya ng eksklusibong lock para palitan ang mga file na ito.
Mas mabilis ba ito kaysa sa VACUUM FULL?
VACUUM FULL, sa sandaling nagsimula ito, kinuha kaagad ang isang eksklusibong lock. At hangga't hindi niya ginagawa ang lahat, hindi niya ito bibitawan. At ang pg_repack ay kumukuha ng eksklusibong lock lamang sa oras ng pagpapalit ng file. Sa sandaling ito hindi ka magsusulat doon, ngunit ang data ay hindi mawawala, ang lahat ay magiging maayos.
Kamusta! Nagsalita ka tungkol sa pagpapatakbo ng vacuum ng kotse. Nagkaroon ng graph na may pula, dilaw at berdeng mga recording cell. Iyon ay, mga dilaw - minarkahan niya ang mga ito bilang tinanggal. At bilang resulta, may bagong maisusulat sa kanila?
Oo. Hindi tinatanggal ng mga postgres ang mga linya. Siya ay may ganoong katiyakan. Kung nag-update kami ng isang linya, minarkahan namin ang luma bilang tinanggal. Ang id ng transaksyon na nagbago sa linyang ito ay lilitaw doon, at nagsusulat kami ng bagong linya. At mayroon kaming mga session na posibleng basahin ang mga ito. Sa ilang mga punto sila ay nagiging medyo matanda. At ang kakanyahan ng kung paano gumagana ang autovacuum ay dumaan ito sa mga linyang ito at minarkahan ang mga ito bilang hindi kailangan. At maaari mong i-overwrite ang data doon.
Naiintindihan ko. Ngunit hindi iyon ang tungkol sa tanong. hindi ko natapos. Ipagpalagay natin na mayroon tayong mesa. Mayroon itong mga field na may variable na laki. At kung susubukan kong magpasok ng bago, maaaring hindi ito magkasya sa lumang cell.
Hindi, sa anumang kaso ang buong linya ay na-update doon. Ang mga postgres ay may dalawang modelo ng imbakan ng data. Pumipili ito mula sa uri ng data. Mayroong data na direktang naka-imbak sa talahanayan, at mayroon ding tos data. Ito ay malalaking halaga ng data: text, json. Ang mga ito ay nakaimbak sa magkahiwalay na mga plato. At ayon sa mga tabletang ito, ang parehong kuwento na may bloat ay nangyayari, i.e. lahat ay pareho. Nakalista lang sila nang hiwalay.
Salamat sa ulat! Katanggap-tanggap ba ang paggamit ng mga statement timeout query para limitahan ang tagal?
Very acceptable. Ginagamit namin ito kahit saan. At dahil wala kaming sariling mga serbisyo, nagbibigay kami ng malayuang suporta, mayroon kaming iba't ibang mga kliyente. At lahat ay ganap na nasiyahan dito. Ibig sabihin, mayroon kaming mga cron job na nagsusuri. Ang tagal ng mga sesyon ay napagkasunduan lamang sa kliyente, bago ito hindi kami sumasang-ayon. Maaaring isang minuto, maaaring 10 minuto. Depende ito sa pagkarga sa base at layunin nito. Ngunit lahat tayo ay gumagamit ng pg_stat_activity.
Salamat sa ulat! Sinusubukan kong ilapat ang iyong ulat sa aking mga aplikasyon. At tila nagsisimula kami ng isang transaksyon sa lahat ng dako, at malinaw na kumpletuhin ito kahit saan. Kung mayroong ilang pagbubukod, pagkatapos ay nangyayari pa rin ang rollback. At pagkatapos ay nagsimula akong mag-isip. Pagkatapos ng lahat, maaaring hindi tahasang magsimula ang transaksyon. Baka pahiwatig ito sa dalaga. Kung mag-a-update lang ako ng record, magsisimula ba ang transaksyon sa PostgreSQL at makukumpleto lang kapag nadiskonekta ang koneksyon?
Kung pinag-uusapan mo ngayon ang antas ng aplikasyon, depende ito sa driver na iyong ginagamit, sa ORM na ginagamit. Mayroong maraming mga setting doon. Kung pinagana mo ang auto commit on, magsisimula doon ang isang transaksyon at magsasara kaagad.
Ibig sabihin, nagsasara kaagad pagkatapos ng pag-update?
Depende ito sa mga setting. Pinangalanan ko ang isang setting. Ito ay naka-auto commit. Ito ay medyo karaniwan. Kung ito ay pinagana, ang transaksyon ay nagbukas at nagsara. Maliban kung tahasan mong sinabi ang "simulan ang transaksyon" at "tapos ang transaksyon", ngunit naglunsad lang ng kahilingan sa session.
Kamusta! Salamat sa ulat! Isipin natin na meron tayong database na bumubukol at bumubukol tapos maubusan ang space sa server. Mayroon bang anumang mga tool upang ayusin ang sitwasyong ito?
Ang espasyo sa server ay kailangang subaybayan ng maayos.
Halimbawa, nag-tea ang DBA, nasa resort, atbp.
Kapag ang isang file system ay nilikha, hindi bababa sa ilang uri ng backup na espasyo ay nilikha kung saan ang data ay hindi nakasulat.
Paano kung ito ay ganap na mas mababa sa zero?
Doon ito ay tinatawag na reserved space, ibig sabihin, maaari itong palayain at depende sa kung gaano kalaki ito nilikha, makakakuha ka ng libreng espasyo. Bilang default hindi ko alam kung ilan ang mayroon. At sa isa pang kaso, maghatid ng mga disk upang magkaroon ka ng puwang para magsagawa ng reconstructive na operasyon. Maaari mong tanggalin ang ilang talahanayan na garantisadong hindi mo kakailanganin.
Mayroon bang iba pang mga tool?
Ito ay palaging gawa sa kamay. At sa lokal ay nagiging malinaw kung ano ang pinakamahusay na gawin doon, dahil ang ilang data ay kritikal at ang ilan ay hindi kritikal. At para sa bawat database at ang application na gumagana kasama nito, depende ito sa negosyo. Palagi itong napagpasyahan nang lokal.
Salamat sa ulat! Mayroon akong dalawang tanong. Una, nagpakita ka ng mga slide na nagpapakita na kapag natigil ang mga transaksyon, parehong lumalaki ang laki ng tablespace at ang laki ng index. At higit pa sa ulat mayroong isang bungkos ng mga utility na nag-package sa tablet. Paano ang index?
Iniimpake din nila ang mga ito.
Ngunit ang vacuum ay hindi nakakaapekto sa index?
Ang ilan ay gumagana sa isang index. Halimbawa, pg_rapack, pgcompacttable. Nililikha ng vacuum ang mga index at naaapektuhan ang mga ito. Sa VACUUM FULL ang ideya ay i-overwrite ang lahat, ibig sabihin, gumagana ito sa lahat.
At ang pangalawang tanong. Hindi ko maintindihan kung bakit umaasa nang husto ang mga ulat sa mga replika sa mismong pagtitiklop. Tila sa akin na ang mga ulat ay binabasa, at ang pagtitiklop ay isinusulat.
Ano ang nagiging sanhi ng salungatan sa pagtitiklop? Mayroon kaming Master kung saan nagaganap ang mga proseso. Mayroon kaming vacuum ng kotse na nangyayari. Ano ba talaga ang ginagawa ng autovacuum? Nagpuputol siya ng ilang lumang linya. Kung sa ngayon ay mayroon kaming kahilingan sa replica na nagbabasa ng mga lumang linyang ito, at sa Master may naganap na sitwasyon na minarkahan ng autovacuum ang mga linyang ito bilang posible para sa pag-overwrit, pagkatapos ay pinatungan namin ang mga ito. At nakatanggap kami ng data packet, kapag kailangan naming muling isulat ang mga linyang iyon na kailangan ng kahilingan sa replica, maghihintay ang proseso ng pagtitiklop para sa timeout na iyong na-configure. At pagkatapos ay magpapasya ang PostgreSQL kung ano ang mas mahalaga dito. At mas mahalaga sa kanya ang pagtitiklop kaysa sa kahilingan, at kukunan niya ang kahilingan para magawa ang mga pagbabagong ito sa replika.
Andrey, may tanong ako. Ang mga kahanga-hangang graph na ito na ipinakita mo sa presentasyon, ito ba ay resulta ng gawain ng ilang uri ng utility mo? Paano ginawa ang mga graph?
Ito ay isang serbisyo .
Ito ba ay isang komersyal na produkto?
Oo. Ito ay isang komersyal na produkto.
Pinagmulan: www.habr.com