WAL-G: પોસ્ટગ્રેએસક્યુએલ ડીબીએમએસનું બેકઅપ અને પુનઃપ્રાપ્તિ

તે લાંબા સમયથી જાણીતું છે કે SQL ડમ્પમાં બેકઅપ બનાવવું (ઉપયોગ કરીને pg_dump અથવા pg_dumpall) એ સારો વિચાર નથી. PostgreSQL DBMS નો બેકઅપ લેવા માટે, આદેશનો ઉપયોગ કરવો વધુ સારું છે pg_basebackup, જે WAL લોગની બાઈનરી કોપી બનાવે છે. પરંતુ જ્યારે તમે નકલ બનાવવા અને પુનઃસ્થાપિત કરવાની સમગ્ર પ્રક્રિયાનો અભ્યાસ કરવાનું શરૂ કરો છો, ત્યારે તમે સમજી શકશો કે આ કામ કરવા માટે તમારે ઓછામાં ઓછા બે ટ્રાઇસાઇકલ લખવાની જરૂર છે અને તમને ઉપર અને નીચે બંને રીતે પીડા ન થાય. દુઃખ દૂર કરવા માટે, WAL-G વિકસાવવામાં આવી હતી.

WAL-G પોસ્ટગ્રેએસક્યુએલ ડેટાબેસેસનો બેકઅપ લેવા અને પુનઃસ્થાપિત કરવા માટે ગોમાં લખાયેલું સાધન છે (અને તાજેતરમાં MySQL/MariaDB, MongoDB અને FoundationDB). તે એમેઝોન એસ3 સ્ટોરેજ (અને એનાલોગ્સ, ઉદાહરણ તરીકે, યાન્ડેક્ષ ઓબ્જેક્ટ સ્ટોરેજ), તેમજ ગૂગલ ક્લાઉડ સ્ટોરેજ, એઝ્યુર સ્ટોરેજ, સ્વિફ્ટ ઓબ્જેક્ટ સ્ટોરેજ અને ફક્ત ફાઇલ સિસ્ટમ સાથે કામ કરવાનું સમર્થન કરે છે. આખું સેટઅપ સરળ પગલાંઓ પર આવે છે, પરંતુ તે હકીકતને કારણે કે તેના વિશેના લેખો સમગ્ર ઇન્ટરનેટ પર ફેલાયેલા છે, ત્યાં કોઈ સંપૂર્ણ કેવી રીતે કરવું તે માર્ગદર્શિકા નથી જેમાં શરૂઆતથી સમાપ્તિ સુધીના તમામ પગલાં શામેલ હોય (હેબ્રે પર ઘણી પોસ્ટ્સ છે, પરંતુ ત્યાં ઘણા મુદ્દાઓ ચૂકી ગયા છે).

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

અલગથી, હું નોંધ કરું છું કે નીચેની દરેક વસ્તુ સંબંધિત છે અને ઉબુન્ટુ 12.3 પર PostgreSQL 18.04 માટે પરીક્ષણ કરાયેલ છે, બધા આદેશો વિશેષાધિકૃત વપરાશકર્તા તરીકે ચલાવવામાં આવશ્યક છે.

સ્થાપન

આ લેખ લખતી વખતે, WAL-G નું સ્થિર સંસ્કરણ છે v0.2.15 (માર્ચ 2020). આ તે છે જેનો આપણે ઉપયોગ કરીશું (પરંતુ જો તમે તેને માસ્ટર બ્રાન્ચમાંથી જાતે બનાવવા માંગો છો, તો ગીથબ રિપોઝીટરી પાસે આ માટેની તમામ સૂચનાઓ છે.). ડાઉનલોડ અને ઇન્સ્ટોલ કરવા માટે તમારે આ કરવાની જરૂર છે:

#!/bin/bash

curl -L "https://github.com/wal-g/wal-g/releases/download/v0.2.15/wal-g.linux-amd64.tar.gz" -o "wal-g.linux-amd64.tar.gz"
tar -xzf wal-g.linux-amd64.tar.gz
mv wal-g /usr/local/bin/

આ પછી, તમારે પહેલા WAL-G ને ગોઠવવાની જરૂર છે, અને પછી PostgreSQL પોતે.

