WAL-G থেকে ব্যাকআপ। 2019 সালে কি আছে? আন্দ্রে বোরোডিন

আমি আপনাকে আন্দ্রে বোরোডিনের 2019 এর শুরু থেকে রিপোর্টের প্রতিলিপি পড়ার পরামর্শ দিচ্ছি "WAL-G এর সাথে ব্যাকআপ। 2019 এ কি আছে?"

হাই সব! আমার নাম আন্দ্রে বোরোদিন। আমি ইয়ানডেক্সের একজন বিকাশকারী। আমি 2016 সাল থেকে PostgreSQL-এ আগ্রহী, যখন আমি ডেভেলপারদের সাথে কথা বলেছিলাম এবং তারা বলেছিল যে সবকিছুই সহজ - আপনি সোর্স কোডটি নিন এবং এটি তৈরি করুন এবং সবকিছু কার্যকর হবে। এবং তারপর থেকে আমি থামতে পারি না - আমি বিভিন্ন ধরণের জিনিস লিখি।

আমি যে জিনিসগুলিতে কাজ করছি তার মধ্যে একটি হল একটি ব্যাকআপ সিস্টেম। ওয়াল-জি. সাধারণভাবে, Yandex-এ আমরা PostgreSQL-এ ব্যাকআপ সিস্টেমে কাজ করছি অনেকদিন ধরে। এবং আমরা কীভাবে ব্যাকআপ সিস্টেম তৈরি করি তার ছয়টি প্রতিবেদনের একটি সিরিজ আপনি ইন্টারনেটে খুঁজে পেতে পারেন। এবং প্রতি বছর তারা একটু বিকশিত হয়, একটু বিকাশ করে এবং আরও নির্ভরযোগ্য হয়ে ওঠে।

কিন্তু আজকের প্রতিবেদনটি কেবল আমরা কী করেছি তা নয়, এটি কতটা সহজ এবং কী তা নিয়েও। আপনারা কতজন ইতিমধ্যেই WAL-G সম্পর্কে আমার রিপোর্ট দেখেছেন? এটা ভাল যে বেশ কয়েকজন লোক দেখেনি, কারণ আমি সবচেয়ে সহজ জিনিস দিয়ে শুরু করব।

যদি হঠাৎ আপনার কাছে একটি PostgreSQL ক্লাস্টার থাকে, এবং আমি মনে করি প্রত্যেকের কাছে তাদের সাথে কয়েকটি আছে, এবং হঠাৎ করে এখনও কোনো ব্যাকআপ সিস্টেম নেই, তাহলে আপনাকে S3 স্টোরেজ বা Google ক্লাউড সামঞ্জস্যপূর্ণ স্টোরেজ পেতে হবে।

উদাহরণস্বরূপ, আপনি আমাদের স্ট্যান্ডে আসতে পারেন এবং Yandex অবজেক্ট স্টোরেজের জন্য একটি প্রচারমূলক কোড নিতে পারেন, যা S3 সামঞ্জস্যপূর্ণ।

তারপর একটি বালতি তৈরি করুন। এটি তথ্যের জন্য একটি ধারক মাত্র।

একটি পরিষেবা ব্যবহারকারী তৈরি করুন।

পরিষেবা ব্যবহারকারীর জন্য একটি অ্যাক্সেস কী তৈরি করুন: aws-s3-key।

WAL-G এর সর্বশেষ স্থিতিশীল রিলিজ ডাউনলোড করুন।

আমাদের প্রি-রিলিজ কীভাবে রিলিজ থেকে আলাদা? আমাকে প্রায়ই তাড়াতাড়ি মুক্তি দিতে বলা হয়। এবং যদি পর্যাপ্ত সময়ের জন্য সংস্করণে কোনও বাগ না থাকে, উদাহরণস্বরূপ, এক মাস, তবে আমি এটি প্রকাশ করি। এখানে নভেম্বর থেকে এই মুক্তি। এবং এর মানে হল যে প্রতি মাসে আমরা কিছু ধরণের বাগ পেয়েছি, সাধারণত অ-সমালোচনামূলক কার্যকারিতায়, কিন্তু আমরা এখনও একটি রিলিজ প্রকাশ করিনি। আগের সংস্করণটি শুধুমাত্র নভেম্বর। এতে আমাদের পরিচিত কোনো বাগ নেই, অর্থাৎ প্রকল্পের অগ্রগতির সাথে সাথে বাগ যোগ করা হয়েছে।

একবার আপনি WAL-G ডাউনলোড করে নিলে, আপনি পরিবেশের ভেরিয়েবলে পাস করে একটি সাধারণ "ব্যাকআপ তালিকা" কমান্ড চালাতে পারেন। এবং এটি অবজেক্ট স্টোরেজের সাথে সংযোগ করবে এবং আপনাকে বলবে আপনার কী ব্যাকআপ আছে। প্রথমে, অবশ্যই, আপনার ব্যাকআপ থাকা উচিত নয়। এই স্লাইডের বিন্দু হল দেখানো যে সবকিছু বেশ সহজ। এটি একটি কনসোল কমান্ড যা পরিবেশের ভেরিয়েবল গ্রহণ করে এবং সাবকমান্ড কার্যকর করে।

এর পরে, আপনি আপনার প্রথম ব্যাকআপ করতে পারেন। WAL-G-তে "ব্যাকআপ-পুশ" বলুন এবং আপনার ক্লাস্টারের pgdata অবস্থান WAL-G-তে উল্লেখ করুন। এবং সম্ভবত, PostgreSQL আপনাকে বলবে, যদি আপনার কাছে ইতিমধ্যে একটি ব্যাকআপ সিস্টেম না থাকে, তাহলে আপনাকে "আর্কাইভ-মোড" সক্ষম করতে হবে।

এর মানে হল যে আপনাকে সেটিংসে যেতে হবে এবং "archive_mode = on" চালু করতে হবে এবং "archive_command" যোগ করতে হবে, যেটি WAL-G-তেও একটি সাবকমান্ড। কিন্তু কিছু কারণে লোকেরা প্রায়শই এই বিষয়ে বার স্ক্রিপ্ট ব্যবহার করে এবং এটি WAL-G এর চারপাশে মোড়ানো হয়। দয়া করে এটা করবেন না। WAL-G-এ পাওয়া কার্যকারিতা ব্যবহার করুন। আপনি যদি কিছু অনুপস্থিত হয়, লিখুন GitHub. WAL-G অনুমান করে যে এটি একমাত্র প্রোগ্রাম যা archive_command এ চলে।

আমরা প্রধানত ইয়ানডেক্স ডেটাবেস ব্যবস্থাপনায় একটি উচ্চ প্রাপ্যতা ক্লাস্টার তৈরি করতে WAL-G ব্যবহার করি।

এবং এটি সাধারণত একটি মাস্টারের টপোলজি এবং বিভিন্ন প্রতিলিপিতে ব্যবহৃত হয়। একই সময়ে, এটি ইয়ানডেক্স অবজেক্ট স্টোরেজে একটি ব্যাকআপ কপি তৈরি করে।

সবচেয়ে সাধারণ পরিস্থিতি হল পয়েন্ট ইন টাইম রিকভারি ব্যবহার করে ক্লাস্টারের কপি তৈরি করা। কিন্তু এই ক্ষেত্রে, ব্যাকআপ সিস্টেমের কর্মক্ষমতা আমাদের জন্য এত গুরুত্বপূর্ণ নয়। আমাদের শুধু ব্যাকআপ থেকে একটি নতুন ক্লাস্টার আপলোড করতে হবে।

সাধারণত, একটি নতুন নোড যোগ করার সময় আমাদের ব্যাকআপ সিস্টেম কর্মক্ষমতা প্রয়োজন। এটা কেন গুরুত্বপূর্ণ? সাধারণত লোকেরা একটি ক্লাস্টারে একটি নতুন নোড যুক্ত করে কারণ বিদ্যমান ক্লাস্টারটি পড়ার লোড পরিচালনা করতে পারে না। তাদের একটি নতুন প্রতিরূপ যোগ করতে হবে। আমরা যদি pg_basebackup থেকে মাস্টারে লোড যোগ করি, তাহলে মাস্টারটি ভেঙে যেতে পারে। অতএব, এটি আমাদের জন্য অত্যন্ত গুরুত্বপূর্ণ ছিল যে আমরা দ্রুত আর্কাইভ থেকে একটি নতুন নোড আপলোড করতে পারি, মাস্টারের উপর ন্যূনতম লোড তৈরি করতে পারি।

