ভূমিকা

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

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

ম্যানেজমেন্ট এখন অনুমোদন করেছে MIT লাইসেন্সের অধীনে ওপেন সোর্স সম্প্রদায়ের জন্য একটি প্রকল্প খুলুন. README শীঘ্রই ইংরেজিতে অনুবাদ করা হবে (কারণ Pacemaker এবং PostgreSQL ডেভেলপাররা প্রধান গ্রাহক হবেন বলে আশা করা হচ্ছে), এবং আমি এই নিবন্ধের আকারে README এর পুরানো রাশিয়ান সংস্করণ (আংশিকভাবে) ইস্যু করার সিদ্ধান্ত নিয়েছি।

ভার্চুয়াল মেশিনে ক্লাস্টার স্থাপন করা হয় VirtualBox. মোট, 12টি ভার্চুয়াল মেশিন স্থাপন করা হবে (মোট 36GiB), যা 4টি ফেইলওভার ক্লাস্টার (বিভিন্ন বিকল্প) গঠন করে। প্রথম দুটি ক্লাস্টারে দুটি পোস্টগ্রেএসকিউএল সার্ভার রয়েছে যা বিভিন্ন ডেটা সেন্টারে অবস্থিত এবং একটি সাধারণ সার্ভার। সাক্ষী c কোরাম ডিভাইস (একটি তৃতীয় ডেটা সেন্টারে একটি সস্তা ভার্চুয়াল মেশিনে হোস্ট করা) যা অনিশ্চয়তার সমাধান করে 50% / 50%ভোট দিয়ে তিনটি ডেটা সেন্টারে তৃতীয় ক্লাস্টার: একজন প্রভু, দুই ক্রীতদাস, না কোরাম ডিভাইস. চতুর্থ ক্লাস্টারে চারটি PostgreSQL সার্ভার রয়েছে, প্রতি ডেটা সেন্টারে দুটি: একটি মাস্টার, বাকিগুলি প্রতিলিপি, এবং এটিও ব্যবহার করে সাক্ষী c কোরাম ডিভাইস. চতুর্থটি দুটি সার্ভার বা একটি ডেটা সেন্টারের ব্যর্থতা থেকে বেঁচে থাকে। প্রয়োজনে এই সমাধানটি আরও প্রতিলিপি পর্যন্ত স্কেল করা যেতে পারে।

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

সংস্করণ

v0. ভার্চুয়ালবক্স 7 এ CentOS 11 এবং PostgreSQL 6.1 এর সাথে কাজ করে।

ক্লাস্টার গঠন

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

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

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

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

Tuchanka1 (সংকুচিত স্কিম)

গঠন

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

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

দুটি নোডের ক্ষেত্রে, দোষ সহনশীলতা কেবলমাত্র অ্যাসিঙ্ক্রোনাস প্রতিলিপির সাথেই সম্ভব, যেহেতু সিঙ্ক্রোনাস প্রতিলিপির সাথে, স্লেভের ব্যর্থতা মাস্টারের স্টপের দিকে নিয়ে যাবে।

সাক্ষী দিতে ব্যর্থতা

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

প্রত্যাখ্যান তুচাঙ্কা ১

Tuchanka1 এর জন্য একটি ডেটা সেন্টারের ব্যর্থতা। এক্ষেত্রে সাক্ষী দ্বিতীয় ডেটা সেন্টারে দ্বিতীয় নোডে ভোট দেয়। সেখানে, প্রাক্তন স্লেভ একজন মাস্টারে পরিণত হয়, ফলস্বরূপ, উভয় মাস্টার একই সার্ভারে কাজ করে এবং তাদের উভয় ফ্লোট আইপি তাদের নির্দেশ করে।

Tuchanka2 (ক্লাসিক)

গঠন

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

দুটি নোডের ক্ষেত্রে, দোষ সহনশীলতা কেবলমাত্র অ্যাসিঙ্ক্রোনাস প্রতিলিপির সাথেই সম্ভব, কারণ সিঙ্ক্রোনাস প্রতিলিপির সাথে, স্লেভের ব্যর্থতা মাস্টারের স্টপের দিকে নিয়ে যাবে।