WAL-G સેટ કરી રહ્યું છે

બેકઅપ સ્ટોર કરવાના ઉદાહરણ માટે, Amazon S3 નો ઉપયોગ કરવામાં આવશે (કારણ કે તે મારા સર્વરની નજીક છે અને તેનો ઉપયોગ ખૂબ સસ્તો છે). તેની સાથે કામ કરવા માટે, તમારે "s3 બકેટ" અને ઍક્સેસ કીની જરૂર પડશે.

WAL-G વિશેના તમામ અગાઉના લેખો પર્યાવરણ ચલોનો ઉપયોગ કરીને રૂપરેખાંકનનો ઉપયોગ કરે છે, પરંતુ આ પ્રકાશન સાથે સેટિંગ્સ આમાં સ્થિત થઈ શકે છે. .walg.json ફાઇલ પોસ્ટગ્રેસ વપરાશકર્તાની હોમ ડિરેક્ટરીમાં. તેને બનાવવા માટે, નીચેની bash સ્ક્રિપ્ટ ચલાવો:

#!/bin/bash

cat > /var/lib/postgresql/.walg.json << EOF
{
    "WALG_S3_PREFIX": "s3://your_bucket/path",
    "AWS_ACCESS_KEY_ID": "key_id",
    "AWS_SECRET_ACCESS_KEY": "secret_key",
    "WALG_COMPRESSION_METHOD": "brotli",
    "WALG_DELTA_MAX_STEPS": "5",
    "PGDATA": "/var/lib/postgresql/12/main",
    "PGHOST": "/var/run/postgresql/.s.PGSQL.5432"
}
EOF
# обязательно меняем владельца файла:
chown postgres: /var/lib/postgresql/.walg.json

ચાલો હું બધા પરિમાણો વિશે થોડું સમજાવું:

• WALG_S3_PREFIX - તમારી S3 બકેટનો માર્ગ જ્યાં બેકઅપ અપલોડ કરવામાં આવશે (તમે કાં તો રૂટ પર અથવા ફોલ્ડરમાં કરી શકો છો);
• AWS_ACCESS_KEY_ID - S3 માં એક્સેસ કી (ટેસ્ટ સર્વર પર પુનઃપ્રાપ્તિના કિસ્સામાં, આ કીઓમાં ફક્ત વાંચવાની નીતિ હોવી આવશ્યક છે! પુનઃપ્રાપ્તિ પરના વિભાગમાં આનું વધુ વિગતવાર વર્ણન કરવામાં આવ્યું છે.);
• AWS_SECRET_ACCESS_KEY - S3 સ્ટોરેજમાં ગુપ્ત કી;
• WALG_COMPRESSION_METHOD - કમ્પ્રેશન પદ્ધતિ, બ્રોટલીનો ઉપયોગ કરવો વધુ સારું છે (કારણ કે આ અંતિમ કદ અને કમ્પ્રેશન/ડિકોમ્પ્રેશન સ્પીડ વચ્ચેનો સોનેરી સરેરાશ છે);
• WALG_DELTA_MAX_STEPS - સંપૂર્ણ બેકઅપ બનાવતા પહેલા "ડેલ્ટા" ની સંખ્યા (તેઓ સમય અને ડાઉનલોડ કરેલ ડેટાનું કદ બચાવે છે, પરંતુ પુનઃપ્રાપ્તિ પ્રક્રિયાને થોડી ધીમી કરી શકે છે, તેથી મોટા મૂલ્યોનો ઉપયોગ કરવાની સલાહ આપવામાં આવતી નથી);
• PGDATA - તમારા ડેટાબેઝ ડેટા સાથે ડિરેક્ટરીનો માર્ગ (તમે આદેશ ચલાવીને શોધી શકો છો pg_lsclusters);
• PGHOST - ડેટાબેઝ સાથે કનેક્ટ કરવું, સ્થાનિક બેકઅપ સાથે આ ઉદાહરણની જેમ યુનિક્સ-સોકેટ દ્વારા કરવું વધુ સારું છે.

અન્ય પરિમાણો દસ્તાવેજોમાં મળી શકે છે: https://github.com/wal-g/wal-g/blob/v0.2.15/PostgreSQL.md#configuration.