এবং আরেকটি অনুরূপ পরিস্থিতি। যে ডেটা সেন্টারের সাথে সংযোগ বিচ্ছিন্ন হয়েছিল সেখান থেকে ক্লাস্টার মাস্টার স্যুইচ করার পরে পুরানো মাস্টারটি পুনরায় চালু করার প্রয়োজন।

• ফলস্বরূপ, কপি সিস্টেমের জন্য প্রয়োজনীয়তা প্রণয়ন করার সময়, আমরা বুঝতে পেরেছিলাম যে ক্লাউডে কাজ করার সময় pg_basebackup আমাদের জন্য উপযুক্ত নয়।
• আমরা আমাদের ডেটা সংকুচিত করতে সক্ষম হতে চেয়েছিলাম। কিন্তু বাক্সে যা আসে তা ছাড়া প্রায় যেকোনো ব্যাকআপ সিস্টেম ডেটা কম্প্রেশন প্রদান করবে।
• আমরা সবকিছুকে সমান্তরাল করতে চেয়েছিলাম কারণ ক্লাউডের একজন ব্যবহারকারী প্রচুর পরিমাণে প্রসেসর কোর কেনেন। কিন্তু কিছু অপারেশনে যদি আমাদের সমান্তরালতা না থাকে, তাহলে বিপুল সংখ্যক কোর অকেজো হয়ে যায়।
• আমাদের এনক্রিপশন দরকার কারণ প্রায়শই ডেটা আমাদের নয় এবং পরিষ্কার পাঠ্যে সংরক্ষণ করা যায় না। যাইহোক, WAL-G তে আমাদের অবদান এনক্রিপশন দিয়ে শুরু হয়েছিল। আমরা WAL-G-তে এনক্রিপশন সম্পন্ন করেছি, তারপরে আমাদের জিজ্ঞাসা করা হয়েছিল: "হয়তো আমাদের মধ্যে একজন প্রকল্পটি বিকাশ করবে?" এবং তারপর থেকে আমি এক বছরেরও বেশি সময় ধরে WAL-G এর সাথে কাজ করছি।
• আমাদের রিসোর্স থ্রটলিংও দরকার ছিল, কারণ সময়ের সাথে সাথে ক্লাউড ব্যবহার করে, আমরা জানতে পেরেছি যে কখনও কখনও লোকেদের রাতে একটি গুরুত্বপূর্ণ মুদির লোড থাকে এবং এই লোডটি হস্তক্ষেপ করা যায় না। সেজন্য আমরা রিসোর্স থ্রটলিং যোগ করেছি।
• পাশাপাশি তালিকা এবং ব্যবস্থাপনা।
• এবং যাচাইকরণ।

আমরা বিভিন্ন সরঞ্জাম অনেক দেখেছি. ভাগ্যক্রমে, PostgreSQL এ আমাদের একটি বিশাল নির্বাচন রয়েছে। এবং সর্বত্র আমরা কিছু অনুপস্থিত ছিল, কিছু একটি ছোট ফাংশন, কিছু একটি ছোট বৈশিষ্ট্য.

এবং বিদ্যমান সিস্টেমগুলি পরীক্ষা করে, আমরা এই সিদ্ধান্তে পৌঁছেছি যে আমরা WAL-G বিকাশ করব। তখন এটি একটি নতুন প্রকল্প ছিল। ব্যাকআপ সিস্টেমের ক্লাউড অবকাঠামোর দিকে বিকাশকে প্রভাবিত করা বেশ সহজ ছিল।

আমরা যে প্রধান আদর্শ মেনে চলি তা হল WAL-G বলালাইকার মতো সরল হওয়া উচিত।

WAL-G এর 4টি কমান্ড রয়েছে। এই:

ওয়াল-পুশ - খাদ সংরক্ষণাগার.

ওয়াল-ফেচ - একটি খাদ পান।

ব্যাকআপ-পুশ - একটি ব্যাকআপ করুন।

BACKUP-FETCH - ব্যাকআপ সিস্টেম থেকে একটি ব্যাকআপ পান৷

প্রকৃতপক্ষে, WAL-G-এর কাছে এই ব্যাকআপগুলির ব্যবস্থাপনাও রয়েছে, অর্থাৎ ইতিহাসে রেকর্ড এবং ব্যাকআপগুলি তালিকাভুক্ত করা এবং মুছে ফেলা যা এই মুহূর্তে আর প্রয়োজন নেই৷

আমাদের জন্য গুরুত্বপূর্ণ ফাংশনগুলির মধ্যে একটি হল ডেল্টা কপি তৈরি করা।

ডেল্টা কপি বলতে আমরা পুরো ক্লাস্টারের সম্পূর্ণ ব্যাকআপ তৈরি করি না, তবে ক্লাস্টারে পরিবর্তিত ফাইলগুলির শুধুমাত্র পরিবর্তিত পৃষ্ঠাগুলি তৈরি করি। এটা মনে হবে যে কার্যকরীভাবে এটি WAL ব্যবহার করে পুনরুদ্ধার করার ক্ষমতার সাথে খুব মিল। কিন্তু আমরা সমান্তরালে একটি WAL একক-থ্রেডেড ডেল্টা ব্যাকআপ রোল আপ করতে পারি। তদনুসারে, যখন আমরা শনিবারে একটি বেসিক ব্যাকআপ তৈরি করি, প্রতিদিন ডেল্টা ব্যাকআপ করি এবং বৃহস্পতিবার আমরা ব্যর্থ হই, তখন আমাদের 4টি ডেল্টা ব্যাকআপ এবং 10 ঘন্টার WAL রোল আপ করতে হবে। এটি প্রায় একই সময় নেবে কারণ ডেল্টা ব্যাকআপগুলি সমান্তরালে রোল হয়৷

LSN-ভিত্তিক ডেল্টা - এর মানে হল যে একটি ব্যাকআপ তৈরি করার সময়, এটি পরিবর্তিত হয়েছে তা বোঝার জন্য আমাদের প্রতিটি পৃষ্ঠাকে একত্রিত করতে হবে এবং পূর্ববর্তী ব্যাকআপের LSN এর সাথে এর LSN চেক করতে হবে। যে কোনো পৃষ্ঠায় সম্ভাব্য পরিবর্তিত ডেটা থাকতে পারে ডেল্টা ব্যাকআপে উপস্থিত থাকা উচিত।

আমি যেমন বলেছি, সমান্তরালতার দিকে অনেক মনোযোগ দেওয়া হয়েছিল।

কিন্তু PostgreSQL-এ আর্কাইভ API সামঞ্জস্যপূর্ণ। PostgreSQL একটি WAL ফাইল সংরক্ষণ করে এবং এটি পুনরুদ্ধার করার সময় একটি WAL ফাইলের অনুরোধ করে। কিন্তু যখন ডাটাবেস "WAL-FETCH" কমান্ড ব্যবহার করে একটি WAL ফাইলের অনুরোধ করে, তখন আমরা "WAL-PREFETCH" কমান্ড বলি, যা সমান্তরালভাবে অবজেক্ট স্টোর থেকে ডেটা আনার জন্য পরবর্তী 8টি ফাইল প্রস্তুত করে।

