ઓડિસી રોડમેપ: કનેક્શન પૂલરથી આપણને બીજું શું જોઈએ છે. આન્દ્રે બોરોડિન (2019)

તેમના અહેવાલમાં, આન્દ્રે બોરોડિન તમને જણાવશે કે કનેક્શન પૂલર ડિઝાઇન કરતી વખતે તેઓએ PgBouncer સ્કેલિંગના અનુભવને કેવી રીતે ધ્યાનમાં લીધું ઓડીસી, કારણ કે તેઓએ તેને ઉત્પાદનમાં ફેરવ્યું. આ ઉપરાંત, અમે નવા સંસ્કરણોમાં પુલરના કયા કાર્યો જોવા માંગીએ છીએ તેની ચર્ચા કરીશું: અમારા માટે ફક્ત અમારી જરૂરિયાતો પૂરી કરવી જ નહીં, પરંતુ વપરાશકર્તા સમુદાયનો વિકાસ કરવો મહત્વપૂર્ણ છે. ઓડીસી.

વિડિઓ:

કેમ છો બધા! મારું નામ એન્ડ્રુ છે.

યાન્ડેક્ષ પર, હું ઓપન સોર્સ ડેટાબેસેસ વિકસાવું છું. અને આજે આપણી પાસે કનેક્શન પુલર કનેક્શન્સ વિશેનો વિષય છે.

જો તમે રશિયનમાં કનેક્શન પૂલરને કેવી રીતે કૉલ કરવું તે જાણો છો, તો મને કહો. હું ખરેખર એક સારો તકનીકી શબ્દ શોધવા માંગુ છું જે તકનીકી સાહિત્યમાં સ્થાપિત થવો જોઈએ.

વિષય એકદમ જટિલ છે, કારણ કે ઘણા ડેટાબેઝમાં કનેક્શન પૂલર બિલ્ટ-ઇન છે અને તમારે તેના વિશે જાણવાની જરૂર પણ નથી. અલબત્ત, દરેક જગ્યાએ કેટલીક સેટિંગ્સ છે, પરંતુ પોસ્ટગ્રેસમાં તે તે રીતે કામ કરતું નથી. અને સમાંતરમાં (HighLoad++ 2019 પર) Postgres માં ક્વેરી સેટ કરવા વિશે નિકોલાઈ સમોખવાલોવ દ્વારા અહેવાલ છે. અને જેમ હું તેને સમજું છું, એવા લોકો અહીં આવ્યા જેમણે પહેલેથી જ તેમના પ્રશ્નોને સંપૂર્ણ રીતે ગોઠવી દીધા હતા, અને આ એવા લોકો છે કે જેઓ નેટવર્ક અને સંસાધનોના ઉપયોગને લગતી વધુ દુર્લભ સિસ્ટમ સમસ્યાઓનો સામનો કરી રહ્યા છે. અને કેટલાક સ્થળોએ તે અર્થમાં ખૂબ મુશ્કેલ હોઈ શકે છે કે સમસ્યાઓ સ્પષ્ટ નથી.

યાન્ડેક્સમાં પોસ્ટગ્રેસ છે. Yandex.Cloud માં ઘણી Yandex સેવાઓ રહે છે. અને અમારી પાસે ઘણા પેટાબાઇટ્સ ડેટા છે જે પોસ્ટગ્રેસમાં પ્રતિ સેકન્ડ ઓછામાં ઓછા એક મિલિયન વિનંતીઓ જનરેટ કરે છે.

અને અમે બધી સેવાઓ માટે એકદમ પ્રમાણભૂત ક્લસ્ટર પ્રદાન કરીએ છીએ - આ નોડનો મુખ્ય પ્રાથમિક નોડ છે, સામાન્ય બે પ્રતિકૃતિઓ (સિંક્રનસ અને અસિંક્રોનસ), બેકઅપ, પ્રતિકૃતિ પર વાંચવાની વિનંતીઓનું સ્કેલિંગ.

દરેક ક્લસ્ટર નોડ પોસ્ટગ્રેસ છે, જેના પર, પોસ્ટગ્રેસ અને મોનિટરિંગ સિસ્ટમ્સ ઉપરાંત, કનેક્શન પૂલર પણ ઇન્સ્ટોલ કરેલું છે. કનેક્શન પૂલરનો ઉપયોગ ફેન્સીંગ માટે અને તેના મુખ્ય હેતુ માટે થાય છે.

કનેક્શન પૂલરનો મુખ્ય હેતુ શું છે?

ડેટાબેઝ સાથે કામ કરતી વખતે પોસ્ટગ્રેસ પ્રોસેસ મોડલ અપનાવે છે. આનો અર્થ એ છે કે એક કનેક્શન એ એક પ્રક્રિયા છે, એક પોસ્ટગ્રેસ બેકએન્ડ. અને આ બેકએન્ડમાં ઘણાં બધાં અલગ-અલગ કૅશ છે, જે વિવિધ કનેક્શન્સ માટે અલગ-અલગ બનાવવા માટે ખૂબ ખર્ચાળ છે.

વધુમાં, પોસ્ટગ્રેસ કોડમાં પ્રોકએરે નામની એરે છે. તે નેટવર્ક કનેક્શન વિશે મૂળભૂત ડેટા ધરાવે છે. અને લગભગ તમામ procArray પ્રોસેસિંગ એલ્ગોરિધમ્સ રેખીય જટિલતા ધરાવે છે; તેઓ નેટવર્ક કનેક્શન્સના સમગ્ર એરે પર ચાલે છે. તે ખૂબ જ ઝડપી ચક્ર છે, પરંતુ વધુ આવતા નેટવર્ક કનેક્શન સાથે વસ્તુઓ થોડી વધુ મોંઘી થાય છે. અને જ્યારે વસ્તુઓ થોડી વધુ મોંઘી થાય છે, ત્યારે તમે ઘણા બધા નેટવર્ક કનેક્શન્સ માટે ખૂબ ઊંચી કિંમત ચૂકવી શકો છો.

ત્યાં 3 સંભવિત અભિગમો છે:

• અરજી બાજુ પર.
• ડેટાબેઝ બાજુ પર.
• અને વચ્ચે, એટલે કે, તમામ પ્રકારના સંયોજનો.

કમનસીબે, બિલ્ટ-ઇન પૂલર હાલમાં વિકાસ હેઠળ છે. PostgreSQL Professional ખાતેના અમારા મિત્રો મોટે ભાગે આ કરે છે. તે ક્યારે દેખાશે તેની આગાહી કરવી મુશ્કેલ છે. અને વાસ્તવમાં, આર્કિટેક્ટને પસંદ કરવા માટે અમારી પાસે બે ઉકેલો છે. આ એપ્લિકેશન-સાઇડ પૂલ અને પ્રોક્સી પૂલ છે.

એપ્લિકેશન-સાઇડ પૂલ એ સૌથી સહેલો રસ્તો છે. અને લગભગ તમામ ક્લાયંટ ડ્રાઇવરો તમને એક માર્ગ પ્રદાન કરે છે: તમારા લાખો કનેક્શન્સને કોડમાં ડેટાબેઝમાં કેટલાક ડઝન કનેક્શન તરીકે રજૂ કરે છે.