PostgreSQL સેટ કરી રહ્યું છે

ડેટાબેઝની અંદરના આર્કીવરને ક્લાઉડ પર WAL લોગ અપલોડ કરવા અને તેમાંથી પુનઃસ્થાપિત કરવા માટે (જો જરૂરી હોય તો), તમારે રૂપરેખાંકન ફાઇલમાં ઘણા પરિમાણો સેટ કરવાની જરૂર છે. /etc/postgresql/12/main/postgresql.conf. માત્ર શરૂઆત માટે તમારે ખાતરી કરવાની જરૂર છેકે નીચેની કોઈપણ સેટિંગ્સ કોઈપણ અન્ય મૂલ્યો પર સેટ કરેલી નથી, જેથી જ્યારે રૂપરેખાંકન ફરીથી લોડ થાય, ત્યારે DBMS ક્રેશ ન થાય. તમે આ પરિમાણોનો ઉપયોગ કરીને ઉમેરી શકો છો:

#!/bin/bash

echo "wal_level=replica" >> /etc/postgresql/12/main/postgresql.conf
echo "archive_mode=on" >> /etc/postgresql/12/main/postgresql.conf
echo "archive_command='/usr/local/bin/wal-g wal-push "%p" >> /var/log/postgresql/archive_command.log 2>&1' " >> /etc/postgresql/12/main/postgresql.conf
echo “archive_timeout=60” >> /etc/postgresql/12/main/postgresql.conf
echo "restore_command='/usr/local/bin/wal-g wal-fetch "%f" "%p" >> /var/log/postgresql/restore_command.log 2>&1' " >> /etc/postgresql/12/main/postgresql.conf

# перезагружаем конфиг через отправку SIGHUP сигнала всем процессам БД
killall -s HUP postgres

સેટ કરવાના પરિમાણોનું વર્ણન:

• wal_level – WAL લોગમાં કેટલી માહિતી લખવી, “પ્રતિકૃતિ” – બધું લખો;
• આર્કાઇવ_મોડ - પેરામીટરમાંથી આદેશનો ઉપયોગ કરીને WAL લોગ ડાઉનલોડ કરવાનું સક્ષમ કરો આર્કાઇવ_કમાન્ડ;
• આર્કાઇવ_કમાન્ડ - પૂર્ણ થયેલ WAL લોગને આર્કાઇવ કરવા માટે આદેશ;
• આર્કાઇવ_સમયસમાપ્ત - લોગનું આર્કાઇવિંગ માત્ર ત્યારે જ કરવામાં આવે છે જ્યારે તે પૂર્ણ થાય, પરંતુ જો તમારું સર્વર ડેટાબેઝમાં થોડો ડેટા બદલે છે/ ઉમેરે છે, તો તે સેકંડમાં અહીં એક મર્યાદા સેટ કરવાનો અર્થપૂર્ણ છે, જે પછી આર્કાઇવિંગ આદેશને બળજબરીથી બોલાવવામાં આવશે (હું દર સેકન્ડે ડેટાબેઝ પર સઘન રીતે લખું છું, તેથી મેં આ પરિમાણને ઉત્પાદનમાં સેટ ન કરવાનું નક્કી કર્યું);
• પુનઃસ્થાપિત_આદેશ - જો "સંપૂર્ણ બેકઅપ" (બેઝ બેકઅપ) ડેટાબેઝમાં નવીનતમ ફેરફારોનો અભાવ હોય તો બેકઅપમાંથી WAL લોગને પુનઃસ્થાપિત કરવાના આદેશનો ઉપયોગ કરવામાં આવશે.

તમે સત્તાવાર દસ્તાવેજોના અનુવાદમાં આ બધા પરિમાણો વિશે વધુ વાંચી શકો છો: https://postgrespro.ru/docs/postgresql/12/runtime-config-wal.

બેકઅપ શેડ્યૂલ સેટ કરી રહ્યું છે