এবং যখন ডাটাবেস আমাদেরকে একটি ফাইল সংরক্ষণ করতে বলে, তখন আমরা archive_status দেখি এবং দেখি অন্য WAL ফাইল আছে কিনা। এবং আমরা সমান্তরালভাবে WAL ডাউনলোড করার চেষ্টা করছি। এটি একটি উল্লেখযোগ্য পারফরম্যান্স লাভ প্রদান করে এবং অসংরক্ষিত WAL-এর সংখ্যার দূরত্বকে উল্লেখযোগ্যভাবে হ্রাস করে। অনেক ব্যাকআপ সিস্টেম ডেভেলপার বিশ্বাস করেন যে এটি একটি ঝুঁকিপূর্ণ সিস্টেম কারণ আমরা আমাদের কোডের অভ্যন্তরীণ জ্ঞানের উপর নির্ভর করি যা PostgreSQL API নয়। PostgreSQL আমাদের জন্য আর্কাইভ_স্ট্যাটাস ফোল্ডারের উপস্থিতির গ্যারান্টি দেয় না এবং শব্দার্থবিদ্যা, সেখানে WAL ফাইলের জন্য প্রস্তুতি সংকেত উপস্থিতির নিশ্চয়তা দেয় না। তবুও, আমরা সোর্স কোড অধ্যয়ন করছি, আমরা দেখতে পাচ্ছি যে এটি তাই এবং আমরা এটিকে কাজে লাগানোর চেষ্টা করছি। এবং আমরা PostgreSQL যে দিকে বিকাশ করছে তা নিয়ন্ত্রণ করি; যদি হঠাৎ এই প্রক্রিয়াটি ভেঙে যায়, আমরা এটি ব্যবহার করা বন্ধ করে দেব।

এর বিশুদ্ধ আকারে, LSN-ভিত্তিক WAL ডেল্টাতে যেকোন ক্লাস্টার ফাইল পড়তে হবে যার ফাইল সিস্টেমে মোড-টাইম আগের ব্যাকআপের পর থেকে পরিবর্তিত হয়েছে। আমরা এটির সাথে দীর্ঘকাল, প্রায় এক বছর বেঁচে ছিলাম। এবং শেষ পর্যন্ত আমরা উপসংহারে এসেছি যে আমাদের ওয়াল ডেল্টা আছে।

এর মানে হল যে যতবার আমরা মাস্টারে WAL আর্কাইভ করি, আমরা শুধু এটিকে সংকুচিত করি না, এটি এনক্রিপ্ট করি এবং নেটওয়ার্কে পাঠাই, কিন্তু একই সময়ে আমরা এটি পড়ি। আমরা এটির রেকর্ডগুলি বিশ্লেষণ করি এবং পড়ি। আমরা বুঝতে পারি কোন ব্লকগুলি পরিবর্তিত হয়েছে এবং ডেল্টা ফাইলগুলি সংগ্রহ করে৷

একটি ডেল্টা ফাইল WAL ফাইলের একটি নির্দিষ্ট পরিসর বর্ণনা করে, WAL-এর এই পরিসরে কোন ব্লকগুলি পরিবর্তন করা হয়েছে সে সম্পর্কে তথ্য বর্ণনা করে। এবং তারপর এই ডেল্টা ফাইল এছাড়াও আর্কাইভ করা হয়.

এখানে আমরা এই সত্যটির মুখোমুখি হয়েছি যে আমরা খুব দ্রুত সবকিছু সমান্তরাল করেছি, তবে আমরা সমান্তরালে একটি ক্রমিক ইতিহাস পড়তে পারি না, কারণ একটি নির্দিষ্ট বিভাগে আমরা পূর্ববর্তী WAL রেকর্ডের সমাপ্তির মুখোমুখি হতে পারি, যার সাথে আমাদের এখনও সংযোগ করার কিছু নেই, কারণ সমান্তরাল পাঠের ফলে আমরা প্রথমে ভবিষ্যৎ বিশ্লেষণ করি, যার এখনও কোনো অতীত নেই।

ফলস্বরূপ, আমাদের _ডেল্টা_আংশিক ফাইলগুলিতে বোধগম্য টুকরোগুলি রাখতে হয়েছিল। ফলস্বরূপ, আমরা যখন অতীতে ফিরে আসি, তখন আমরা WAL রেকর্ডের টুকরোগুলিকে একটিতে আঠালো করব, তারপরে আমরা এটি বিশ্লেষণ করব এবং বুঝতে পারব এতে কী পরিবর্তন হয়েছে।

যদি আমাদের শ্যাফ্ট পার্সিংয়ের ইতিহাসে অন্তত একটি পয়েন্ট থাকে যেখানে আমরা বুঝতে পারি না যে কী ঘটছে, তাহলে, সেই অনুযায়ী, পরবর্তী ব্যাকআপের সময় আমরা আবার পুরো ক্লাস্টারটি পড়তে বাধ্য হব, ঠিক যেমন আমরা একটি নিয়মিত LSN এর সাথে করেছি। - ভিত্তিক ব-দ্বীপ।