প্রত্যাখ্যান তুচাঙ্কা ১

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

Tuchanka4 (অনেক দাস)

গঠন

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

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

প্রত্যাখ্যান তুচাঙ্কা ১

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

প্রথম জিনিসটি নোট করুন: সমস্ত স্লেভ ফ্লোট আইপি কাজ করবে না, তবে শুধুমাত্র একটি। এবং এটির সাথে সঠিকভাবে কাজ করার জন্য, এটি প্রয়োজনীয় হবে এসকিউএল প্রক্সি শুধুমাত্র অবশিষ্ট ফ্লোট আইপিতে সমস্ত অনুরোধ পুনঃনির্দেশিত করা হয়েছে; এবং যদি এসকিউএল প্রক্সি না, আপনি সংযোগ URL-এ কমা দ্বারা পৃথক করা সমস্ত ফ্লোট আইপি স্লেভ তালিকা করতে পারেন। যে ক্ষেত্রে, সঙ্গে libpq স্বয়ংক্রিয় টেস্টিং সিস্টেমের মতো প্রথম কর্মরত আইপি-তে সংযোগ হবে। সম্ভবত অন্যান্য লাইব্রেরিতে, উদাহরণস্বরূপ, JDBC, এটি কাজ করবে না এবং প্রয়োজনীয় এসকিউএল প্রক্সি. এটি করা হয়েছে কারণ ক্রীতদাসদের জন্য ফ্লোট আইপি একই সাথে একটি সার্ভারে উঠতে নিষেধ করা হয়েছে, যাতে সেগুলি স্লেভ সার্ভারের মধ্যে সমানভাবে বিতরণ করা হয় যদি তাদের মধ্যে বেশ কয়েকটি থাকে।

দ্বিতীয়: এমনকি একটি ডেটা সেন্টার ব্যর্থতার ক্ষেত্রেও, সিঙ্ক্রোনাস প্রতিলিপি বজায় রাখা হবে। এবং এমনকি যদি একটি সেকেন্ডারি ব্যর্থতা ঘটে, অর্থাৎ, দুটি সার্ভারের মধ্যে একটি অবশিষ্ট ডেটা সেন্টারে ব্যর্থ হয়, ক্লাস্টার, যদিও এটি পরিষেবা প্রদান বন্ধ করে দেয়, তবুও সমস্ত প্রতিশ্রুতিবদ্ধ লেনদেন সম্পর্কে তথ্য বজায় রাখবে যার জন্য এটি প্রতিশ্রুতি নিশ্চিত করেছে (সেখানে থাকবে সেকেন্ডারি ব্যর্থতার কোনো ক্ষতির তথ্য থাকবে না)।

Tuchanka3 (3 ডেটা সেন্টার)

গঠন

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

প্রত্যাখ্যান তুচাঙ্কা ১

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

আমি ফাইল কাঠামো এবং স্থাপনার একটি বিশদ বিবরণ অন্তর্ভুক্ত না করার সিদ্ধান্ত নিয়েছি। আপনি যদি আশেপাশে খেলতে চান তবে আপনি README তে এই সমস্ত পড়তে পারেন। আমি শুধুমাত্র স্বয়ংক্রিয় পরীক্ষার একটি বিবরণ দিতে.

স্বয়ংক্রিয় পরীক্ষার সিস্টেম

বিভিন্ন ত্রুটির অনুকরণ সহ ক্লাস্টারগুলির ত্রুটি সহনশীলতা পরীক্ষা করার জন্য, একটি স্বয়ংক্রিয় পরীক্ষার সিস্টেম তৈরি করা হয়েছিল। একটি স্ক্রিপ্ট দ্বারা চালু test/failure. আপনি পরীক্ষা করতে চান এমন ক্লাস্টারের সংখ্যার প্যারামিটার হিসেবে স্ক্রিপ্টটি নিতে পারে। উদাহরণস্বরূপ, এই কমান্ড:

test/failure 2 3

শুধুমাত্র দ্বিতীয় এবং তৃতীয় ক্লাস্টার পরীক্ষা করবে। যদি পরামিতি নির্দিষ্ট করা না থাকে, তাহলে সমস্ত ক্লাস্টার পরীক্ষা করা হবে। সমস্ত ক্লাস্টার সমান্তরালভাবে পরীক্ষা করা হয় এবং ফলাফল tmux প্যানেলে প্রদর্শিত হয়। Tmux একটি ডেডিকেটেড tmux সার্ভার ব্যবহার করে, তাই স্ক্রিপ্টটি ডিফল্ট tmux এর অধীনে থেকে চালানো যেতে পারে, ফলে একটি নেস্টেড tmux হয়। আমি একটি বড় উইন্ডোতে এবং একটি ছোট ফন্ট সহ টার্মিনাল ব্যবহার করার পরামর্শ দিই। পরীক্ষা শুরু করার আগে, স্ক্রিপ্ট শেষ হওয়ার সময়ে সমস্ত ভার্চুয়াল মেশিন একটি স্ন্যাপশটে ফিরিয়ে আনা হয় setup.

টার্মিনালটি পরীক্ষিত ক্লাস্টারের সংখ্যা অনুসারে কলামে বিভক্ত, ডিফল্টরূপে (স্ক্রিনশটে) তাদের মধ্যে চারটি রয়েছে। আমি উদাহরণ হিসেবে Tuchanka2 ব্যবহার করে কলামের বিষয়বস্তু বর্ণনা করব। স্ক্রিনশটের প্যানেলগুলি সংখ্যাযুক্ত:

1. এখানেই পরীক্ষার পরিসংখ্যান প্রদর্শিত হয়। বক্তা:
   • ব্যর্থতা — পরীক্ষার নাম (স্ক্রিপ্টে ফাংশন) যা ব্যর্থতাকে অনুকরণ করে।
   • প্রতিক্রিয়া — পাটিগণিতের গড় সময় সেকেন্ডে যার জন্য ক্লাস্টারটি তার কর্মক্ষমতা পুনরুদ্ধার করেছে। এটি স্ক্রিপ্টের শুরু থেকে পরিমাপ করা হয় যা ব্যর্থতার অনুকরণ করে এবং সেই মুহূর্ত পর্যন্ত যখন ক্লাস্টারটি তার স্বাস্থ্য পুনরুদ্ধার করে এবং পরিষেবা প্রদান চালিয়ে যেতে সক্ষম হয়। যদি সময় খুব কম হয়, উদাহরণস্বরূপ, ছয় সেকেন্ড (এটি বেশ কয়েকটি স্লেভের সাথে ক্লাস্টারে ঘটে (Tuchanka3 এবং Tuchanka4)), এর মানে হল যে ত্রুটিটি একটি অ্যাসিঙ্ক্রোনাস স্লেভের উপর শেষ হয়েছিল এবং কোনওভাবেই কর্মক্ষমতাকে প্রভাবিত করেনি, সেখানে কোনও ছিল না। ক্লাস্টার রাষ্ট্র সুইচ.
   • চ্যুতি - মানের বিস্তার (নির্ভুলতা) দেখায় প্রতিক্রিয়া আদর্শ বিচ্যুতি পদ্ধতি দ্বারা।
   • গণনা কতবার এই পরীক্ষা করা হয়েছে।