સમસ્યા જે ઊભી થાય છે તે એ છે કે ચોક્કસ બિંદુએ તમે બેકએન્ડને માપવા માંગો છો, તમે તેને ઘણા વર્ચ્યુઅલ મશીનો પર જમાવવા માંગો છો.

પછી તમે સમજો છો કે તમારી પાસે ઘણા વધુ ઉપલબ્ધતા ઝોન છે, ઘણા ડેટા સેન્ટર છે. અને ક્લાયંટ સાઇડ પૂલિંગ અભિગમ મોટી સંખ્યામાં તરફ દોરી જાય છે. મોટામાં લગભગ 10 કનેક્શન છે. આ એ ધાર છે જે સામાન્ય રીતે કામ કરી શકે છે.

જો આપણે પ્રોક્સી પૂલર્સ વિશે વાત કરીએ, તો ત્યાં બે પૂલર્સ છે જે ઘણું બધું કરી શકે છે. તેઓ માત્ર પૂલર નથી. તેઓ પૂલર + વધુ ઠંડી કાર્યક્ષમતા છે. આ પીજીપૂલ и ક્રન્ચી-પ્રોક્સી.

પરંતુ, કમનસીબે, દરેકને આ વધારાની કાર્યક્ષમતાની જરૂર નથી. અને તે એ હકીકત તરફ દોરી જાય છે કે પૂલર્સ ફક્ત સત્ર પૂલિંગને સમર્થન આપે છે, એટલે કે એક ઇનકમિંગ ક્લાયન્ટ, એક આઉટગોઇંગ ક્લાયંટ ડેટાબેઝમાં.

આ અમારા હેતુઓ માટે ખૂબ જ યોગ્ય નથી, તેથી અમે PgBouncer નો ઉપયોગ કરીએ છીએ, જે ટ્રાન્ઝેક્શન પૂલિંગનો અમલ કરે છે, એટલે કે સર્વર કનેક્શન્સ ક્લાયન્ટ કનેક્શન્સ સાથે માત્ર વ્યવહારના સમયગાળા માટે મેળ ખાય છે.

અને અમારા વર્કલોડમાં, આ સાચું છે. પરંતુ થોડી સમસ્યાઓ છે.

જ્યારે તમે સત્રનું નિદાન કરવા માંગતા હો ત્યારે સમસ્યાઓ શરૂ થાય છે, કારણ કે તમારા બધા આવનારા જોડાણો સ્થાનિક છે. દરેક વ્યક્તિ લૂપબેક સાથે આવ્યા હતા અને કોઈક રીતે સત્રને ટ્રેસ કરવું મુશ્કેલ બની જાય છે.

અલબત્ત તમે application_name_add_host નો ઉપયોગ કરી શકો છો. એપ્લિકેશન_નામમાં IP સરનામું ઉમેરવા માટે બાઉન્સર બાજુ પરનો આ એક માર્ગ છે. પરંતુ એપ્લિકેશન_નામ વધારાના કનેક્શન દ્વારા સેટ કરેલ છે.

આ ગ્રાફ પર, જ્યાં પીળી લાઇન વાસ્તવિક વિનંતીઓ છે અને જ્યાં વાદળી રેખા ડેટાબેઝમાં ઉડતી વિનંતીઓ છે. અને આ તફાવત ચોક્કસપણે એપ્લીકેશન_નામનું ઇન્સ્ટોલેશન છે, જે ફક્ત ટ્રેસિંગ માટે જરૂરી છે, પરંતુ તે બિલકુલ મફત નથી.

વધુમાં, બાઉન્સરમાં તમે એક પૂલને મર્યાદિત કરી શકતા નથી, એટલે કે ચોક્કસ ડેટાબેઝ દીઠ ચોક્કસ વપરાશકર્તા દીઠ ડેટાબેઝ કનેક્શન્સની સંખ્યા.

આ શું તરફ દોરી જાય છે? તમારી પાસે C++ માં લખેલી એક લોડ કરેલી સેવા છે અને ક્યાંક નજીકમાં નોડ પર એક નાની સેવા છે જે ડેટાબેઝ સાથે કંઈપણ ભયંકર કરતી નથી, પરંતુ તેનો ડ્રાઇવર પાગલ થઈ જાય છે. તે 20 કનેક્શન ખોલે છે અને બાકીનું બધું રાહ જોશે. તમારો કોડ પણ સામાન્ય છે.

અમે, અલબત્ત, બાઉન્સર માટે એક નાનો પેચ લખ્યો છે જેણે આ સેટિંગ ઉમેર્યું છે, એટલે કે ક્લાયન્ટ્સને પૂલ સુધી મર્યાદિત કરવા.

પોસ્ટગ્રેસ બાજુ પર આ કરવાનું શક્ય બનશે, એટલે કે, ડેટાબેઝમાંની ભૂમિકાઓને જોડાણોની સંખ્યા દ્વારા મર્યાદિત કરો.

પરંતુ પછી તમે એ સમજવાની ક્ષમતા ગુમાવો છો કે શા માટે તમારી પાસે સર્વર સાથે કોઈ જોડાણ નથી. PgBouncer કનેક્શન ભૂલ ફેંકતું નથી, તે હંમેશા સમાન માહિતી પરત કરે છે. અને તમે સમજી શકતા નથી: કદાચ તમારો પાસવર્ડ બદલાઈ ગયો છે, કદાચ ડેટાબેઝ હમણાં જ ખોવાઈ ગયો છે, કદાચ કંઈક ખોટું છે. પરંતુ ત્યાં કોઈ નિદાન નથી. જો સત્ર સ્થાપિત કરી શકાતું નથી, તો તમે જાણશો નહીં કે તે શા માટે સ્થાપિત થઈ શકતું નથી.

ચોક્કસ બિંદુએ, તમે એપ્લિકેશન ગ્રાફ્સ જુઓ અને જુઓ કે એપ્લિકેશન કામ કરી રહી નથી.

ટોચ પર જુઓ અને જુઓ કે બાઉન્સર સિંગલ-થ્રેડેડ છે. સેવાના જીવનમાં આ એક વળાંક છે. તમે સમજો છો કે તમે દોઢ વર્ષમાં ડેટાબેઝને સ્કેલ કરવાની તૈયારી કરી રહ્યા હતા, અને તમારે પૂલરને સ્કેલ કરવાની જરૂર છે.

અમે એવા નિષ્કર્ષ પર આવ્યા છીએ કે અમને વધુ PgBouncersની જરૂર છે.

https://lwn.net/Articles/542629/

બાઉન્સરને થોડો પેચ કરવામાં આવ્યો છે.

અને તેઓએ તેને બનાવ્યું જેથી કરીને TCP પોર્ટનો પુનઃઉપયોગ કરીને ઘણા બાઉન્સર્સ ઉભા કરી શકાય. અને ઓપરેટિંગ સિસ્ટમ રાઉન્ડ-રોબિનનો ઉપયોગ કરીને તેમની વચ્ચે આવનારા TCP કનેક્શનને આપમેળે સ્થાનાંતરિત કરે છે.