ফলস্বরূপ, আমাদের সমস্ত দুর্ভোগ এই সত্যের দিকে পরিচালিত করে যে আমরা WAL-G পার্সিং লাইব্রেরি ওপেন সোর্স করেছি। আমি যতদূর জানি, কেউ এখনও এটি ব্যবহার করছে না, তবে কেউ যদি এটি লিখতে এবং ব্যবহার করতে চায় তবে এটি সর্বজনীন ডোমেইনে রয়েছে। (আপডেট করা লিঙ্ক https://github.com/wal-g/wal-g/tree/master/internal/walparser)

ফলস্বরূপ, সমস্ত তথ্য প্রবাহ বেশ জটিল দেখায়। আমাদের মাস্টার শ্যাফট সংরক্ষণাগার এবং ডেল্টা ফাইল সংরক্ষণাগার. এবং যে প্রতিলিপিটি ব্যাকআপ অনুলিপি তৈরি করে তা অবশ্যই ব্যাকআপগুলির মধ্যে অতিবাহিত হওয়ার সময় ডেল্টা ফাইলগুলি গ্রহণ করবে৷ এই ক্ষেত্রে, ইতিহাসের অংশগুলিকে প্রচুর পরিমাণে যোগ করতে হবে এবং পার্স করতে হবে, কারণ পুরো ইতিহাস বড় অংশে খাপ খায় না। এবং শুধুমাত্র এর পরেই প্রতিরূপটি একটি সম্পূর্ণ ডেল্টা ব্যাকআপ সংরক্ষণাগারভুক্ত করতে পারে।

গ্রাফে সবকিছু অনেক সহজ দেখায়। এটি আমাদের প্রকৃত ক্লাস্টারগুলির একটি থেকে একটি ডাউনলোড। আমাদের LSN-ভিত্তিক, একদিনে তৈরি। এবং আমরা দেখি যে LSN-ভিত্তিক ডেল্টা ব্যাকআপ সকাল তিনটা থেকে ভোর পাঁচটা পর্যন্ত চলছিল। এটি প্রসেসর কোরের সংখ্যার লোড। ওয়াল-ডেল্টা আমাদের এখানে প্রায় 20 মিনিট সময় নিয়েছে। অর্থাৎ, এটি উল্লেখযোগ্যভাবে দ্রুত হয়ে উঠেছে, কিন্তু একই সময়ে নেটওয়ার্কে আরও তীব্র বিনিময় ছিল।

যেহেতু ডাটাবেসের ইতিহাসে কোন ব্লক এবং কোন সময়ে পরিবর্তন হয়েছে সে সম্পর্কে আমাদের কাছে তথ্য রয়েছে, তাই আমরা আরও এগিয়ে গিয়ে কার্যকারিতা একীভূত করার সিদ্ধান্ত নিয়েছি - একটি PostgreSQL এক্সটেনশন যাকে বলা হয় "pg_prefaulter"

এর মানে হল যে যখন স্ট্যান্ড-বাই বেস পুনরুদ্ধার কমান্ডটি কার্যকর করে, তখন এটি WAL-G কে পরবর্তী WAL ফাইলটি আনতে বলে। WAL পুনরুদ্ধার প্রক্রিয়া অদূর ভবিষ্যতে কোন ডেটা ব্লকগুলিকে অ্যাক্সেস করবে এবং এই ব্লকগুলিতে একটি পঠিত অপারেশন শুরু করবে তা আমরা বুঝতে পারি। এসএসডি কন্ট্রোলারের কর্মক্ষমতা বাড়ানোর জন্য এটি করা হয়েছিল। কারণ ওয়াল রোলটি সেই পৃষ্ঠায় পৌঁছে যাবে যা পরিবর্তন করতে হবে। এই পৃষ্ঠাটি ডিস্কে রয়েছে এবং পৃষ্ঠার ক্যাশে নেই৷ এবং তিনি এই পৃষ্ঠাটি আসার জন্য সিঙ্ক্রোনাসভাবে অপেক্ষা করবেন। কিন্তু কাছাকাছি রয়েছে WAL-G, যেটি জানে যে WAL-এর পরবর্তী কয়েকশো মেগাবাইটে আমাদের কিছু নির্দিষ্ট পৃষ্ঠার প্রয়োজন হবে এবং একই সাথে সেগুলিকে উষ্ণ করা শুরু করে। একাধিক ডিস্ক অ্যাক্সেস শুরু করে যাতে সেগুলি সমান্তরালভাবে চালানো হয়। এটি এসএসডি ড্রাইভে ভাল কাজ করে, কিন্তু, দুর্ভাগ্যবশত, এটি একটি হার্ড ড্রাইভের জন্য একেবারেই প্রযোজ্য নয়, কারণ আমরা শুধুমাত্র আমাদের প্রম্পট দিয়ে এতে হস্তক্ষেপ করি।

এই কোড এখন কি আছে.

আমরা যোগ করতে চাই যে বৈশিষ্ট্য আছে.

এই ছবিটি দেখায় যে ওয়াল-ডেল্টা অপেক্ষাকৃত কম সময় নেয়। এবং এটি দিনের বেলা ডাটাবেসে ঘটে যাওয়া পরিবর্তনগুলি পড়ছে। আমরা ওয়াল-ডেল্টা করতে পারি না শুধুমাত্র রাতে, কারণ এটি আর লোডের একটি উল্লেখযোগ্য উৎস নয়। আমরা প্রতি মিনিটে WAL-ডেল্টা পড়তে পারি কারণ এটি সস্তা। এক মিনিটের মধ্যে আমরা ক্লাস্টারে যে সমস্ত পরিবর্তন ঘটেছে তা স্ক্যান করতে পারি। এবং এটিকে "তাত্ক্ষণিক ওয়াল-ডেল্টা" বলা যেতে পারে।

বিন্দু হল যে যখন আমরা ক্লাস্টার পুনরুদ্ধার করি, তখন আমরা গল্পের সংখ্যা কমিয়ে দিই যা আমাদের ক্রমাগতভাবে রোল আপ করতে হবে। অর্থাৎ, PostgreSQL রোল করা WAL-এর পরিমাণ কমাতে হবে, কারণ এতে উল্লেখযোগ্য সময় লাগে।

কিন্তু এখানেই শেষ নয়. যদি আমরা জানি যে কিছু ব্লক ব্যাকআপ সামঞ্জস্যের বিন্দুতে পরিবর্তন করা হবে, আমরা অতীতে এটি পরিবর্তন করতে পারি না। অর্থাৎ, এখন আমাদের কাছে WAL-ডেল্টা ফরওয়ার্ডিংয়ের ফাইল-বাই-ফাইল অপ্টিমাইজেশন রয়েছে। এর মানে হল যে, উদাহরণস্বরূপ, যদি মঙ্গলবার একটি টেবিল সম্পূর্ণরূপে মুছে ফেলা হয় বা কিছু ফাইল সম্পূর্ণরূপে টেবিল থেকে মুছে ফেলা হয়, তাহলে সোমবার যখন ডেল্টা রোল ওভার হয় এবং শনিবারের pg_basebackup পুনরুদ্ধার করা হয়, আমরা এমনকি এই ডেটা তৈরি করব না।

আমরা এই প্রযুক্তিকে পেজ লেভেল পর্যন্ত প্রসারিত করতে চাই। অর্থাৎ, যদি ফাইলের কিছু অংশ সোমবার পরিবর্তন হয় তবে বুধবার ওভাররাইট করা হবে, তাহলে বৃহস্পতিবার একটি বিন্দুতে পুনরুদ্ধার করার সময়, আমাদের পৃষ্ঠাগুলির প্রথম কয়েকটি সংস্করণ ডিস্কে লিখতে হবে না।

তবে এটি এখনও একটি ধারণা যা আমাদের মধ্যে সক্রিয়ভাবে আলোচনা করা হচ্ছে, তবে এটি এখনও কোডে পৌঁছায়নি।

আমরা WAL-G-তে আরও একটি বৈশিষ্ট্য তৈরি করতে চাই। আমরা এটিকে এক্সটেনসিবল করতে চাই কারণ আমাদের বিভিন্ন ডাটাবেস সমর্থন করতে হবে এবং একইভাবে ব্যাকআপ ব্যবস্থাপনার কাছে যেতে সক্ষম হতে চাই। কিন্তু সমস্যা হল যে মাইএসকিউএল এপিআইগুলি আমূল ভিন্ন। MySQL-এ, PITR ভৌত WAL লগের উপর নয়, binlog-এর উপর ভিত্তি করে। এবং আমাদের MySQL-এ একটি আর্কাইভিং সিস্টেম নেই যা কিছু বাহ্যিক সিস্টেমকে বলবে যে এই বিনলগটি শেষ হয়েছে এবং আর্কাইভ করা দরকার। আমাদের ডাটাবেসের সাথে ক্রোনের কোথাও দাঁড়াতে হবে এবং কিছু প্রস্তুত আছে কিনা তা পরীক্ষা করতে হবে?

এবং একইভাবে, একটি মাইএসকিউএল পুনরুদ্ধারের সময়, এমন কোনও পুনরুদ্ধার কমান্ড নেই যা সিস্টেমকে বলতে পারে যে আমার এই জাতীয় ফাইলগুলির প্রয়োজন। আপনি আপনার ক্লাস্টার পুনর্নির্মাণ শুরু করার আগে, আপনাকে জানতে হবে আপনার কোন ফাইলগুলির প্রয়োজন হবে৷ আপনি নিজেই অনুমান করতে হবে আপনার কি ফাইল প্রয়োজন হবে. তবে এই সমস্যাগুলি কোনওভাবে কাটিয়ে উঠতে সক্ষম হতে পারে। (স্পষ্টকরণ: MySQL ইতিমধ্যে সমর্থিত)

প্রতিবেদনে, আমি সেই ক্ষেত্রেও কথা বলতে চেয়েছিলাম যখন WAL-G আপনার জন্য উপযুক্ত নয়।

আপনার যদি একটি সিঙ্ক্রোনাস প্রতিরূপ না থাকে, তাহলে WAL-G গ্যারান্টি দেয় না যে শেষ অংশটি সংরক্ষিত হবে। এবং যদি সংরক্ষণাগার ইতিহাসের শেষ কয়েকটি অংশ থেকে পিছিয়ে থাকে তবে এটি একটি ঝুঁকি। যদি কোন সিঙ্ক্রোনাস প্রতিরূপ না থাকে, আমি WAL-G ব্যবহার করার সুপারিশ করব না। তবুও, এটি মূলত একটি ক্লাউড ইনস্টলেশনের জন্য ডিজাইন করা হয়েছে, যা একটি সিঙ্ক্রোনাস প্রতিরূপ সহ একটি উচ্চ প্রাপ্যতা সমাধানকে বোঝায়, যা প্রতিশ্রুত শেষ বাইটের নিরাপত্তার জন্য দায়ী৷

আমি প্রায়ই লোকেদের একই সময়ে WAL-G এবং WAL-E উভয় চালানোর চেষ্টা করতে দেখি। আমরা এই অর্থে পশ্চাদমুখী সামঞ্জস্যতা সমর্থন করি যে WAL-G WAL-E থেকে একটি ফাইল পুনরুদ্ধার করতে পারে এবং WAL-E-এ তৈরি একটি ব্যাকআপ পুনরুদ্ধার করতে পারে। কিন্তু যেহেতু এই দুটি সিস্টেমই সমান্তরাল ওয়াল-পুশ ব্যবহার করে, তারা একে অপরের থেকে ফাইল চুরি করতে শুরু করে। যদি আমরা এটিকে WAL-G-এ ঠিক করি, তবে এটি এখনও WAL-E-তে থাকবে। WAL-E-তে, এটি আর্কাইভ-স্ট্যাটাস দেখে, সমাপ্ত ফাইলগুলি দেখে এবং সেগুলি আর্কাইভ করে, যখন অন্যান্য সিস্টেমগুলি কেবল জানবে না যে এই WAL ফাইলটি বিদ্যমান ছিল, কারণ PostgreSQL এটিকে দ্বিতীয়বার সংরক্ষণাগার করার চেষ্টা করবে না।

আমরা এখানে WAL-G দিকে কী ঠিক করতে যাচ্ছি? আমরা PostgreSQL কে জানাব না যে এই ফাইলটি সমান্তরালভাবে স্থানান্তরিত হয়েছে, এবং যখন PostgreSQL আমাদেরকে এটি আর্কাইভ করতে বলবে, আমরা ইতিমধ্যেই জানব যে এই মোড-টাইম এবং এই md5 সহ এই ধরনের একটি ফাইল ইতিমধ্যেই আর্কাইভ করা হয়েছে এবং আমরা শুধু বলব PostgreSQL - ঠিক আছে, কিছু না করেই সবকিছু প্রস্তুত।

কিন্তু এই সমস্যাটি WAL-E দিকে ঠিক হওয়ার সম্ভাবনা নেই, তাই বর্তমানে একটি আর্কাইভ কমান্ড তৈরি করা অসম্ভব যেটি WAL-G এবং WAL-E উভয় ক্ষেত্রেই ফাইলটিকে আর্কাইভ করবে।

এছাড়াও, এমন কিছু ক্ষেত্রে রয়েছে যেখানে WAL-G এখন আপনার জন্য উপযুক্ত নয়, তবে আমরা অবশ্যই এটি ঠিক করব।

প্রথমত, বর্তমানে আমাদের বিল্ট-ইন ব্যাকআপ যাচাইকরণ নেই। ব্যাকআপ বা পুনরুদ্ধারের সময় আমাদের যাচাইকরণ নেই। অবশ্যই, এটি ক্লাউডে প্রয়োগ করা হয়। কিন্তু এটি শুধুমাত্র প্রাক-পরীক্ষার মাধ্যমে বাস্তবায়িত হয়, কেবল ক্লাস্টার পুনরুদ্ধার করে। আমি ব্যবহারকারীদের এই কার্যকারিতা দিতে চাই। কিন্তু যাচাইকরণের মাধ্যমে, আমি অনুমান করি যে WAL-G-তে ক্লাস্টারটি পুনরুদ্ধার করা এবং এটি চালু করা এবং ধোঁয়া পরীক্ষা চালানো সম্ভব হবে: pg_dumpall থেকে /dev/null এবং amcheck সূচক যাচাইকরণ।

বর্তমানে WAL-G-তে WAL থেকে একটি ব্যাকআপ স্থগিত করার কোনো উপায় নেই। যে, আমরা কিছু উইন্ডো সমর্থন করি। উদাহরণস্বরূপ, শেষ সাত দিন সংরক্ষণ করা, শেষ দশটি ব্যাকআপ সংরক্ষণ করা, শেষ তিনটি সম্পূর্ণ ব্যাকআপ সংরক্ষণ করা। প্রায়শই লোকেরা এসে বলে: "নববর্ষে যা ঘটেছিল তার একটি ব্যাকআপ আমাদের প্রয়োজন এবং আমরা এটি চিরতরে রাখতে চাই।" WAL-G এখনও এটি করতে পারে না৷ (দ্রষ্টব্য - এটি ইতিমধ্যেই ঠিক করা হয়েছে। আরও পড়ুন - ব্যাকআপ-মার্ক বিকল্পে https://github.com/wal-g/wal-g/blob/master/PostgreSQL.md)

এবং পিআইটিআর যাচাই করার সময় আমাদের কাছে সমস্ত শ্যাফ্ট সেগমেন্টের জন্য পৃষ্ঠা চেকসাম এবং অখণ্ডতা পরীক্ষা নেই।

এই সব থেকে আমি গুগল সামার অফ কোডের জন্য একটি প্রকল্প একসাথে রাখলাম। আপনি যদি বুদ্ধিমান ছাত্রদের চেনেন যারা Go-তে কিছু লিখতে চান এবং “G” অক্ষর সহ একটি কোম্পানি থেকে কয়েক হাজার ডলার পেতে চান, তাহলে তাদের কাছে আমাদের প্রকল্পের সুপারিশ করুন। আমি এই প্রকল্পের জন্য একজন পরামর্শদাতা হিসাবে কাজ করব, তারা এটি করতে পারে। যদি কোন ছাত্র না থাকে, তাহলে আমি এটি গ্রহণ করব এবং গ্রীষ্মে এটি নিজেই করব।

এবং আমাদের আরও অনেক ছোট ছোট সমস্যা আছে যেগুলো আমরা ধীরে ধীরে সমাধান করছি। এবং কিছু চমত্কার অদ্ভুত জিনিস ঘটে.

উদাহরণস্বরূপ, আপনি যদি WAL-G-কে একটি খালি ব্যাকআপ দেন তবে এটি সহজভাবে পড়ে যাবে। উদাহরণস্বরূপ, যদি আপনি তাকে বলেন যে তাকে একটি খালি ফোল্ডার ব্যাকআপ করতে হবে। pg_control ফাইলটি সেখানে থাকবে না। এবং সে ভাববে যে সে কিছু বোঝে না। তাত্ত্বিকভাবে, এই ক্ষেত্রে আপনাকে ব্যবহারকারীর কাছে একটি সাধারণ বার্তা লিখতে হবে তাকে ব্যাখ্যা করার জন্য কীভাবে সরঞ্জামটি ব্যবহার করবেন। তবে এটি এমনকি প্রোগ্রামিংয়ের একটি বৈশিষ্ট্য নয়, তবে একটি ভাল, বোধগম্য ভাষার বৈশিষ্ট্য।

আমরা জানি না কিভাবে অফলাইন ব্যাকআপ করতে হয়। যদি ডাটাবেস মিথ্যা হয়, আমরা এটি ব্যাকআপ করতে পারি না। কিন্তু এখানে সবকিছু খুব সহজ। যখন এটি শুরু হয় তখন আমরা LSN দ্বারা ব্যাকআপ কল করি৷ অন্তর্নিহিত বেসের LSN অবশ্যই কন্ট্রোল ফাইল থেকে পড়তে হবে। এবং এটি এমন একটি অবাস্তব বৈশিষ্ট্য। অনেক ব্যাকআপ সিস্টেম একটি অন্তর্নিহিত ডাটাবেস ব্যাকআপ করতে পারে। এবং এটা সুবিধাজনক.

আমরা বর্তমানে ব্যাকআপ স্থানের অভাব সঠিকভাবে পরিচালনা করতে পারি না। কারণ আমরা সাধারণত বাড়িতে বড় ব্যাকআপ নিয়ে কাজ করি। এবং তারা এটির কাছাকাছি পায়নি। কিন্তু কেউ যদি এখনই গো-তে প্রোগ্রাম করতে চায়, তাহলে বালতিতে স্থান-বহির্ভূত ত্রুটির জন্য হ্যান্ডলিং যোগ করুন। আমি স্পষ্টভাবে টান অনুরোধে দেখব.

এবং প্রধান জিনিস যা আমাদের উদ্বিগ্ন করে তা হল আমরা যতটা সম্ভব ডকার ইন্টিগ্রেশন পরীক্ষা চাই যা বিভিন্ন পরিস্থিতিতে পরীক্ষা করে। এই মুহূর্তে আমরা শুধুমাত্র মৌলিক পরিস্থিতি পরীক্ষা করছি। প্রতিটি প্রতিশ্রুতিতে, তবে আমরা যে সমস্ত কার্যকারিতা সমর্থন করি তা আমরা প্রতিশ্রুতিবদ্ধভাবে পরীক্ষা করতে চাই। বিশেষ করে, উদাহরণস্বরূপ, PostgreSQL 9.4-9.5 এর জন্য আমাদের যথেষ্ট সমর্থন থাকবে। আমরা তাদের সমর্থন করি কারণ সম্প্রদায়টি PostgreSQL সমর্থন করে, কিন্তু সবকিছু ভেঙে না গেছে তা নিশ্চিত করতে আমরা কমিট-বাই-কমিট পরীক্ষা করি না। এবং এটা আমার মনে হয় যে এটি একটি বরং গুরুতর ঝুঁকি।

ইয়ানডেক্স ডেটাবেস ম্যানেজমেন্টে আমাদের এক হাজারেরও বেশি ক্লাস্টারে WAL-G চলছে। এবং এটি প্রতিদিন কয়েকশ টেরাবাইট ডেটা ব্যাক আপ করে।

আমাদের কোডে অনেক TODO আছে। আপনি যদি প্রোগ্রাম করতে চান, আসুন, আমরা টান অনুরোধের জন্য অপেক্ষা করছি, আমরা প্রশ্নের জন্য অপেক্ষা করছি।

প্রশ্ন

শুভ সন্ধ্যা! ধন্যবাদ! আমার অনুমান হল যে আপনি যদি WAL-delta ব্যবহার করেন, আপনি সম্ভবত পূর্ণ-পৃষ্ঠার লেখার উপর খুব বেশি নির্ভর করছেন। এবং যদি তাই হয়, আপনি কি পরীক্ষা চালান? আপনি একটি সুন্দর গ্রাফ দেখিয়েছেন. FPW বন্ধ থাকলে এটি আর কত সুন্দর হয়ে যায়?

পূর্ণ-পৃষ্ঠার লেখাগুলি আমাদের জন্য সক্ষম, আমরা এটি নিষ্ক্রিয় করার চেষ্টা করিনি। অর্থাৎ, আমি, একজন বিকাশকারী হিসাবে, এটি বন্ধ করার চেষ্টা করিনি। সিস্টেম অ্যাডমিনিস্ট্রেটররা যারা গবেষণা করেছেন তারা সম্ভবত এই সমস্যাটি নিয়ে গবেষণা করেছেন। কিন্তু আমাদের FPW দরকার। প্রায় কেউই এটি নিষ্ক্রিয় করে না, কারণ অন্যথায় একটি প্রতিরূপ থেকে ব্যাকআপ নেওয়া অসম্ভব।

প্রতিবেদনের জন্য ধন্যবাদ! আমার দুটি প্রশ্ন আছে। প্রথম প্রশ্ন টেবিলস্পেস কি হবে?

আমরা একটি টান অনুরোধের জন্য অপেক্ষা করছি. আমাদের ডাটাবেসগুলি SSD এবং NMVE ডিস্কগুলিতে বাস করে এবং আমাদের এই বৈশিষ্ট্যটির সত্যিই প্রয়োজন নেই। আমি এই মুহূর্তে এটি ভাল করার জন্য গুরুতর সময় ব্যয় করতে প্রস্তুত নই। আমি আন্তরিকভাবে সমর্থন করি যে আমরা এটি সমর্থন করি। এমন কিছু লোক আছে যারা এটিকে সমর্থন করেছিল, কিন্তু এটিকে এমনভাবে সমর্থন করেছিল যা তাদের জন্য উপযুক্ত। তারা একটি কাঁটাচামচ তৈরি, কিন্তু তারা অনুরোধ টান না. (0.2.13 সংস্করণে যোগ করা হয়েছে)

এবং দ্বিতীয় প্রশ্ন। আপনি একেবারে শুরুতে বলেছিলেন যে WAL-G অনুমান করে যে এটি একা কাজ করে এবং কোনও মোড়কের প্রয়োজন নেই। আমি নিজেই মোড়ক ব্যবহার করি। কেন তাদের ব্যবহার করা উচিত নয়?

আমরা চাই এটা বলালাইকার মতো সরল হোক। এর মানে হল আপনার বলালাইকা ছাড়া আর কিছুই লাগবে না। আমরা চাই সিস্টেমটি সহজ হোক। আপনার যদি কোনো কার্যকারিতা থাকে যা আপনাকে একটি স্ক্রিপ্টে করতে হবে, তাহলে আসুন এবং আমাদের বলুন - আমরা এটি গো-তে করব৷

শুভ সন্ধ্যা! প্রতিবেদনের জন্য ধন্যবাদ! আমরা GPG ডিক্রিপশনের সাথে কাজ করার জন্য WAL-G পেতে পারিনি। এটি সাধারণত এনক্রিপ্ট করে, কিন্তু ডিক্রিপ্ট করতে চায় না। এটা কি এমন কিছু যা আমাদের জন্য কাজ করেনি? পরিস্থিতি হতাশাজনক।

গিটহাবে একটি সমস্যা তৈরি করুন এবং আসুন এটি বের করি।

অর্থাৎ, আপনি এই সম্মুখীন হননি?

ত্রুটি প্রতিবেদনের একটি বৈশিষ্ট্য রয়েছে যে যখন WAL-G বুঝতে পারে না এটি কি ধরনের ফাইল, তখন এটি জিজ্ঞাসা করে: "সম্ভবত এটি এনক্রিপ্ট করা হয়েছে?" সম্ভবত সমস্যাটি মোটেও এনক্রিপশন নয়। আমি এই বিষয়ে লগিং উন্নত করতে চান. তাকে এটির পাঠোদ্ধার করতে হবে। আমরা বর্তমানে এই বিষয়ে কাজ করছি এই অর্থে যে আমরা সত্যিই পছন্দ করি না যে কীভাবে সর্বজনীন এবং ব্যক্তিগত কী পাওয়ার সিস্টেমটি সংগঠিত হয়। কারণ আমরা বহিরাগত জিপিজিকে কল করি যাতে এটি আমাদের কী দেয়। এবং তারপরে আমরা এই কীগুলি গ্রহণ করি এবং সেগুলিকে অভ্যন্তরীণ জিপিজিতে স্থানান্তর করি, যা খোলা পিজিপি, যা আমাদের জন্য WAL-G-এর মধ্যে সংকলিত হয় এবং সেখানে আমরা এনক্রিপশন বলি। এই বিষয়ে, আমরা সিস্টেমের উন্নতি করতে চাই এবং Libsodium এনক্রিপশন সমর্থন করতে চাই (সংস্করণ 0.2.15 এ যোগ করা হয়েছে)। অবশ্যই, ডিকোডিং কাজ করা উচিত, আসুন এটি বের করা যাক - আপনার কয়েকটি শব্দের চেয়ে একটি লক্ষণের বেশি প্রয়োজন। আপনি কিছু সময় স্পিকারের ঘরে জড়ো হয়ে সিস্টেমটি দেখতে পারেন। (বাহ্যিক GPG ছাড়া PGP এনক্রিপশন - v0.2.9)

হ্যালো! প্রতিবেদনের জন্য ধন্যবাদ! আমার দুটি প্রশ্ন আছে। আমার দুটি প্রোভাইডার pg_basebackup এবং WAL লগ ইন করার একটি অদ্ভুত ইচ্ছা আছে, যেমন আমি একটি ক্লাউড এবং অন্যটি করতে চাই। এই কাজ করতে কিছু উপায় আছে কি?

এটি এখন বিদ্যমান নেই, তবে এটি একটি আকর্ষণীয় ধারণা।

আমি শুধু একটি প্রদানকারীকে বিশ্বাস করি না, আমি অন্যের ক্ষেত্রেও একই রকম থাকতে চাই।

ধারণা আকর্ষণীয়. প্রযুক্তিগতভাবে, এটি বাস্তবায়ন করা মোটেও কঠিন নয়। ধারণাটি হারিয়ে যাওয়া থেকে রক্ষা করার জন্য, আমি কি আপনাকে গিটহাবে একটি সমস্যা তৈরি করতে বলতে পারি?

অবশ্যই হ্যাঁ।

এবং তারপরে, যখন শিক্ষার্থীরা Google Summer of Code-এ আসবে, তখন আমরা তাদের প্রকল্পে যুক্ত করব যাতে তাদের থেকে আরও বেশি কিছু পেতে আরও কাজ হয়।

এবং দ্বিতীয় প্রশ্ন। GitHub এ একটি সমস্যা আছে। আমি মনে করি এটি ইতিমধ্যে বন্ধ আছে. পুনরুদ্ধারের সময় একটি আতঙ্ক আছে। আর একে পরাজিত করার জন্য আপনি আলাদা সমাবেশ করেছেন। এটা সমস্যা সঠিক. এবং একটি থ্রেডে একটি পরিবর্তনশীল পরিবেশ করার বিকল্প রয়েছে। আর সে কারণেই এটি খুব ধীরে কাজ করে। এবং আমরা এই সমস্যার সম্মুখীন হয়েছি, এবং এটি এখনও ঠিক করা হয়নি।

সমস্যা হল কিছু কারণে সঞ্চয়স্থান (CEPH) সংযোগটি পুনরায় সেট করে যখন আমরা এটিতে উচ্চ একযোগে আসি। এই সম্পর্কে কি করা যেতে পারে? পুনরায় চেষ্টা যুক্তি এই মত দেখায়. আমরা আবার ফাইল ডাউনলোড করার চেষ্টা করছি. একটি পাসে, আমাদের কাছে অনেকগুলি ফাইল ডাউনলোড করা হয়নি, যারা লগ ইন করেননি তাদের জন্য আমরা দ্বিতীয়টি তৈরি করব। এবং যতক্ষণ প্রতি পুনরাবৃত্তি অন্তত একটি ফাইল লোড করা হয়, আমরা পুনরাবৃত্তি এবং পুনরাবৃত্তি এবং পুনরাবৃত্তি. আমরা পুনরায় চেষ্টা করার যুক্তি উন্নত করেছি - সূচকীয় ব্যাকঅফ। তবে স্টোরেজ সিস্টেমের পাশে সংযোগটি ভেঙে যাওয়ার কারণে কী করা উচিত তা সম্পূর্ণরূপে পরিষ্কার নয়। অর্থাৎ, যখন আমরা একটি স্ট্রীমে আপলোড করি, এটি এই সংযোগগুলিকে ভেঙে দেয় না। আমরা এখানে কি উন্নতি করতে পারি? আমাদের নেটওয়ার্ক থ্রোটলিং আছে, আমরা প্রতিটি সংযোগকে এটি পাঠানো বাইটের সংখ্যা দ্বারা সীমাবদ্ধ করতে পারি। অন্যথায়, বস্তুর সঞ্চয়স্থান আমাদের সমান্তরালভাবে এটি থেকে ডাউনলোড বা ডাউনলোড করার অনুমতি দেয় না এই বিষয়টির সাথে কীভাবে মোকাবিলা করতে হয় তা আমি জানি না।

SLA নেই? এটা কি তাদের জন্য লেখা নেই কিভাবে তারা নিজেদেরকে কষ্ট পেতে দেয়?

বিন্দু হল যে এই প্রশ্নটি নিয়ে আসা লোকেরা সাধারণত তাদের নিজস্ব ভল্ট থাকে। অর্থাৎ, আমাজন বা গুগল ক্লাউড বা ইয়ানডেক্স অবজেক্ট স্টোরেজ থেকে কেউ আসে না।

হয়তো প্রশ্নটি আর আপনার কাছে নেই?

এই ক্ষেত্রে এখানে প্রশ্ন কার কাছে কোন ব্যাপার নয়। এটির সাথে কীভাবে মোকাবিলা করা যায় সে সম্পর্কে যদি কোনও ধারণা থাকে তবে আসুন এটি WAL-G-এ করি৷ কিন্তু এখন পর্যন্ত আমি এটা কিভাবে মোকাবেলা করতে কোন ভাল ধারণা আছে. কিছু অবজেক্ট স্টোরেজ আছে যা বিভিন্নভাবে তালিকাভুক্ত ব্যাকআপ সমর্থন করে। আপনি তাদের বস্তুর তালিকা করতে বলুন, এবং তারা সেখানে ফোল্ডার যোগ করুন। WAL-G এতে ভয় পায় - এখানে এমন কিছু জিনিস রয়েছে যা একটি ফাইল নয়, আমি এটি পুনরুদ্ধার করতে পারি না, যার অর্থ ব্যাকআপ পুনরুদ্ধার করা হয়নি। অর্থাৎ, প্রকৃতপক্ষে, আপনার কাছে একটি সম্পূর্ণ পুনরুদ্ধার করা ক্লাস্টার রয়েছে, কিন্তু এটি আপনাকে একটি ভুল স্থিতি ফিরিয়ে দেয় কারণ অবজেক্ট স্টোরেজ কিছু অদ্ভুত তথ্য ফিরিয়ে দিয়েছে যা এটি সম্পূর্ণরূপে বুঝতে পারেনি।

এটি এমন একটি জিনিস যা মেল ক্লাউডে ঘটে।

আপনি যদি একটি প্রজনন তৈরি করতে পারেন ...

এটি ধারাবাহিকভাবে পুনরুত্পাদন করা হয়...

যদি একটি পুনরুত্পাদন হয়, তাহলে আমি মনে করি আমরা পুনরায় চেষ্টা করার কৌশলগুলি নিয়ে পরীক্ষা করব এবং কীভাবে পুনরায় চেষ্টা করতে হবে এবং ক্লাউডের আমাদের জন্য কী প্রয়োজন তা বুঝতে হবে। হয়তো এটি তিনটি সংযোগে আমাদের জন্য স্থিতিশীল হবে এবং সংযোগটি ভাঙবে না, তারপর আমরা সাবধানে তিনটিতে পৌঁছাব। কারণ এখন আমরা খুব দ্রুত সংযোগটি বাদ দিই, অর্থাত্ যদি আমরা 16টি থ্রেড সহ একটি পুনরুদ্ধার শুরু করি, তাহলে প্রথম পুনঃপ্রচেষ্টার পরে 8টি থ্রেড, 4টি থ্রেড, 2টি থ্রেড এবং একটি থাকবে। এবং তারপর এটি একটি স্ট্রীম মধ্যে ফাইল টান হবে. যদি কিছু জাদু মান থাকে যেমন 7,5 থ্রেড পাম্প করার জন্য সর্বোত্তম, তবে আমরা সেগুলিকে বিবেচনা করব এবং আরও 7,5 থ্রেড তৈরি করার চেষ্টা করব। এখানে একটি ধারণা আছে.

প্রতিবেদনের জন্য ধন্যবাদ! WAL-G এর সাথে কাজ করার জন্য একটি সম্পূর্ণ ওয়ার্কফ্লো দেখতে কেমন? উদাহরণস্বরূপ, বোকা ক্ষেত্রে যখন পৃষ্ঠা জুড়ে কোন ডেল্টা নেই। এবং আমরা প্রাথমিক ব্যাকআপ গ্রহণ করি এবং সরিয়ে ফেলি, তারপরে শ্যাফ্টটি আর্কাইভ করি যতক্ষণ না আমরা মুখের মধ্যে নীল হয়। এখানে, আমি এটি বুঝতে, একটি ভাঙ্গন আছে. কিছু সময়ে আপনাকে পৃষ্ঠাগুলির একটি ডেল্টা ব্যাকআপ করতে হবে, যেমন কিছু বাহ্যিক প্রক্রিয়া এটি চালাচ্ছে বা এটি কীভাবে ঘটে?

ডেল্টা ব্যাকআপ API বেশ সহজ। সেখানে একটি সংখ্যা আছে – সর্বোচ্চ ডেল্টা ধাপ, একে বলা হয়। এটা শূন্য ডিফল্ট. এর মানে হল যে প্রতিবার আপনি ব্যাকআপ-পুশ করেন, এটি একটি সম্পূর্ণ ব্যাকআপ ডাউনলোড করে। আপনি যদি এটিকে যেকোনো ধনাত্মক সংখ্যায় পরিবর্তন করেন, উদাহরণস্বরূপ, 3, তাহলে পরের বার আপনি যখন ব্যাকআপ-পুশ করেন, এটি পূর্ববর্তী ব্যাকআপগুলির ইতিহাস দেখায়। তিনি দেখেন যে আপনি 3 ডেল্টার চেইন অতিক্রম করবেন না এবং একটি ডেল্টা তৈরি করেন।

অর্থাৎ, যতবার আমরা WAL-G চালু করি, এটি একটি সম্পূর্ণ ব্যাকআপ করার চেষ্টা করে?

না, আমরা WAL-G চালাই, এবং আপনার নীতিগুলি অনুমতি দিলে এটি একটি ডেল্টা তৈরি করার চেষ্টা করে৷

মোটামুটিভাবে বলতে গেলে, আপনি যদি প্রতিবার শূন্য দিয়ে এটি চালান, তাহলে এটি কি pg_basebackup এর মতো আচরণ করবে?

না, এটি এখনও দ্রুত চলবে কারণ এটি কম্প্রেশন এবং সমান্তরালতা ব্যবহার করে। Pg_basebackup আপনার পাশে খাদ রাখবে। WAL-G অনুমান করে যে আপনি সংরক্ষণাগার কনফিগার করেছেন। এবং এটি কনফিগার করা না হলে এটি একটি সতর্কতা জারি করবে।

Pg_basebackup shafts ছাড়া চালানো যাবে.

হ্যাঁ, তারপর তারা প্রায় একই আচরণ করবে। Pg_basebackup ফাইল সিস্টেমে কপি করে। যাইহোক, আমাদের একটি নতুন বৈশিষ্ট্য রয়েছে যা আমি উল্লেখ করতে ভুলে গেছি। আমরা এখন pg_basebackup থেকে ফাইল সিস্টেমে ব্যাকআপ নিতে পারি। আমি জানি না কেন এটি প্রয়োজন, কিন্তু এটি আছে।

উদাহরণস্বরূপ, CephFS এ। সবাই অবজেক্ট স্টোরেজ কনফিগার করতে চায় না।

হ্যাঁ, সম্ভবত এই কারণেই তারা এই বৈশিষ্ট্যটি সম্পর্কে একটি প্রশ্ন জিজ্ঞাসা করেছিল যাতে আমরা এটি করতে পারি। এবং আমরা এটা করেছি.

প্রতিবেদনের জন্য ধন্যবাদ! ফাইল সিস্টেমে অনুলিপি করার বিষয়ে শুধু একটি প্রশ্ন আছে। বাক্সের বাইরে, আপনি কি এখন দূরবর্তী সঞ্চয়স্থানে অনুলিপি করা সমর্থন করেন, উদাহরণস্বরূপ, যদি ডেটা সেন্টারে বা অন্য কিছু থাকে?

এই সূত্রে, এটি একটি কঠিন প্রশ্ন। হ্যাঁ, আমরা সমর্থন করি, কিন্তু এই কার্যকারিতা এখনও কোনো রিলিজে অন্তর্ভুক্ত করা হয়নি। অর্থাৎ, সমস্ত প্রাক-রিলিজ এটি সমর্থন করে, কিন্তু প্রকাশের সংস্করণগুলি তা করে না। এই কার্যকারিতা সংস্করণ 0.2 এ যোগ করা হয়েছে। এটি অবশ্যই শীঘ্রই মুক্তি পাবে, যত তাড়াতাড়ি আমরা সমস্ত পরিচিত বাগগুলি ঠিক করব৷ কিন্তু এই মুহূর্তে এটি শুধুমাত্র প্রাক-মুক্তিতে করা যেতে পারে। প্রি-রিলিজে দুটি বাগ আছে। WAL-E পুনরুদ্ধারের সাথে সমস্যা, আমরা এটি ঠিক করিনি। এবং সর্বশেষ প্রি-রিলিজে ডেল্টা-ব্যাকআপ সম্পর্কে একটি বাগ যোগ করা হয়েছে। অতএব, আমরা সবাইকে রিলিজ সংস্করণ ব্যবহার করার পরামর্শ দিই। যত তাড়াতাড়ি প্রি-রিলিজে আর কোনো বাগ নেই, আমরা বলতে পারি যে আমরা Google ক্লাউড, S3-সামঞ্জস্যপূর্ণ জিনিস এবং ফাইল স্টোরেজ সমর্থন করি।

হ্যালো, প্রতিবেদনের জন্য ধন্যবাদ. আমি এটি বুঝতে পেরেছি, WAL-G বারমেনের মতো এক ধরণের কেন্দ্রীভূত ব্যবস্থা নয়? আপনি কি এই দিকে অগ্রসর হওয়ার পরিকল্পনা করছেন?

সমস্যা হল আমরা এই দিক থেকে দূরে সরে গেছি। WAL-G বেস হোস্টে, ক্লাস্টার হোস্টে এবং ক্লাস্টারের সমস্ত হোস্টে বাস করে। যখন আমরা কয়েক হাজার ক্লাস্টারে চলে যাই, তখন আমাদের অনেক বারটেন্ডার ইনস্টলেশন ছিল। এবং প্রতিবার তাদের মধ্যে কিছু আলাদা হয়ে যায়, এটি একটি বড় সমস্যা। কারণ সেগুলি মেরামত করা দরকার, আপনাকে বুঝতে হবে কোন ক্লাস্টারগুলিতে এখন ব্যাকআপ নেই৷ আমি ব্যাকআপ সিস্টেমের জন্য শারীরিক হার্ডওয়্যারের দিক থেকে WAL-G বিকাশ করার পরিকল্পনা করি না। সম্প্রদায় যদি এখানে কিছু কার্যকারিতা চায়, আমি মোটেও আপত্তি করি না।

আমরা স্টোরেজ জন্য দায়ী যে দল আছে. এবং আমরা খুব ভালো বোধ করি যে এটি আমরা নই, সেখানে বিশেষ ব্যক্তিরা আছেন যারা আমাদের ফাইলগুলি যেখানে ফাইলগুলি নিরাপদ সেখানে রাখেন৷ নির্দিষ্ট সংখ্যক ফাইলের ক্ষতি সহ্য করার জন্য তারা সেখানে সমস্ত ধরণের চতুর কোডিং করে। তারা নেটওয়ার্ক ব্যান্ডউইথের জন্য দায়ী। যখন আপনার বারটেন্ডার থাকে, আপনি হঠাৎ করেই জানতে পারেন যে একই সার্ভারে প্রচুর ট্রাফিক সহ ছোট ডাটাবেস জড়ো হয়েছে। আপনার এটিতে অনেক জায়গা আছে বলে মনে হচ্ছে, কিন্তু কিছু কারণে সবকিছু নেটওয়ার্কের মাধ্যমে মাপসই হয় না। এটা অন্য উপায় কাছাকাছি চালু হতে পারে. সেখানে অনেক নেটওয়ার্ক আছে, প্রসেসর কোর আছে, কিন্তু এখানে কোন ডিস্ক নেই। এবং আমরা কিছু ঘাঁটাঘাঁটি করার এই প্রয়োজনে ক্লান্ত হয়ে পড়েছিলাম, এবং আমরা এই সত্যে চলে এসেছি যে ডেটা স্টোরেজ একটি পৃথক পরিষেবা, যার জন্য পৃথক বিশেষ ব্যক্তিরা দায়ী।

PS একটি নতুন সংস্করণ প্রকাশিত হয়েছে 0.2.15, যেখানে আপনি .walg.json কনফিগারেশন ফাইলটি ব্যবহার করতে পারেন, যা ডিফল্টরূপে postgres হোম ডিরেক্টরিতে অবস্থিত। আপনি ব্যাশ স্ক্রিপ্ট পরিত্যাগ করতে পারেন। উদাহরণ .walg.json এই সংখ্যায় আছে https://github.com/wal-g/wal-g/issues/545

ভিডিও:

উত্স: www.habr.com