2. একটি সংক্ষিপ্ত লগ আপনাকে ক্লাস্টার বর্তমানে কি করছে তা মূল্যায়ন করতে দেয়। পুনরাবৃত্তি (পরীক্ষা) নম্বর, টাইমস্ট্যাম্প এবং অপারেশন নাম প্রদর্শিত হয়। খুব দীর্ঘ এক্সিকিউশন (> 5 মিনিট) কোনো ধরনের সমস্যা নির্দেশ করে।
3. হৃদয় (হৃদয়) বর্তমান সময়। চাক্ষুষ কর্মক্ষমতা মূল্যায়ন জন্য মনিব বর্তমান সময় ক্রমাগত মাস্টারের ফ্লোট আইপি ব্যবহার করে তার টেবিলে লেখা হয়। সফল হলে, ফলাফল এই প্যানেলে প্রদর্শিত হবে।
4. বীট (নাড়ি) - "বর্তমান সময়", যা আগে স্ক্রিপ্ট দ্বারা রেকর্ড করা হয়েছিল হৃদয় মাস্টার করতে, এখন থেকে পড়ুন ক্রীতদাস এর ফ্লোট আইপির মাধ্যমে। আপনি চাক্ষুষরূপে একটি স্লেভ এবং প্রতিলিপি কর্মক্ষমতা মূল্যায়ন করার অনুমতি দেয়. Tuchanka1 এ ফ্লোট আইপি সহ কোন স্লেভ নেই (সেখানে কোন স্লেভ নেই যা পরিষেবা প্রদান করে), তবে দুটি উদাহরণ (DB) আছে, তাই এটি এখানে দেখানো হবে না বীটএবং হৃদয় দ্বিতীয় উদাহরণ
5. ইউটিলিটি ব্যবহার করে ক্লাস্টারের অবস্থা পর্যবেক্ষণ করা pcs mon. গঠন, নোড এবং অন্যান্য দরকারী তথ্য দ্বারা সম্পদ বিতরণ দেখায়.
6. এটি প্রতিটি ক্লাস্টার ভার্চুয়াল মেশিন থেকে সিস্টেম পর্যবেক্ষণ প্রদর্শন করে। এই ধরনের আরও প্যানেল থাকতে পারে - ক্লাস্টারে কতগুলি ভার্চুয়াল মেশিন রয়েছে। দুটি গ্রাফ CPU লোড (ভার্চুয়াল মেশিনে দুটি প্রসেসর), ভার্চুয়াল মেশিনের নাম, সিস্টেম লোড (লোড গড় নামকরণ করা হয়েছে কারণ এটির গড় 5, 10 এবং 15 মিনিটের বেশি), প্রসেস ডেটা এবং মেমরি বরাদ্দ।
7. স্ক্রিপ্ট ট্রেসিং যা পরীক্ষা করে। একটি ত্রুটির ঘটনা - কাজের হঠাৎ বাধা বা একটি অন্তহীন অপেক্ষা চক্র - এখানে আপনি এই আচরণের কারণ দেখতে পারেন।

পরীক্ষা দুটি পর্যায়ে বাহিত হয়। প্রথমত, স্ক্রিপ্টটি সব ধরনের পরীক্ষার মধ্য দিয়ে যায়, এলোমেলোভাবে একটি ভার্চুয়াল মেশিন বেছে নেয় যেখানে এই পরীক্ষাটি প্রয়োগ করা উচিত। তারপরে একটি অন্তহীন পরীক্ষার চক্র সঞ্চালিত হয়, ভার্চুয়াল মেশিন এবং একটি ত্রুটি প্রতিবার এলোমেলোভাবে নির্বাচন করা হয়। পরীক্ষার স্ক্রিপ্টের হঠাৎ সমাপ্তি (নীচের প্যানেল) বা কিছুর জন্য একটি অন্তহীন অপেক্ষার লুপ (> 5 মিনিট সময় একটি অপারেশন সম্পূর্ণ করতে, এটি ট্রেসে দেখা যায়) নির্দেশ করে যে এই ক্লাস্টারের কিছু পরীক্ষা ব্যর্থ হয়েছে।

প্রতিটি পরীক্ষা নিম্নলিখিত অপারেশন নিয়ে গঠিত:

1. একটি ফাংশন শুরু করা যা একটি ফল্ট অনুকরণ করে৷
2. প্রস্তুত? - ক্লাস্টারের স্বাস্থ্য পুনরুদ্ধারের জন্য অপেক্ষা করছে (যখন সমস্ত পরিষেবা প্রদান করা হয়)।
3. ক্লাস্টার পুনরুদ্ধারের সময়সীমা দেখানো হয়েছে (প্রতিক্রিয়া).
4. ঠিক করা - ক্লাস্টারটি "মেরামত" করা হয়েছে। এর পরে এটি সম্পূর্ণরূপে কার্যকরী অবস্থায় ফিরে আসা উচিত এবং পরবর্তী ত্রুটির জন্য প্রস্তুত হওয়া উচিত।

তারা কী করে তার বিবরণ সহ এখানে পরীক্ষার একটি তালিকা রয়েছে:

• ফর্কবোম: একটি কাঁটাচামচ বোমা দিয়ে "আউট অফ মেমরি" তৈরি করে।
• স্থান: হার্ড ড্রাইভ পূর্ণ। কিন্তু পরীক্ষাটি বরং প্রতীকী, পরীক্ষার সময় তৈরি করা তুচ্ছ লোড সহ, যখন হার্ড ড্রাইভ ওভারফ্লো হয়, PostgreSQL সাধারণত ব্যর্থ হয় না।
• পোস্টগ্রেস-কিল: কমান্ড দিয়ে PostgreSQL হত্যা করে killall -KILL postgres.
• পোস্টগ্রেস-স্টপ: কমান্ডের সাথে PostgreSQL হ্যাং করে killall -STOP postgres.
• যন্ত্র বন্ধ: কমান্ডের সাহায্যে ভার্চুয়াল মেশিনকে "ডি-এনার্জিস" করে VBoxManage controlvm "виртуалка" poweroff.
• রিসেট: কমান্ড দিয়ে ভার্চুয়াল মেশিন পুনরায় লোড করে VBoxManage controlvm "виртуалка" reset.
• এসবিডি স্টপ: কমান্ড দিয়ে SBD ডেমন সাসপেন্ড করে killall -STOP sbd.
• শাটডাউন: SSH এর মাধ্যমে ভার্চুয়াল মেশিনে একটি কমান্ড পাঠায় systemctl poweroff, সিস্টেম gracefully বন্ধ.
• আনলিঙ্ক: নেটওয়ার্ক বিচ্ছিন্নতা, কমান্ড VBoxManage controlvm "виртуалка" setlinkstate1 off.

স্ট্যান্ডার্ড tmux কমান্ড "কিল-উইন্ডো" দিয়ে পরীক্ষা শেষ করুন ctrl-b&, অথবা কমান্ড দ্বারা "detach-client" ctrl-bd: একই সময়ে, পরীক্ষা সম্পন্ন হয়, tmux বন্ধ, ভার্চুয়াল মেশিন বন্ধ করা হয়।

পরীক্ষার সময় চিহ্নিত সমস্যা

• এই মুহুর্তে ওয়াচডগ ডেমন এসবিডি পর্যবেক্ষিত ডেমনগুলিকে থামানো পরিচালনা করে, কিন্তু সেগুলিকে হিমায়িত করে না। এবং, ফলস্বরূপ, ত্রুটিগুলি ভুলভাবে কাজ করা হয়, যার ফলে শুধুমাত্র একটি হিমায়িত হয় কোরোসিঙ্ক и পেসমেকার, কিন্তু ঝুলন্ত না sbd... চেকের জন্য কোরোসিঙ্ক ইতিমধ্যে আছে পিআর#83 (এতে গিটহাবে sbd)শাখায় গৃহীত মালিক. তারা প্রতিশ্রুতি দিয়েছিল (PR#83) যে পেসমেকারের জন্যও একই রকম কিছু হবে, আমি আশা করি এর মধ্যেই রেডহ্যাট 8 করব. কিন্তু এই ধরনের "ব্যর্থতা" অনুমানমূলক, সহজেই কৃত্রিমভাবে ব্যবহার করে অনুকরণ করা হয়, উদাহরণস্বরূপ, killall -STOP corosyncকিন্তু বাস্তব জীবনে দেখা হয় না।