આ ક્લાયંટ માટે પારદર્શક છે, એટલે કે એવું લાગે છે કે તમારી પાસે એક બાઉન્સર છે, પરંતુ તમારી પાસે ચાલતા બાઉન્સર્સ વચ્ચે નિષ્ક્રિય કનેક્શન્સનું વિભાજન છે.

અને ચોક્કસ ક્ષણે તમે જોશો કે આ 3 બાઉન્સર દરેક તેમના કોરને 100% ખાઈ જાય છે. તમારે થોડા બાઉન્સરની જરૂર છે. શા માટે?

કારણ કે તમારી પાસે TLS છે. તમારી પાસે એન્ક્રિપ્ટેડ કનેક્શન છે. અને જો તમે TLS સાથે અને તેના વગર પોસ્ટગ્રેસને બેન્ચમાર્ક કરો છો, તો તમે જોશો કે સ્થાપિત જોડાણોની સંખ્યા એન્ક્રિપ્શન સક્ષમ સાથે લગભગ બે ઓર્ડરની તીવ્રતાથી ઘટી જાય છે, કારણ કે TLS હેન્ડશેક CPU સંસાધનોનો ઉપયોગ કરે છે.

અને ટોચ પર તમે થોડાક ક્રિપ્ટોગ્રાફિક ફંક્શન્સ જોઈ શકો છો જે જ્યારે ઇનકમિંગ કનેક્શન્સની તરંગ હોય ત્યારે ચલાવવામાં આવે છે. અમારું પ્રાથમિક પ્રાપ્યતા ક્ષેત્રો વચ્ચે સ્વિચ કરી શકે છે, તેથી આવનારા જોડાણોની લહેર એ એકદમ લાક્ષણિક પરિસ્થિતિ છે. એટલે કે, કેટલાક કારણોસર જૂની પ્રાથમિક અનુપલબ્ધ હતી, સમગ્ર લોડ અન્ય ડેટા સેન્ટરમાં મોકલવામાં આવ્યો હતો. તેઓ બધા એક જ સમયે TLS ને હેલો કહેવા આવશે.

અને મોટી સંખ્યામાં TLS હેન્ડશેક હવે બાઉન્સરને હેલો નહીં કહે, પરંતુ તેનું ગળું દબાવશે. સમયસમાપ્તિને લીધે, ઇનકમિંગ કનેક્શન્સની લહેર અનડેમ્પ થઈ શકે છે. જો તમે ઘાતાંકીય બેકઓફ વિના આધાર પર ફરીથી પ્રયાસ કરો છો, તો તેઓ સુસંગત તરંગમાં વારંવાર આવશે નહીં.

અહીં 16 PgBouncersનું ઉદાહરણ છે જે 16% પર 100 કોરો લોડ કરે છે.

અમે કાસ્કેડ PgBouncer પર આવ્યા. આ શ્રેષ્ઠ રૂપરેખાંકન છે જે બાઉન્સર સાથે અમારા લોડ પર પ્રાપ્ત કરી શકાય છે. અમારા બાહ્ય બાઉન્સર્સનો ઉપયોગ TCP હેન્ડશેક માટે થાય છે, અને આંતરિક બાઉન્સર્સનો ઉપયોગ વાસ્તવિક પૂલિંગ માટે થાય છે, જેથી બાહ્ય કનેક્શનને વધુ ખંડિત ન થાય.

આ રૂપરેખાંકનમાં, સરળ પુનઃપ્રારંભ શક્ય છે. તમે આ બધા 18 બાઉન્સર્સને એક પછી એક ફરી શરૂ કરી શકો છો. પરંતુ આવા રૂપરેખાંકન જાળવવા તદ્દન મુશ્કેલ છે. Sysadmins, DevOps, અને જે લોકો ખરેખર આ સર્વર માટે જવાબદાર છે તેઓ આ વ્યવસ્થાથી બહુ ખુશ નહીં હોય.

એવું લાગે છે કે અમારા તમામ સુધારાઓને ઓપન સોર્સમાં પ્રમોટ કરી શકાય છે, પરંતુ બાઉન્સર ખૂબ સારી રીતે સમર્થિત નથી. ઉદાહરણ તરીકે, એક પોર્ટ પર અનેક PgBouncers ચલાવવાની ક્ષમતા એક મહિના પહેલા પ્રતિબદ્ધ કરવામાં આવી હતી. ઘણા વર્ષો પહેલા આ સુવિધા સાથે પુલ વિનંતી કરવામાં આવી હતી.

https://www.postgresql.org/docs/current/libpq-cancel.html

https://github.com/pgbouncer/pgbouncer/pull/79

અથવા એક વધુ ઉદાહરણ. Postgres માં, તમે બિનજરૂરી પ્રમાણીકરણ વિના અલગ કનેક્શન પર ગુપ્ત મોકલીને પ્રગતિમાં વિનંતીને રદ કરી શકો છો. પરંતુ કેટલાક ક્લાયંટ ફક્ત TCP રીસેટ મોકલે છે, એટલે કે તેઓ નેટવર્ક કનેક્શન તોડી નાખે છે. બાઉન્સર શું કરશે? તે કંઈ કરશે નહીં. તે વિનંતીનો અમલ કરવાનું ચાલુ રાખશે. જો તમને મોટી સંખ્યામાં કનેક્શન્સ પ્રાપ્ત થયા છે જેણે નાની વિનંતીઓ સાથે ડેટાબેઝ બનાવ્યો છે, તો પછી ફક્ત બાઉન્સરથી કનેક્શનને ડિસ્કનેક્ટ કરવું પૂરતું નથી; તમારે તે વિનંતીઓ પણ પૂર્ણ કરવાની જરૂર છે જે ડેટાબેઝમાં ચાલી રહી છે.

આને પેચ કરવામાં આવ્યું છે અને આ સમસ્યા હજુ સુધી બાઉન્સરના અપસ્ટ્રીમમાં મર્જ કરવામાં આવી નથી.

અને તેથી અમે નિષ્કર્ષ પર આવ્યા કે અમને અમારા પોતાના કનેક્શન પૂલરની જરૂર છે, જે વિકસાવવામાં આવશે, પેચ કરવામાં આવશે, જેમાં સમસ્યાઓ ઝડપથી સુધારી શકાય છે અને જે, અલબત્ત, મલ્ટિ-થ્રેડેડ હોવી જોઈએ.

અમે મલ્ટિથ્રેડિંગને મુખ્ય કાર્ય તરીકે સેટ કરીએ છીએ. આપણે આવનારા TLS કનેક્શન્સના મોજાને સારી રીતે હેન્ડલ કરવામાં સક્ષમ બનવાની જરૂર છે.