ગમે તે કહે, તેને ચલાવવાની સૌથી અનુકૂળ રીત ક્રોન છે. આ તે છે જે અમે બેકઅપ બનાવવા માટે ગોઠવીશું. ચાલો સંપૂર્ણ બેકઅપ બનાવવા માટે આદેશ સાથે પ્રારંભ કરીએ: wal-g માં આ લોન્ચ દલીલ છે બેકઅપ-પુશ. પરંતુ પ્રથમ, બધું બરાબર છે તેની ખાતરી કરવા માટે પોસ્ટગ્રેસ વપરાશકર્તા પાસેથી આ આદેશને મેન્યુઅલી ચલાવવાનું વધુ સારું છે (અને ત્યાં કોઈ ઍક્સેસ ભૂલો નથી):

#!/bin/bash

su - postgres -c '/usr/local/bin/wal-g backup-push /var/lib/postgresql/12/main'

લોંચ દલીલો ડેટા ડાયરેક્ટરીનો માર્ગ સૂચવે છે - હું તમને યાદ કરાવું છું કે તમે તેને ચલાવીને શોધી શકો છો pg_lsclusters.

જો બધું ભૂલો વિના થયું હોય અને ડેટા S3 સ્ટોરેજમાં લોડ કરવામાં આવ્યો હોય, તો પછી તમે ક્રૉન્ટાબમાં સામયિક લૉન્ચને ગોઠવી શકો છો:

#!/bin/bash

echo "15 4 * * *    /usr/local/bin/wal-g backup-push /var/lib/postgresql/12/main >> /var/log/postgresql/walg_backup.log 2>&1" >> /var/spool/cron/crontabs/postgres
# задаем владельца и выставляем правильные права файлу
chown postgres: /var/spool/cron/crontabs/postgres
chmod 600 /var/spool/cron/crontabs/postgres

આ ઉદાહરણમાં, બેકઅપ પ્રક્રિયા દરરોજ સવારે 4:15 વાગ્યે શરૂ થાય છે.

જૂના બેકઅપ કાઢી રહ્યા છીએ

મોટે ભાગે, તમારે મેસોઝોઇક યુગના તમામ બેકઅપ્સ રાખવાની જરૂર નથી, તેથી તે સમયાંતરે તમારા સ્ટોરેજને "સાફ" કરવા માટે ઉપયોગી થશે (બંને "સંપૂર્ણ બેકઅપ" અને WAL લોગ). અમે આ બધું ક્રોન કાર્ય દ્વારા કરીશું:

#!/bin/bash

echo "30 6 * * *    /usr/local/bin/wal-g delete before FIND_FULL $(date -d '-10 days' '+%FT%TZ') --confirm >> /var/log/postgresql/walg_delete.log 2>&1" >> /var/spool/cron/crontabs/postgres
# ещё раз задаем владельца и выставляем правильные права файлу (хоть это обычно это и не нужно повторно делать)
chown postgres: /var/spool/cron/crontabs/postgres
chmod 600 /var/spool/cron/crontabs/postgres

ક્રોન આ કાર્ય દરરોજ સવારે 6:30 વાગ્યે ચલાવશે, છેલ્લા 10 દિવસની નકલો સિવાય બધું (સંપૂર્ણ બેકઅપ, ડેલ્ટા અને WAL) કાઢી નાખશે, પરંતુ ઓછામાં ઓછું એક બેકઅપ છોડી દેશે. માટે ઉલ્લેખિત તારીખ જેથી કોઈપણ બિંદુ после PITR માં તારીખોનો સમાવેશ કરવામાં આવ્યો હતો.

બેકઅપમાંથી પુનઃસ્થાપિત કરી રહ્યું છે

તે કોઈ રહસ્ય નથી કે તંદુરસ્ત ડેટાબેઝની ચાવી એ સમયાંતરે પુનઃસ્થાપન અને અંદરના ડેટાની અખંડિતતાની ચકાસણી છે. હું તમને આ વિભાગમાં WAL-G નો ઉપયોગ કરીને કેવી રીતે પુનઃપ્રાપ્ત કરવું તે કહીશ, અને અમે પછીથી તપાસ વિશે વાત કરીશું.