• У পেসমেকার জন্য সংস্করণ CentOS 7 ভুলভাবে সেট করা সিঙ্ক_টাইমআউট у কোরাম ডিভাইস, ফলস্বরূপ যদি একটি নোড ব্যর্থ হয়, দ্বিতীয় নোডটি কিছু সম্ভাবনার সাথে পুনরায় বুট হয়, যা মাস্টার সরানো অনুমিত ছিল. বিবর্ধন দ্বারা নিরাময় সিঙ্ক_টাইমআউট у কোরাম ডিভাইস স্থাপনার সময় (স্ক্রিপ্টে setup/setup1) এই সংশোধনী ডেভেলপারদের দ্বারা গৃহীত হয়নি পেসমেকার, পরিবর্তে তারা পরিকাঠামোকে এমনভাবে (কিছু অনির্দিষ্ট ভবিষ্যতে) পুনরায় কাজ করার প্রতিশ্রুতি দিয়েছে যাতে এই সময়সীমা স্বয়ংক্রিয়ভাবে গণনা করা হয়।

• যদি আপনি ডাটাবেস কনফিগারেশনের সময় উল্লেখ করেন যে LC_MESSAGES (টেক্সট বার্তা) ইউনিকোড ব্যবহার করা যেতে পারে, উদাহরণস্বরূপ, ru_RU.UTF-8, তারপর স্টার্টআপে postgres একটি পরিবেশে যেখানে লোকেলটি UTF-8 নয়, বলুন, একটি খালি পরিবেশে (এখানে পেসমেকার+pgsqlms(paf) শুরু হয় postgres) তারপর লগে UTF-8 অক্ষরের পরিবর্তে প্রশ্নবোধক চিহ্ন থাকবে. PostgreSQL ডেভেলপাররা এই ক্ষেত্রে কি করতে হবে তা নিয়ে সম্মত হননি। এটা খরচ, আপনি লাগাতে হবে LC_MESSAGES=en_US.UTF-8 একটি ডিবি উদাহরণ কনফিগার করার সময় (তৈরি করা)।

• যদি wal_receiver_timeout সেট করা থাকে (ডিফল্টরূপে এটি 60s), তাহলে tuchanka3 এবং tuchanka4 ক্লাস্টারে মাস্টারে PostgreSQL-STOP পরীক্ষা করার সময় প্রতিলিপি একটি নতুন মাস্টারের সাথে পুনরায় সংযোগ করে না. সেখানে প্রতিলিপি সিঙ্ক্রোনাস, তাই শুধু স্লেভই থেমে যায় না, নতুন প্রভুও। PostgreSQL কনফিগার করার সময় wal_receiver_timeout=0 সেট করে পাওয়া যায়।

• আমি মাঝে মাঝে ForkBomb পরীক্ষায় (মেমরি ওভারফ্লো) ঝুলন্ত PostgreSQL প্রতিলিপি পর্যবেক্ষণ করেছি। ForkBomb পরে, কখনও কখনও ক্রীতদাসরা নতুন মাস্টারের সাথে পুনরায় সংযোগ করতে পারে না. আমি এটি শুধুমাত্র tuchanka3 এবং tuchanka4 ক্লাস্টারে দেখেছি, যেখানে প্রতিলিপিটি সিঙ্ক্রোনাস হওয়ার কারণে, মাস্টারটি হ্যাং হয়েছে৷ কিছু দীর্ঘ সময় (প্রায় দুই ঘন্টা) পরে সমস্যাটি নিজেই চলে গেল। এটি ঠিক করার জন্য আরও গবেষণা প্রয়োজন। উপসর্গ পূর্ববর্তী বাগ অনুরূপ, যা একটি ভিন্ন কারণে সৃষ্ট, কিন্তু একই পরিণতি সঙ্গে।

ক্রোগান থেকে তোলা ছবি deviant আর্ট লেখকের অনুমতি নিয়ে:

উত্স: www.habr.com