આ કરવા માટે, અમારે મશીનરીયમ નામની એક અલગ લાઇબ્રેરી વિકસાવવાની હતી, જે નેટવર્ક કનેક્શનની મશીન સ્ટેટ્સને ક્રમિક કોડ તરીકે વર્ણવવા માટે ડિઝાઇન કરવામાં આવી છે. જો તમે libpq સોર્સ કોડ જોશો, તો તમને કેટલાક ખૂબ જટિલ કૉલ્સ દેખાશે જે તમને પરિણામ આપી શકે છે અને કહે છે, “મને પછીથી કૉલ કરો. અત્યારે મારી પાસે હમણાં માટે IO છે, પરંતુ જ્યારે IO દૂર થઈ જશે ત્યારે મારી પાસે પ્રોસેસર પર ભાર હશે. અને આ બહુ-સ્તરીય યોજના છે. નેટવર્ક સંચાર સામાન્ય રીતે રાજ્ય મશીન દ્વારા વર્ણવવામાં આવે છે. ઘણા બધા નિયમો જેમ કે "જો મને અગાઉ N કદનું પેકેટ હેડર મળ્યું હોય, તો હવે હું N બાઈટ્સની રાહ જોઈ રહ્યો છું," "જો મેં SYNC પેકેટ મોકલ્યું હોય, તો હવે હું પરિણામ મેટાડેટાવાળા પેકેટની રાહ જોઈ રહ્યો છું." પરિણામ એ એક જગ્યાએ મુશ્કેલ, કાઉન્ટર ઇન્ટ્યુટિવ કોડ છે, જાણે કે મેઝને લાઇન સ્કેનમાં રૂપાંતરિત કરવામાં આવી હોય. અમે તેને બનાવ્યું છે જેથી રાજ્ય મશીનને બદલે, પ્રોગ્રામર સામાન્ય આવશ્યક કોડના સ્વરૂપમાં ક્રિયાપ્રતિક્રિયાના મુખ્ય માર્ગનું વર્ણન કરે. તે માત્ર એટલું જ છે કે આ હિતાવહ કોડમાં તમારે એવા સ્થાનો દાખલ કરવાની જરૂર છે જ્યાં નેટવર્કમાંથી ડેટાની રાહ જોઈને, અમલના સંદર્ભને અન્ય કોરોટીન (ગ્રીન થ્રેડ) પર પસાર કરીને એક્ઝેક્યુશન સિક્વન્સને વિક્ષેપિત કરવાની જરૂર છે. આ અભિગમ એ હકીકત જેવો જ છે કે આપણે સળંગ માર્ગમાં સૌથી અપેક્ષિત પાથ લખીએ છીએ અને પછી તેમાં શાખાઓ ઉમેરીએ છીએ.

પરિણામે, અમારી પાસે એક થ્રેડ છે જે TCP સ્વીકારે છે અને રાઉન્ડ-રોબિન ઘણા કામદારોને TPC કનેક્શન પાસ કરે છે.

આ કિસ્સામાં, દરેક ક્લાયંટ કનેક્શન હંમેશા એક પ્રોસેસર પર ચાલે છે. અને આ તમને તેને કેશ-ફ્રેંડલી બનાવવા માટે પરવાનગી આપે છે.

અને વધુમાં, અમે સિસ્ટમ TCP સ્ટેકને રાહત આપવા માટે એક મોટા પેકેટમાં નાના પેકેટોના સંગ્રહમાં થોડો સુધારો કર્યો છે.

વધુમાં, અમે ટ્રાન્ઝેક્શનલ પૂલિંગને એ અર્થમાં સુધાર્યું છે કે જ્યારે ઓડિસી, જ્યારે ગોઠવેલું હોય, ત્યારે નેટવર્ક કનેક્શન નિષ્ફળતાના કિસ્સામાં કેન્સલ અને રોલબેક મોકલી શકે છે, એટલે કે જો કોઈ વિનંતીની રાહ જોતું નથી, તો ઓડિસી ડેટાબેઝને કહેશે કે તેનો પ્રયાસ ન કરો. વિનંતીને પૂર્ણ કરો જે કિંમતી સંસાધનોનો બગાડ કરી શકે છે.

અને જ્યારે પણ શક્ય હોય ત્યારે, અમે એક જ ક્લાયન્ટ સાથે જોડાણો રાખીએ છીએ. આ application_name_add_host પુનઃસ્થાપિત કરવાનું ટાળે છે. જો આ શક્ય હોય, તો અમારે ડાયગ્નોસ્ટિક્સ માટે જરૂરી પરિમાણોને ફરીથી સેટ કરવાની જરૂર નથી.

અમે Yandex.Cloud ના હિતમાં કામ કરીએ છીએ. અને જો તમે મેનેજ્ડ PostgreSQL નો ઉપયોગ કરો છો અને તમારી પાસે કનેક્શન પૂલર ઇન્સ્ટોલ કરેલ છે, તો તમે લોજિકલ પ્રતિકૃતિનો ઉપયોગ કરીને બહારની તરફ લોજિકલ પ્રતિકૃતિ બનાવી શકો છો, એટલે કે, જો તમે ઇચ્છો તો, અમને છોડી દો. બાઉન્સર તાર્કિક પ્રતિકૃતિ પ્રવાહને બહાર છોડશે નહીં.

આ લોજિકલ પ્રતિકૃતિ સેટ કરવાનું ઉદાહરણ છે.

વધુમાં, અમારી પાસે બાહ્ય પ્રતિકૃતિ માટે સમર્થન છે. ક્લાઉડમાં, અલબત્ત, આ અશક્ય છે, કારણ કે પછી ક્લસ્ટર તમને પોતાના વિશે ઘણી બધી માહિતી આપશે. પરંતુ તમારા ઇન્સ્ટોલેશનમાં, જો તમને ઓડિસીમાં કનેક્શન પૂલર દ્વારા ભૌતિક પ્રતિકૃતિની જરૂર હોય, તો આ શક્ય છે.

Odyssey PgBouncer સાથે સંપૂર્ણપણે સુસંગત મોનિટરિંગ ધરાવે છે. અમારી પાસે સમાન કન્સોલ છે જે લગભગ તમામ સમાન આદેશો ચલાવે છે. જો કંઈક ખૂટે છે, તો પુલ વિનંતી મોકલો, અથવા ઓછામાં ઓછું GitHub પર કોઈ સમસ્યા, અને અમે જરૂરી આદેશો પૂર્ણ કરીશું. પરંતુ અમારી પાસે પહેલાથી જ PgBouncer કન્સોલની મુખ્ય કાર્યક્ષમતા છે.

અને, અલબત્ત, અમારી પાસે ભૂલ ફોરવર્ડિંગ છે. અમે ડેટાબેઝ દ્વારા નોંધાયેલ ભૂલ પરત કરીશું. તમે ડેટાબેઝમાં શા માટે સમાવિષ્ટ નથી તે વિશે તમને માહિતી પ્રાપ્ત થશે, અને એટલું જ નહીં કે તમે તેમાં શામેલ નથી.

જો તમને PgBouncer સાથે 100% સુસંગતતાની જરૂર હોય તો આ સુવિધા અક્ષમ છે. અમે બાઉન્સરની જેમ જ વર્તન કરી શકીએ છીએ, ફક્ત સલામત બાજુએ રહેવા માટે.

વિકાસ

ઓડિસી સ્ત્રોત કોડ વિશે થોડાક શબ્દો.

https://github.com/yandex/odyssey/pull/66