તે અલગથી નોંધવું યોગ્ય છે કે જે પરીક્ષણ વાતાવરણમાં પુનઃસ્થાપિત કરવા માટે (જે ઉત્પાદન નથી તે બધું) તમારે S3 માં ફક્ત વાંચવા માટેના એકાઉન્ટનો ઉપયોગ કરવાની જરૂર છે જેથી આકસ્મિક રીતે બેકઅપ પર ફરીથી લખી ન શકાય. WAL-G ના કિસ્સામાં, તમારે S3 વપરાશકર્તા માટે જૂથ નીતિમાં નીચેના અધિકારો સેટ કરવાની જરૂર છે (અસર: મંજૂરી આપો): s3:GetObject, s3:લિસ્ટબકેટ, s3:GetBucketLocation. અને, અલબત્ત, સેટ કરવાનું ભૂલશો નહીં આર્કાઇવ_મોડ=બંધ સેટિંગ્સ ફાઇલમાં postgresql.conf, જેથી તમારો ટેસ્ટ ડેટાબેઝ શાંતિથી બેકઅપ લેવા માંગતો નથી.

પુનઃસંગ્રહ હાથની સહેજ ચળવળ સાથે હાથ ધરવામાં આવે છે બધો PostgreSQL ડેટા કાઢી નાખે છે (વપરાશકર્તાઓ સહિત), તેથી કૃપા કરીને જ્યારે તમે નીચેના આદેશો ચલાવો ત્યારે અત્યંત સાવચેત રહો.

#!/bin/bash

# если есть балансировщик подключений (например, pgbouncer), то вначале отключаем его, чтобы он не нарыгал ошибок в лог
service pgbouncer stop
# если есть демон, который перезапускает упавшие процессы (например, monit), то останавливаем в нём процесс мониторинга базы (у меня это pgsql12)
monit stop pgsql12
# или останавливаем мониторинг полностью
service monit stop
# останавливаем саму базу данных
service postgresql stop
# удаляем все данные из текущей базы (!!!); лучше предварительно сделать их копию, если есть свободное место на диске
rm -rf /var/lib/postgresql/12/main
# скачиваем резервную копию и разархивируем её
su - postgres -c '/usr/local/bin/wal-g backup-fetch /var/lib/postgresql/12/main LATEST'
# помещаем рядом с базой специальный файл-сигнал для восстановления (см. https://postgrespro.ru/docs/postgresql/12/runtime-config-wal#RUNTIME-CONFIG-WAL-ARCHIVE-RECOVERY ), он обязательно должен быть создан от пользователя postgres
su - postgres -c 'touch /var/lib/postgresql/12/main/recovery.signal'
# запускаем базу данных, чтобы она инициировала процесс восстановления
service postgresql start

જેઓ પુનઃપ્રાપ્તિ પ્રક્રિયાને તપાસવા માગે છે તેમના માટે, બેશ મેજિકનો એક નાનો ટુકડો નીચે તૈયાર કરવામાં આવ્યો છે, જેથી પુનઃપ્રાપ્તિમાં સમસ્યાઓના કિસ્સામાં, સ્ક્રિપ્ટ બિન-શૂન્ય એક્ઝિટ કોડ સાથે ક્રેશ થઈ જશે. આ ઉદાહરણમાં, સિગ્નલ ફાઇલ કાઢી નાખવામાં આવી હતી કે કેમ તે શોધવા માટે 120 સેકન્ડ (પુનઃપ્રાપ્તિ માટે કુલ 5 મિનિટ) ના સમયસમાપ્તિ સાથે 10 તપાસ કરવામાં આવે છે (આનો અર્થ એ થશે કે પુનઃપ્રાપ્તિ સફળ હતી):

#!/bin/bash

CHECK_RECOVERY_SIGNAL_ITER=0
while [ ${CHECK_RECOVERY_SIGNAL_ITER} -le 120 ]
do
    if [ ! -f "/var/lib/postgresql/12/main/recovery.signal" ]
    then
        echo "recovery.signal removed"
        break
    fi
    sleep 5
    ((CHECK_RECOVERY_SIGNAL_ITER+1))
done

# если после всех проверок файл всё равно существует, то падаем с ошибкой
if [ -f "/var/lib/postgresql/12/main/recovery.signal" ]
then
    echo "recovery.signal still exists!"
    exit 17
fi

સફળ પુનઃપ્રાપ્તિ પછી, બધી પ્રક્રિયાઓ પાછી શરૂ કરવાનું ભૂલશો નહીં (pgbouncer/monit, વગેરે).

