WAL-G: PostgreSQL DBMS এর ব্যাকআপ এবং পুনরুদ্ধার

এটি দীর্ঘদিন ধরেই জানা গেছে যে এসকিউএল ডাম্পগুলিতে ব্যাকআপ তৈরি করা (ব্যবহার করে pg_dump বা pg_dumpall) একটি ভাল ধারণা নয়। PostgreSQL DBMS ব্যাকআপ করতে, কমান্ডটি ব্যবহার করা ভাল pg_basebackup, যা WAL লগের একটি বাইনারি কপি তৈরি করে। কিন্তু যখন আপনি একটি অনুলিপি তৈরি এবং পুনরুদ্ধার করার পুরো প্রক্রিয়াটি অধ্যয়ন করা শুরু করবেন, তখন আপনি বুঝতে পারবেন যে এটি সমস্ত কাজ করার জন্য আপনাকে কমপক্ষে কয়েকটি ট্রাইসাইকেল লিখতে হবে এবং আপনার উপরে এবং নীচে উভয়ই ব্যথা সৃষ্টি করবে না। দুর্ভোগ কমানোর জন্য, WAL-G তৈরি করা হয়েছিল।

ওয়াল-জি PostgreSQL ডাটাবেস ব্যাক আপ এবং পুনরুদ্ধার করার জন্য Go-তে লেখা একটি টুল (এবং অতি সম্প্রতি MySQL/MariaDB, MongoDB এবং FoundationDB) এটি অ্যামাজন S3 স্টোরেজ (এবং অ্যানালগগুলি, উদাহরণস্বরূপ, ইয়ানডেক্স অবজেক্ট স্টোরেজ), সেইসাথে গুগল ক্লাউড স্টোরেজ, অ্যাজুর স্টোরেজ, সুইফট অবজেক্ট স্টোরেজ এবং সহজভাবে ফাইল সিস্টেমের সাথে কাজ করা সমর্থন করে। সম্পূর্ণ সেটআপটি সাধারণ ধাপে নেমে আসে, কিন্তু এই বিষয়ে নিবন্ধগুলি ইন্টারনেট জুড়ে ছড়িয়ে ছিটিয়ে থাকার কারণে, শুরু থেকে শেষ পর্যন্ত সমস্ত পদক্ষেপগুলি অন্তর্ভুক্ত করার জন্য কোনও সম্পূর্ণ কীভাবে ম্যানুয়াল নেই (হাব্রেতে বেশ কয়েকটি পোস্ট রয়েছে, কিন্তু সেখানে অনেক পয়েন্ট মিস করা হয়েছে)।

এই নিবন্ধটি প্রাথমিকভাবে আমার জ্ঞান পদ্ধতিগতভাবে লেখা হয়েছে. আমি একজন DBA নই এবং আমি কোথাও সাধারণ মানুষের ভাষায় নিজেকে প্রকাশ করতে পারি, তাই যেকোনো সংশোধন স্বাগত জানাই!

আমি আলাদাভাবে উল্লেখ করতে চাই যে, নীচের সবকিছুই প্রাসঙ্গিক এবং PostgreSQL 12.3-এর জন্য পরীক্ষিত। Ubuntu ১৮.০৪, সকল কমান্ড অবশ্যই একজন বিশেষাধিকারপ্রাপ্ত ব্যবহারকারী হিসেবে চালাতে হবে।

বিন্যাস

এই নিবন্ধটি লেখার সময়, 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 ফাইল পোস্টগ্রেস ব্যবহারকারীর হোম ডিরেক্টরিতে। এটি তৈরি করতে, নিম্নলিখিত ব্যাশ স্ক্রিপ্টটি চালান:

#!/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 লগগুলিতে কত তথ্য লিখতে হবে, "প্রতিলিপি" - সবকিছু লিখুন;
• সংরক্ষণাগার_মোড - প্যারামিটার থেকে কমান্ড ব্যবহার করে WAL লগ ডাউনলোড করা সক্ষম করুন সংরক্ষণাগার_কমান্ড;
• সংরক্ষণাগার_কমান্ড - একটি সম্পূর্ণ WAL লগ আর্কাইভ করার জন্য কমান্ড;
• আর্কাইভ_টাইমআউট - লগের আর্কাইভিং শুধুমাত্র সম্পন্ন হলেই সঞ্চালিত হয়, কিন্তু যদি আপনার সার্ভার ডাটাবেসে সামান্য ডেটা পরিবর্তন/সংযোজন করে, তাহলে এখানে সেকেন্ডের মধ্যে একটি সীমা নির্ধারণ করা বোধগম্য হয়, যার পরে আর্কাইভিং কমান্ডকে জোর করে ডাকা হবে (আমি প্রতি সেকেন্ডে ডাটাবেসে নিবিড়ভাবে লিখি, তাই আমি এই প্যারামিটারটি উৎপাদনে সেট না করার সিদ্ধান্ত নিয়েছি);
• restore_command - একটি ব্যাকআপ থেকে 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 এ শুরু হয়।

পুরানো ব্যাকআপ মুছে ফেলা হচ্ছে

খুব সম্ভবত, আপনাকে মেসোজোয়িক যুগের একেবারে সমস্ত ব্যাকআপ রাখতে হবে না, তাই এটি পর্যায়ক্রমে আপনার স্টোরেজকে "পরিষ্কার" করার জন্য উপযোগী হবে (উভয় "সম্পূর্ণ ব্যাকআপ" এবং ওয়াল লগ)। আমরা একটি ক্রোন টাস্কের মাধ্যমে এটি করব:

#!/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-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 মডিউল, এর জন্য এসকিউএল কোয়েরি নেওয়া যাক 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 এর সাথেও কাজ করতে পারে:

• মাইএসকিউএল / MariaDB;
• MongoDB;
• ফাউন্ডেশনডিবি;
• এবং কমিট দ্বারা বিচার, আরো বেশ কিছু প্রত্যাশিত!

উত্স: www.habr.com