ઉદાહરણ તરીકે, "થોભો / ફરી શરૂ કરો" આદેશો છે. તેઓ સામાન્ય રીતે ડેટાબેઝ અપડેટ કરવા માટે વપરાય છે. જો તમારે પોસ્ટગ્રેસને અપડેટ કરવાની જરૂર હોય, તો પછી તમે તેને કનેક્શન પૂલરમાં થોભાવી શકો છો, pg_upgrade કરી શકો છો, પછી ફરી શરૂ કરી શકો છો. અને ક્લાયંટની બાજુથી એવું દેખાશે કે જાણે ડેટાબેઝ ખાલી ધીમું થઈ રહ્યું હતું. આ કાર્યક્ષમતા સમુદાયના લોકો દ્વારા અમારી પાસે લાવવામાં આવી હતી. તેણી હજી સ્થિર નથી, પરંતુ ટૂંક સમયમાં બધું થઈ જશે. (પહેલેથી જ સ્થિર)

https://github.com/yandex/odyssey/pull/73 - પહેલેથી જ સ્થિર

વધુમાં, PgBouncer માંની એક નવી વિશેષતા એ SCRAM પ્રમાણીકરણ માટે સપોર્ટ છે, જે Yandex.Cloud માં કામ ન કરતી વ્યક્તિ દ્વારા પણ અમને લાવવામાં આવી હતી. બંને જટિલ કાર્યક્ષમતા અને મહત્વપૂર્ણ છે.

તેથી, હું તમને જણાવવા માંગુ છું કે ઓડીસી શેની બનેલી છે, જો તમે પણ હવે થોડો કોડ લખવા માંગતા હોવ.

તમારી પાસે ઓડિસી સ્ત્રોત આધાર છે, જે બે મુખ્ય પુસ્તકાલયો પર આધાર રાખે છે. કિવિ લાઇબ્રેરી એ પોસ્ટગ્રેસ મેસેજ પ્રોટોકોલનું અમલીકરણ છે. એટલે કે, પોસ્ટગ્રેસનો મૂળ પ્રોટો 3 એ પ્રમાણભૂત સંદેશાઓ છે જે આગળના છેડા અને પાછળના છેડાઓ વિનિમય કરી શકે છે. તેઓ કિવિ લાઇબ્રેરીમાં અમલમાં છે.

મશીનરીયમ લાઇબ્રેરી એ થ્રેડ અમલીકરણ પુસ્તકાલય છે. આ મશીનરીયમનો એક નાનો ટુકડો એસેમ્બલી ભાષામાં લખાયેલો છે. પરંતુ ગભરાશો નહીં, ત્યાં ફક્ત 15 રેખાઓ છે.

ઓડીસી આર્કિટેક્ચર. એક મુખ્ય મશીન છે જેના પર કોરોટીન્સ ચાલી રહી છે. આ મશીન ઇનકમિંગ TCP કનેક્શન્સ સ્વીકારવાનું અને કામદારોમાં વહેંચવાનું અમલીકરણ કરે છે.

ઘણા ગ્રાહકો માટે હેન્ડલર એક કાર્યકરની અંદર કામ કરી શકે છે. મુખ્ય થ્રેડ કન્સોલને પણ ચલાવે છે અને પુલમાં હવે જરૂરી ન હોય તેવા જોડાણોને કાઢી નાખવા માટે ક્રોન કાર્યોની પ્રક્રિયા કરે છે.

પ્રમાણભૂત પોસ્ટગ્રેસ ટેસ્ટ સ્યુટનો ઉપયોગ કરીને ઓડિસીનું પરીક્ષણ કરવામાં આવે છે. અમે ફક્ત બાઉન્સર દ્વારા અને ઓડિસી દ્વારા ઇન્સ્ટોલ-ચેક ચલાવીએ છીએ, અમને નલ ડિવ મળે છે. તારીખ ફોર્મેટિંગને લગતી ઘણી કસોટીઓ છે જે બાઉન્સર અને ઓડિસીમાં બરાબર પાસ થતી નથી.

વધુમાં, એવા ઘણા ડ્રાઇવરો છે કે જેઓનું પોતાનું પરીક્ષણ છે. અને અમે ઓડીસી ચકાસવા માટે તેમના પરીક્ષણોનો ઉપયોગ કરીએ છીએ.

આ ઉપરાંત, અમારા કાસ્કેડ ગોઠવણીને લીધે, અમારે વિવિધ બંડલ્સનું પરીક્ષણ કરવું પડશે: પોસ્ટગ્રેસ + ઓડીસી, પીજીબાઉન્સર + ઓડીસી, ઓડીસી + ઓડીસી એ ખાતરી કરવા માટે કે જો ઓડીસી કાસ્કેડના કોઈપણ ભાગોમાં સમાપ્ત થાય છે, તો તે હજી પણ કાર્ય કરે છે. જેમ આપણે અપેક્ષા રાખીએ છીએ.

રેક

અમે ઉત્પાદનમાં ઓડિસીનો ઉપયોગ કરીએ છીએ. અને તે વાજબી રહેશે નહીં જો હું કહું કે બધું જ કામ કરે છે. ના, એટલે કે, હા, પરંતુ હંમેશા નહીં. ઉદાહરણ તરીકે, ઉત્પાદનમાં બધું જ કામ કર્યું, પછી પોસ્ટગ્રેએસક્યુએલ પ્રોફેશનલના અમારા મિત્રો આવ્યા અને કહ્યું કે અમારી પાસે મેમરી લીક છે. તેઓ ખરેખર હતા, અમે તેમને સુધાર્યા. પરંતુ તે સરળ હતું.

પછી અમે શોધ્યું કે કનેક્શન પૂલરમાં ઇનકમિંગ TLS કનેક્શન અને આઉટગોઇંગ TLS કનેક્શન છે. અને જોડાણોને ક્લાયંટ પ્રમાણપત્રો અને સર્વર પ્રમાણપત્રોની જરૂર છે.

બાઉન્સર અને ઓડિસી સર્વર પ્રમાણપત્રો તેમના pcache દ્વારા ફરીથી વાંચવામાં આવે છે, પરંતુ ક્લાયંટ પ્રમાણપત્રોને pcacheમાંથી ફરીથી વાંચવાની જરૂર નથી, કારણ કે અમારી સ્કેલેબલ ઓડિસી આખરે આ પ્રમાણપત્ર વાંચવાના સિસ્ટમ પ્રદર્શનમાં ચાલે છે. આ અમારા માટે આશ્ચર્યજનક હતું, કારણ કે તેને પ્રતિકાર કરવામાં લાંબો સમય લાગ્યો ન હતો. શરૂઆતમાં તે રેખીય રીતે માપવામાં આવ્યું હતું, પરંતુ 20 ઇનકમિંગ એક સાથે જોડાણો પછી આ સમસ્યા પોતાને બતાવી હતી.

પ્લગેબલ ઓથેન્ટિકેશન મેથડ એ બિલ્ટ-ઇન લુનક્સ ટૂલ્સનો ઉપયોગ કરીને પ્રમાણીકરણ કરવાની ક્ષમતા છે. PgBouncer માં તે એવી રીતે લાગુ કરવામાં આવે છે કે PAM તરફથી પ્રતિસાદની રાહ જોવા માટે એક અલગ થ્રેડ છે અને ત્યાં એક મુખ્ય PgBouncer થ્રેડ છે જે વર્તમાન કનેક્શનને સેવા આપે છે અને તેમને PAM થ્રેડમાં રહેવા માટે કહી શકે છે.