પુનઃપ્રાપ્તિ પછી ડેટા તપાસી રહ્યું છે

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

ડેટા તપાસવા માટે, તેને ડમ્પ દ્વારા ચલાવવા માટે તે પૂરતું છે, પરંતુ તે વધુ સારું છે કે ડેટાબેઝ બનાવતી વખતે તમે ચેકસમ સક્ષમ કરેલ હોય (ડેટા ચેકસમ):

#!/bin/bash

if ! su - postgres -c 'pg_dumpall > /dev/null'
then
    echo 'pg_dumpall failed'
    exit 125
fi

અનુક્રમણિકાઓ તપાસવા માટે - અસ્તિત્વમાં છે amcheck મોડ્યુલ, ચાલો તેના માટે sql ક્વેરી લઈએ WAL-G પરીક્ષણો અને તેની આસપાસ થોડું તર્ક બનાવો:

#!/bin/bash

# добавляем sql-запрос для проверки в файл во временной директории
cat > /tmp/amcheck.sql << EOF
CREATE EXTENSION IF NOT EXISTS amcheck;
SELECT bt_index_check(c.oid), c.relname, c.relpages
FROM pg_index i
JOIN pg_opclass op ON i.indclass[0] = op.oid
JOIN pg_am am ON op.opcmethod = am.oid
JOIN pg_class c ON i.indexrelid = c.oid
JOIN pg_namespace n ON c.relnamespace = n.oid
WHERE am.amname = 'btree'
AND c.relpersistence != 't'
AND i.indisready AND i.indisvalid;
EOF
chown postgres: /tmp/amcheck.sql

# добавляем скрипт для запуска проверок всех доступных баз в кластере
# (обратите внимание что переменные и запуск команд – экранированы)
cat > /tmp/run_amcheck.sh << EOF
for DBNAME in $(su - postgres -c 'psql -q -A -t -c "SELECT datname FROM pg_database WHERE datistemplate = false;" ')
do
    echo "Database: ${DBNAME}"
    su - postgres -c "psql -f /tmp/amcheck.sql -v 'ON_ERROR_STOP=1' ${DBNAME}" && EXIT_STATUS=$? || EXIT_STATUS=$?
    if [ "${EXIT_STATUS}" -ne 0 ]
    then
        echo "amcheck failed on DB: ${DBNAME}"
        exit 125
    fi
done
EOF
chmod +x /tmp/run_amcheck.sh

# запускаем скрипт
/tmp/run_amcheck.sh > /tmp/amcheck.log

# для проверки что всё прошло успешно можно проверить exit code или grep’нуть ошибку
if grep 'amcheck failed' "/tmp/amcheck.log"
then
    echo 'amcheck failed: '
    cat /tmp/amcheck.log
    exit 125
fi

સારાંશ માટે

હું આન્દ્રે બોરોદિનને પ્રકાશન તૈયાર કરવામાં મદદ કરવા બદલ તેમનો આભાર વ્યક્ત કરવા માંગુ છું અને WAL-G ના વિકાસમાં તેમના યોગદાન માટે વિશેષ આભાર!

આ આ નોંધને પૂર્ણ કરે છે. હું આશા રાખું છું કે હું સેટઅપની સરળતા અને તમારી કંપનીમાં આ ટૂલનો ઉપયોગ કરવાની વિશાળ સંભાવના વ્યક્ત કરવામાં સક્ષમ હતો. મેં WAL-G વિશે ઘણું સાંભળ્યું છે, પરંતુ ક્યારેય બેસીને તેને સમજવા માટે પૂરતો સમય મળ્યો નથી. અને મેં તેને ઘરે અમલમાં મૂક્યા પછી, આ લેખ મારામાંથી બહાર આવ્યો.

અલગથી, એ નોંધવું યોગ્ય છે કે WAL-G નીચેના DBMS સાથે પણ કામ કરી શકે છે:

• માયએસક્યુએલ / મારિયાડીબી;
• MongoDB;
• ફાઉન્ડેશનડીબી;
• અને પ્રતિબદ્ધતાઓ દ્વારા અભિપ્રાય, ઘણા વધુ અપેક્ષિત છે!

સોર્સ: www.habr.com