અમે એક સરળ કારણસર આનો અમલ કર્યો નથી. અમારી પાસે ઘણા બધા થ્રેડો છે. આપણને આની શા માટે જરૂર છે?

આ આખરે સમસ્યા ઊભી કરી શકે છે કે જો તમારી પાસે PAM પ્રમાણીકરણ અને બિન-PAM પ્રમાણીકરણ હોય, તો PAM પ્રમાણીકરણની મોટી તરંગ બિન-PAM પ્રમાણીકરણમાં નોંધપાત્ર રીતે વિલંબ કરી શકે છે. આ તે વસ્તુઓમાંથી એક છે જે અમે ઠીક કરી નથી. પરંતુ જો તમે તેને ઠીક કરવા માંગતા હો, તો તમે આ કરી શકો છો.

અન્ય રેક એ હતું કે અમારી પાસે એક થ્રેડ છે જે તમામ ઇનકમિંગ કનેક્શન્સને સ્વીકારે છે. અને પછી તેઓને વર્કર પૂલમાં સ્થાનાંતરિત કરવામાં આવે છે, જ્યાં TLS હેન્ડશેક થશે.

બોટમ લાઇન, જો તમારી પાસે 20 નેટવર્ક કનેક્શન્સની સુસંગત તરંગ હોય, તો તે બધા સ્વીકારવામાં આવશે. અને ક્લાયન્ટ બાજુ પર libpq સમયસમાપ્તિની જાણ કરવાનું શરૂ કરશે. મૂળભૂત રીતે તે 000 સેકન્ડ લાગે છે.

જો તે બધા એક જ સમયે ડેટાબેઝમાં પ્રવેશી શકતા નથી, તો તેઓ ડેટાબેઝમાં પ્રવેશી શકતા નથી, કારણ કે આ બધું બિન-ઘાતાંકીય પુનઃપ્રયાસ દ્વારા આવરી લેવામાં આવી શકે છે.

અમે એવા નિષ્કર્ષ પર આવ્યા છીએ કે અમે PgBouncerમાંથી સ્કીમની નકલ અહીં એ હકીકત સાથે કરી છે કે અમે TCP કનેક્શનની સંખ્યાને થ્રોટલ કરી રહ્યા છીએ જેને અમે સ્વીકારીએ છીએ.

જો આપણે જોઈએ કે અમે કનેક્શન્સ સ્વીકારી રહ્યા છીએ, પરંતુ તેમની પાસે આખરે હેન્ડશેક કરવાનો સમય નથી, તો અમે તેમને એક કતારમાં મૂકીએ છીએ જેથી તેઓ CPU સંસાધનોનો બગાડ ન કરે. આ એ હકીકત તરફ દોરી જાય છે કે એક સાથે હેન્ડશેક બધા જોડાણો માટે કરી શકાતા નથી જે પહોંચ્યા છે. પરંતુ ઓછામાં ઓછું કોઈ ડેટાબેઝમાં પ્રવેશ કરશે, ભલે ભાર ખૂબ ભારે હોય.

roadmap

તમે ભવિષ્યમાં ઓડિસીમાં શું જોવા માંગો છો? આપણે આપણી જાતને વિકસાવવા માટે શું તૈયાર છીએ અને આપણે સમુદાય પાસેથી શું અપેક્ષા રાખીએ છીએ?

ઓગસ્ટ 2019 મુજબ.

ઓગસ્ટમાં ઓડિસી રોડમેપ આવો દેખાતો હતો:

• અમને SCRAM અને PAM પ્રમાણીકરણ જોઈતું હતું.
• અમે વાંચન વિનંતીઓને સ્ટેન્ડબાય ફોરવર્ડ કરવા માગીએ છીએ.
• હું ઑનલાઇન પુનઃપ્રારંભ કરવા માંગુ છું.
• અને સર્વર પર થોભવાની ક્ષમતા.

આ રોડમેપનો અડધો ભાગ પૂરો થઈ ગયો છે, અમારા દ્વારા નહીં. અને આ સારું છે. તો ચાલો ચર્ચા કરીએ કે શું બાકી છે અને વધુ ઉમેરો.

સ્ટેન્ડબાય પર ફોરવર્ડ ઓન્લી-રીડ ક્વેરીઝ અંગે? અમારી પાસે એવી પ્રતિકૃતિઓ છે જે વિનંતીઓ ચલાવ્યા વિના હવાને ગરમ કરશે. ફેલઓવર અને સ્વિચઓવર આપવા માટે અમને તેમની જરૂર છે. ડેટા સેન્ટર્સમાંના એકમાં સમસ્યાઓના કિસ્સામાં, હું તેમને કેટલાક ઉપયોગી કાર્ય સાથે કબજે કરવા માંગુ છું. કારણ કે આપણે સમાન કેન્દ્રીય પ્રોસેસરો, સમાન મેમરીને અલગ રીતે ગોઠવી શકતા નથી, કારણ કે અન્યથા પ્રતિકૃતિ કામ કરશે નહીં.

સૈદ્ધાંતિક રીતે, પોસ્ટગ્રેસમાં, 10 થી શરૂ કરીને, કનેક્ટ કરતી વખતે session_attrs નો ઉલ્લેખ કરવો શક્ય છે. તમે કનેક્શનમાંના તમામ ડેટાબેઝ હોસ્ટને સૂચિબદ્ધ કરી શકો છો અને કહી શકો છો કે તમે શા માટે ડેટાબેઝ પર જાઓ છો: ફક્ત લખો અથવા વાંચો. અને ડ્રાઇવર પોતે સૂચિમાં પ્રથમ હોસ્ટને પસંદ કરશે જે તેને શ્રેષ્ઠ ગમશે, જે સેશન_એટીઆરની આવશ્યકતાઓને પૂર્ણ કરે છે.

પરંતુ આ અભિગમ સાથે સમસ્યા એ છે કે તે પ્રતિકૃતિ લેગને નિયંત્રિત કરતું નથી. તમારી પાસે કેટલીક પ્રતિકૃતિ હોઈ શકે છે જે તમારી સેવા માટે અસ્વીકાર્ય સમય માટે પાછળ રહી ગઈ છે. પ્રતિકૃતિ પર રીડ ક્વેરીઝના સંપૂર્ણ ફીચર્ડ એક્ઝેક્યુશનને સક્ષમ કરવા માટે, જ્યારે તે વાંચી શકાતું નથી ત્યારે ઓડીસીની ન ચલાવવાની ક્ષમતાને આપણે આવશ્યકપણે સમર્થન આપવાની જરૂર છે.

ઓડિસીએ સમયાંતરે ડેટાબેઝ પર જવું જોઈએ અને પ્રાથમિકથી પ્રતિકૃતિનું અંતર પૂછવું જોઈએ. અને જો તે મર્યાદા મૂલ્ય સુધી પહોંચી ગયું હોય, તો ડેટાબેઝમાં નવી વિનંતીઓને મંજૂરી આપશો નહીં, ક્લાયંટને કહો કે તેને કનેક્શન્સ ફરીથી શરૂ કરવાની જરૂર છે અને, સંભવતઃ, વિનંતીઓ ચલાવવા માટે અન્ય હોસ્ટને પસંદ કરો. આ ડેટાબેઝને પ્રતિકૃતિ લેગને ઝડપથી પુનઃસ્થાપિત કરવાની અને વિનંતી સાથે પ્રતિસાદ આપવા માટે ફરીથી પાછા આવવાની મંજૂરી આપશે.

અમલીકરણ માટે સમયમર્યાદા આપવી મુશ્કેલ છે, કારણ કે તે ઓપન સોર્સ છે. પરંતુ, હું આશા રાખું છું, PgBouncer ના મારા સાથીદારોની જેમ 2,5 વર્ષ નહીં. આ તે લક્ષણ છે જે હું ઓડિસીમાં જોવા માંગુ છું.

સમુદાયમાં, લોકોએ તૈયાર નિવેદન માટે સમર્થન વિશે પૂછ્યું. હવે તમે બે રીતે તૈયાર નિવેદન બનાવી શકો છો. પ્રથમ, તમે SQL આદેશ ચલાવી શકો છો, એટલે કે "તૈયાર". આ SQL આદેશને સમજવા માટે, આપણે બાઉન્સર બાજુ પર SQL ને સમજવાનું શીખવું પડશે. આ ઓવરકિલ હશે, કારણ કે તે ઓવરકિલ છે, કારણ કે આપણને સંપૂર્ણ પાર્સરની જરૂર છે. અમે દરેક SQL આદેશનું વિશ્લેષણ કરી શકતા નથી.

પરંતુ પ્રોટો3 પર સંદેશ પ્રોટોકોલ સ્તરે એક તૈયાર નિવેદન છે. અને આ તે સ્થાન છે જ્યારે તૈયાર નિવેદન બનાવવામાં આવી રહ્યું છે તે માહિતી માળખાગત સ્વરૂપમાં આવે છે. અને અમે એ સમજને સમર્થન આપી શકીએ છીએ કે અમુક સર્વર કનેક્શન પર ક્લાયન્ટે તૈયાર નિવેદનો બનાવવાનું કહ્યું છે. અને જો ટ્રાન્ઝેક્શન બંધ હોય તો પણ આપણે સર્વર અને ક્લાયન્ટ વચ્ચે કનેક્ટિવિટી જાળવી રાખવાની જરૂર છે.

પરંતુ અહીં સંવાદમાં વિસંગતતા ઊભી થાય છે, કારણ કે કોઈ કહે છે કે તમારે સમજવાની જરૂર છે કે ક્લાયન્ટે કયા પ્રકારનાં તૈયાર નિવેદનો બનાવ્યાં છે અને આ સર્વર કનેક્શન બનાવનાર તમામ ક્લાયન્ટ્સ વચ્ચે સર્વર કનેક્શન શેર કરવાની જરૂર છે, એટલે કે, જેમણે આવા તૈયાર નિવેદન બનાવ્યાં છે.

એન્ડ્રેસ ફ્રેઉન્ડે કહ્યું કે જો કોઈ ક્લાયંટ તમારી પાસે આવે છે જેણે પહેલાથી જ બીજા સર્વર કનેક્શનમાં આ પ્રકારનું તૈયાર નિવેદન બનાવ્યું છે, તો તેના માટે તેને બનાવો. પરંતુ ક્લાયન્ટને બદલે ડેટાબેઝમાં ક્વેરી ચલાવવામાં થોડું ખોટું લાગે છે, પરંતુ ડેવલપર જે ડેટાબેઝ સાથે ક્રિયાપ્રતિક્રિયા કરવા માટે પ્રોટોકોલ લખે છે તેના દૃષ્ટિકોણથી, જો તેને ફક્ત નેટવર્ક કનેક્શન આપવામાં આવે તો તે અનુકૂળ રહેશે. આવી તૈયાર ક્વેરી છે.

અને એક વધુ સુવિધા કે જેને આપણે અમલમાં મૂકવાની જરૂર છે. અમારી પાસે હવે PgBouncer સાથે સુસંગત મોનિટરિંગ છે. અમે સરેરાશ ક્વેરી એક્ઝેક્યુશન સમય પરત કરી શકીએ છીએ. પરંતુ સરેરાશ સમય એ હોસ્પિટલમાં સરેરાશ તાપમાન છે: કેટલાક ઠંડા છે, કેટલાક ગરમ છે - સરેરાશ, દરેક સ્વસ્થ છે. તે સાચું નથી.

અમારે પર્સન્ટાઇલ્સ માટે સપોર્ટ લાગુ કરવાની જરૂર છે જે સૂચવે છે કે ત્યાં ધીમી ક્વેરી છે જે સંસાધનોનો બગાડ કરી રહી છે અને મોનિટરિંગને વધુ સ્વીકાર્ય બનાવે છે.

સૌથી મહત્વની બાબત એ છે કે મને સંસ્કરણ 1.0 જોઈએ છે (સંસ્કરણ 1.1 પહેલેથી જ બહાર પાડવામાં આવ્યું છે). હકીકત એ છે કે ઓડિસી હવે સંસ્કરણ 1.0rc માં છે, એટલે કે રિલીઝ ઉમેદવાર. અને બધી સમસ્યાઓ કે જે મેં સૂચિબદ્ધ કરી છે તે મેમરી લીક સિવાય, બરાબર સમાન સંસ્કરણ સાથે ઠીક કરવામાં આવી હતી.

સંસ્કરણ 1.0 નો આપણા માટે શું અર્થ થશે? અમે ઓડિસીને અમારા પાયા પર લઈ જઈ રહ્યા છીએ. તે પહેલાથી જ અમારા ડેટાબેસેસ પર ચાલી રહ્યું છે, પરંતુ જ્યારે તે પ્રતિ સેકન્ડ 1 વિનંતીઓ સુધી પહોંચે છે, ત્યારે આપણે કહી શકીએ કે આ રિલીઝ વર્ઝન છે અને આ એક વર્ઝન છે જેને 000 કહી શકાય.

સમુદાયના કેટલાક લોકોએ પૂછ્યું છે કે સંસ્કરણ 1.0 માં થોભો અને SCRAM શામેલ છે. પરંતુ આનો અર્થ એ થશે કે અમારે ઉત્પાદન માટે આગલા સંસ્કરણને રોલ આઉટ કરવાની જરૂર પડશે, કારણ કે ન તો SCRAM કે વિરામ હજુ સુધી માર્યા ગયા છે. પરંતુ, મોટે ભાગે, આ સમસ્યા ખૂબ ઝડપથી ઉકેલાઈ જશે.

હું તમારી ખેંચવાની વિનંતીની રાહ જોઈ રહ્યો છું. હું એ પણ સાંભળવા માંગુ છું કે તમને બાઉન્સર સાથે કઈ સમસ્યાઓ છે. ચાલો તેમની ચર્ચા કરીએ. કદાચ અમે તમને જોઈતા કેટલાક કાર્યો અમલમાં મૂકી શકીએ.

આ મારા ભાગનો અંત છે, હું તમને સાંભળવા માંગુ છું. આભાર!

પ્રશ્નો

જો હું મારું પોતાનું એપ્લિકેશન_નામ સેટ કરું, તો શું તે ઑડિસીમાં ટ્રાન્ઝેક્શન પૂલિંગ સહિત યોગ્ય રીતે ફોરવર્ડ કરવામાં આવશે?

ઓડીસી કે બાઉન્સર?

ઓડીસીમાં. બાઉન્સરમાં તે ફેંકાય છે.

અમે સેટ કરીશું.

અને જો મારું વાસ્તવિક કનેક્શન અન્ય કનેક્શન્સ પર કૂદી જાય, તો શું તે પ્રસારિત થશે?

અમે સૂચિમાં સૂચિબદ્ધ તમામ પરિમાણોનો સમૂહ બનાવીશું. એપ્લિકેશન_નામ આ સૂચિમાં છે કે કેમ તે હું કહી શકતો નથી. મને લાગે છે કે મેં તેને ત્યાં જોયો છે. અમે બધા સમાન પરિમાણો સેટ કરીશું. એક વિનંતી સાથે, સેટ તે બધું કરશે જે સ્ટાર્ટઅપ દરમિયાન ક્લાયંટ દ્વારા ઇન્સ્ટોલ કરવામાં આવ્યું હતું.

આન્દ્રે, રિપોર્ટ માટે આભાર! સારો અહેવાલ! મને ખુશી છે કે ઓડિસી દર મિનિટે વધુ ઝડપથી અને ઝડપથી વિકાસ કરી રહી છે. હું આ રીતે ચાલુ રાખવા માંગુ છું. અમે તમને મલ્ટી ડેટા-સોર્સ કનેક્શન રાખવા માટે પહેલાથી જ કહ્યું છે કે જેથી Odyssey એકસાથે વિવિધ ડેટાબેસેસ સાથે કનેક્ટ થઈ શકે, એટલે કે એક માસ્ટર સ્લેવ, અને પછી ફેલઓવર પછી આપમેળે નવા માસ્ટર સાથે કનેક્ટ થઈ શકે.

હા, મને આ ચર્ચા યાદ છે એવું લાગે છે. હવે ઘણા સ્ટોરેજ છે. પરંતુ તેમની વચ્ચે કોઈ સ્વિચિંગ નથી. અમારી બાજુએ, આપણે સર્વરનું મતદાન કરવું જોઈએ કે તે હજુ પણ જીવંત છે અને સમજવું જોઈએ કે એક નિષ્ફળતા આવી છે, જે pg_recovery કૉલ કરશે. મારી પાસે સમજવાની પ્રમાણભૂત રીત છે કે અમે માસ્ટર પાસે આવ્યા નથી. અને આપણે ભૂલોમાંથી કોઈક રીતે સમજવું જોઈએ કે શું? એટલે કે, વિચાર રસપ્રદ છે, તેની ચર્ચા થઈ રહી છે. વધુ ટિપ્પણીઓ લખો. જો તમારી પાસે કામદારો છે જેઓ C જાણે છે, તો તે મહાન છે.

પ્રતિકૃતિઓ પર સ્કેલિંગનો મુદ્દો પણ અમારા માટે રસનો છે, કારણ કે અમે એપ્લિકેશન ડેવલપર્સ માટે પ્રતિકૃતિ ક્લસ્ટરોને અપનાવવાનું શક્ય તેટલું સરળ બનાવવા માંગીએ છીએ. પરંતુ અહીં મને વધુ ટિપ્પણીઓ ગમશે, એટલે કે તે કેવી રીતે કરવું, તે કેવી રીતે સારું કરવું.

પ્રશ્ન પ્રતિકૃતિઓનો પણ છે. તે તારણ આપે છે કે તમારી પાસે એક માસ્ટર અને ઘણી પ્રતિકૃતિઓ છે. અને તે સ્પષ્ટ છે કે તેઓ કનેક્શન્સ માટે માસ્ટરની તુલનામાં ઓછી વાર પ્રતિકૃતિ પર જાય છે, કારણ કે તેમાં તફાવત હોઈ શકે છે. તમે કહ્યું હતું કે ડેટામાં તફાવત એટલો હોઈ શકે છે કે તે તમારા વ્યવસાયને સંતોષશે નહીં અને જ્યાં સુધી તેની નકલ ન થાય ત્યાં સુધી તમે ત્યાં જશો નહીં. તે જ સમયે, જો તમે લાંબા સમય સુધી ત્યાં ન ગયા, અને પછી જવાનું શરૂ કર્યું, તો પછી જરૂરી ડેટા તરત જ ઉપલબ્ધ થશે નહીં. એટલે કે, જો આપણે સતત માસ્ટર પાસે જઈએ, તો ત્યાંનો કેશ ગરમ થાય છે, પરંતુ પ્રતિકૃતિમાં કેશ થોડો પાછળ રહે છે.

હા તે સાચું છે. pcache પાસે તમને જોઈતા ડેટા બ્લોક્સ હશે નહીં, વાસ્તવિક કેશમાં તમને જોઈતા કોષ્ટકો વિશેની માહિતી હશે નહીં, યોજનાઓમાં વિશ્લેષિત ક્વેરીઝ હશે નહીં, કંઈપણ હશે નહીં.

અને જ્યારે તમારી પાસે કોઈ પ્રકારનું ક્લસ્ટર હોય, અને તમે ત્યાં એક નવી પ્રતિકૃતિ ઉમેરો, પછી જ્યારે તે શરૂ થાય, ત્યારે તેમાં બધું જ ખરાબ હોય છે, એટલે કે તે તેની કેશને વધારે છે.

મને વિચાર આવ્યો. સાચો અભિગમ એ પ્રતિકૃતિ પર પ્રશ્નોની થોડી ટકાવારી ચલાવવાનો હશે, જે કેશને ગરમ કરશે. સામાન્ય રીતે કહીએ તો, અમારી પાસે એવી શરત છે કે આપણે માસ્ટરથી 10 સેકન્ડથી વધુ પાછળ ન રહેવું જોઈએ. અને આ સ્થિતિ એક તરંગમાં સમાવિષ્ટ નથી, પરંતુ કેટલાક ગ્રાહકો માટે સરળતાથી.

હા, વજન વધારો.

આ એક સારો વિચાર છે. પરંતુ પહેલા આપણે આ શટડાઉનનો અમલ કરવાની જરૂર છે. પહેલા આપણે બંધ કરવાની જરૂર છે, અને પછી અમે કેવી રીતે ચાલુ કરવું તે વિશે વિચારીશું. સરળતાથી સક્ષમ કરવા માટે આ એક સરસ સુવિધા છે.

Nginx પાસે આ વિકલ્પ છે slowly start સર્વર માટે ક્લસ્ટરમાં. અને તે ધીમે ધીમે ભાર વધારતો જાય છે.

હા, સરસ વિચાર, જ્યારે આપણે તેની આસપાસ જઈશું ત્યારે અમે તેનો પ્રયાસ કરીશું.

સોર્સ: www.habr.com