Patroni ব্যর্থতার গল্প বা কিভাবে আপনার PostgreSQL ক্লাস্টার ক্র্যাশ করবেন। আলেক্সি লেসভস্কি

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

আমি আপনাকে আমার সম্পর্কে একটু বলব. আমি একটি সিস্টেম প্রশাসক হিসাবে শুরু. ওয়েব ডেভেলপমেন্টে কাজ করেছেন। আমি 2014 সাল থেকে Data Egret এ কাজ করছি। কোম্পানি Postgres ক্ষেত্রে পরামর্শ নিযুক্ত করা হয়. এবং আমরা ঠিক পোস্টগ্রেস পরিবেশন করি, এবং আমরা প্রতিদিন পোস্টগ্রেসের সাথে কাজ করি, তাই আমাদের অপারেশন সম্পর্কিত বিভিন্ন দক্ষতা রয়েছে।

এবং 2018 এর শেষে, আমরা ধীরে ধীরে Patroni ব্যবহার করতে শুরু করি। আর কিছু অভিজ্ঞতা সঞ্চিত হয়েছে। আমরা একরকম এটি নির্ণয় করেছি, এটি টিউন করেছি, আমাদের সেরা অনুশীলনে এসেছি। আর তাদের নিয়েই কথা বলব এই প্রতিবেদনে।

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

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

• প্যাট্রোনি কীভাবে ইনস্টল করবেন তা আমি আপনাকে বলব না, কারণ আপনি ইন্টারনেটে গুগল করতে পারেন, এটি কীভাবে শুরু হয়, এটি কীভাবে কনফিগার করা হয় তা বোঝার জন্য আপনি কনফিগারেশন ফাইলগুলি দেখতে পারেন। আপনি স্কিম, আর্কিটেকচার বুঝতে পারেন, ইন্টারনেটে এটি সম্পর্কে তথ্য খুঁজে পেতে পারেন।
• আমি অন্য কারো অভিজ্ঞতার কথা বলব না। আমি কেবল আমরা যে সমস্যার মুখোমুখি হয়েছিলাম সে সম্পর্কে কথা বলব।
• এবং আমি Patroni এবং PostgreSQL এর বাইরের সমস্যাগুলি নিয়ে কথা বলব না। যদি, উদাহরণস্বরূপ, ভারসাম্যের সাথে সম্পর্কিত সমস্যা থাকে, যখন আমাদের ক্লাস্টারটি ভেঙে যায়, আমি এটি সম্পর্কে কথা বলব না।

এবং আমরা আমাদের প্রতিবেদন শুরু করার আগে একটি ছোট দাবিত্যাগ।

এই সমস্ত সমস্যা যে আমরা সম্মুখীন হয়েছিলাম, আমরা অপারেশনের প্রথম 6-7-8 মাসে সেগুলি পেয়েছি। সময়ের সাথে সাথে, আমরা আমাদের অভ্যন্তরীণ সেরা অনুশীলনে এসেছি। এবং আমাদের সমস্যাগুলি অদৃশ্য হয়ে গেল। অতএব, প্রতিবেদনটি প্রায় ছয় মাস আগে ঘোষণা করা হয়েছিল, যখন এটি আমার মাথায় তাজা ছিল এবং আমি এটি পুরোপুরি মনে রেখেছিলাম।

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

Patroni কি?

• এটি HA নির্মাণের জন্য একটি টেমপ্লেট। ডকুমেন্টেশনে সেটাই বলা হয়েছে। এবং আমার দৃষ্টিকোণ থেকে, এটি একটি খুব সঠিক ব্যাখ্যা। Patroni একটি রূপালী বুলেট নয় যা আপনার সমস্ত সমস্যার সমাধান করবে, অর্থাৎ, এটিকে কার্যকর করতে এবং সুবিধাগুলি আনার জন্য আপনাকে প্রচেষ্টা করতে হবে।
• এটি একটি এজেন্ট পরিষেবা যা প্রতিটি ডাটাবেস পরিষেবাতে ইনস্টল করা থাকে এবং এটি আপনার পোস্টগ্রেসের জন্য এক ধরনের init সিস্টেম। এটি পোস্টগ্রেস শুরু করে, বন্ধ করে, পুনরায় চালু করে, পুনরায় কনফিগার করে এবং আপনার ক্লাস্টারের টপোলজি পরিবর্তন করে।
• তদনুসারে, ক্লাস্টারের অবস্থা সংরক্ষণ করার জন্য, এর বর্তমান উপস্থাপনা, যেমনটি দেখায়, কিছু ধরণের স্টোরেজ প্রয়োজন। এবং এই দৃষ্টিকোণ থেকে, পৃষ্ঠপোষক একটি বহিরাগত সিস্টেমে রাষ্ট্র সংরক্ষণের পথ গ্রহণ করেন। এটি একটি বিতরণকৃত কনফিগারেশন স্টোরেজ সিস্টেম। এটি হতে পারে Etcd, Consul, ZooKeeper, অথবা kubernetes Etcd, অর্থাৎ এই বিকল্পগুলির মধ্যে একটি।
• এবং Patroni এর একটি বৈশিষ্ট্য হল যে আপনি অটোফাইলারটিকে বক্সের বাইরে নিয়ে যান, শুধুমাত্র এটি সেট আপ করার মাধ্যমে। যদি আমরা তুলনার জন্য Repmgr নিই, তাহলে ফাইলার সেখানে অন্তর্ভুক্ত করা হয়। Repmgr এর সাথে, আমরা একটি সুইচওভার পাই, কিন্তু যদি আমরা একটি অটোফাইলার চাই, তাহলে আমাদের এটি অতিরিক্তভাবে কনফিগার করতে হবে। Patroni ইতিমধ্যে বাক্সের বাইরে একটি অটোফাইলার আছে.
• এবং আরও অনেক কিছু আছে। উদাহরণস্বরূপ, কনফিগারেশনের রক্ষণাবেক্ষণ, নতুন প্রতিলিপি ঢালা, ব্যাকআপ ইত্যাদি। তবে এটি প্রতিবেদনের সুযোগের বাইরে, আমি এটি সম্পর্কে কথা বলব না।

এবং একটি ছোট ফলাফল হল Patroni-এর প্রধান কাজ হল একটি অটোফাইল ভাল এবং নির্ভরযোগ্যভাবে করা যাতে আমাদের ক্লাস্টার চালু থাকে এবং অ্যাপ্লিকেশনটি ক্লাস্টার টপোলজিতে পরিবর্তন লক্ষ্য না করে।

কিন্তু যখন আমরা Patroni ব্যবহার শুরু করি, তখন আমাদের সিস্টেম একটু বেশি জটিল হয়ে যায়। যদি আগে আমাদের পোস্টগ্রেস থাকে, তাহলে Patroni ব্যবহার করার সময় আমরা Patroni নিজেই পাই, আমরা DCS পাই যেখানে রাজ্য সংরক্ষিত থাকে। এবং এটা সব একরকম কাজ আছে. তাই কি ভুল হতে পারে?

ভেঙ্গে যেতে পারে:

• পোস্টগ্রেস ভেঙ্গে যেতে পারে। এটি একটি মাস্টার বা একটি প্রতিরূপ হতে পারে, তাদের মধ্যে একটি ব্যর্থ হতে পারে।
• পাত্রী নিজেই ভেঙ্গে যেতে পারে।
• DCS যেখানে স্টেট সংরক্ষিত আছে তা ভেঙে যেতে পারে।
• এবং নেটওয়ার্ক ভেঙ্গে যেতে পারে।

এই সব পয়েন্ট আমি রিপোর্ট বিবেচনা করা হবে.

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

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

সুতরাং, একটি ফাইলার ছিল, চলুন কি ঘটেছে মোকাবেলা করতে যান.

এবং এখানে আমরা আগ্রহী যখন ফাইলার ঘটেছে. অর্থাৎ, ক্লাস্টার স্টেট পরিবর্তিত হওয়ার সময়ে আমরা এই মুহূর্তে আগ্রহী।

কিন্তু ফাইলার সবসময় তাত্ক্ষণিক হয় না, অর্থাৎ এটি সময়ের কোনো একক নেয় না, এটি বিলম্বিত হতে পারে। এটি দীর্ঘস্থায়ী হতে পারে।

অতএব, এটির একটি শুরুর সময় এবং একটি শেষ সময় রয়েছে, অর্থাৎ এটি একটি ধারাবাহিক ঘটনা। এবং আমরা সমস্ত ইভেন্টকে তিনটি ব্যবধানে ভাগ করি: আমাদের কাছে ফাইলারের আগে, ফাইলারের সময় এবং ফাইলারের পরে সময় আছে। অর্থাৎ, আমরা এই টাইমলাইনে সমস্ত ঘটনা বিবেচনা করি।

এবং প্রথম জিনিস, যখন একটি ফাইলার ঘটেছে, আমরা কি ঘটেছে তার কারণ অনুসন্ধান, ফাইলার নেতৃত্বে কি কারণ ছিল.

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

এর পরে, আমাদের বুঝতে হবে কেন ফাইলারটি ঘটেছে, অর্থাত্ কোন ঘটনা ঘটেছে যার ফলে মাস্টার রোল এক নোড থেকে অন্য নোডে চলে গেছে। এবং এই ক্ষেত্রে, সবকিছু সহজ। স্টোরেজ সিস্টেমের সাথে ইন্টারঅ্যাক্ট করার সময় আমাদের একটি ত্রুটি আছে। মাস্টার বুঝতে পেরেছিলেন যে তিনি ডিসিএসের সাথে কাজ করতে পারবেন না, অর্থাৎ মিথস্ক্রিয়ায় একধরনের সমস্যা ছিল। এবং তিনি বলেছেন যে তিনি আর মাস্টার হতে পারবেন না এবং পদত্যাগ করেছেন। এই লাইন "নিম্নতিত স্ব" ঠিক তাই বলে.

যদি আমরা ফাইলারের পূর্ববর্তী ঘটনাগুলি দেখি, আমরা সেখানে সেই কারণগুলি দেখতে পাব যা উইজার্ডটি চালিয়ে যেতে সমস্যা সৃষ্টি করেছে।

আমরা যদি Patroni লগগুলি দেখি, আমরা দেখতে পাব যে আমাদের অনেক ত্রুটি, টাইমআউট, অর্থাৎ Patroni এজেন্ট DCS এর সাথে কাজ করতে পারে না। এই ক্ষেত্রে, এটি কনসাল এজেন্ট, যা পোর্ট 8500 এ যোগাযোগ করছে।

এবং এখানে সমস্যা হল Patroni এবং ডাটাবেস একই হোস্টে চলছে। এবং কনসাল সার্ভারগুলি একই নোডে চালু হয়েছিল। সার্ভারে একটি লোড তৈরি করে, আমরা কনসাল সার্ভারগুলির জন্যও সমস্যা তৈরি করেছি। তারা ঠিকমতো যোগাযোগ করতে পারেনি।

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

এবং এটি একটি মিথ্যা শঙ্কা হিসাবে গণ্য করা যেতে পারে, বা এটি বিবেচনা করা যেতে পারে যে Patroni সবকিছু ঠিকঠাক করেছে। অর্থাৎ, তিনি বুঝতে পেরেছিলেন যে তিনি ক্লাস্টারের অবস্থা বজায় রাখতে পারবেন না এবং তার কর্তৃত্ব সরিয়ে ফেললেন।

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

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

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

প্রথম সমস্যা, যেমন আপনি বুঝতে, সহজ. আমরা বেস সহ ডিসিএস নিয়েছি এবং রেখেছি, আমরা একটি সমস্যা পেয়েছি।

দ্বিতীয় সমস্যাটি প্রথমটির মতোই। এটি একই রকম যে আমাদের আবার ডিসিএস সিস্টেমের সাথে ইন্টারঅপারেবিলিটি সমস্যা রয়েছে।

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

পুরানো মাস্টার একটি প্রতিরূপ হয়ে ওঠে, এখানে Patroni কাজ আউট, এটি হওয়া উচিত. এটি লেনদেন লগ রিওয়াইন্ড করতে pg_rewind চালায় এবং তারপরে নতুন মাস্টারের সাথে যোগাযোগ করতে নতুন মাস্টারের সাথে সংযোগ করুন৷ এখানে Patroni কাজ করে, যেমন তার উচিত।

এখানে আমাদের অবশ্যই ফাইলারের পূর্ববর্তী স্থানটি খুঁজে বের করতে হবে, অর্থাৎ সেই ত্রুটিগুলি যা আমাদের একটি ফাইলার তৈরি করেছে। এবং এই বিষয়ে, Patroni লগ সঙ্গে কাজ করার জন্য বেশ সুবিধাজনক। তিনি একটি নির্দিষ্ট ব্যবধানে একই বার্তা লেখেন। এবং যদি আমরা এই লগগুলি দ্রুত স্ক্রোল করা শুরু করি, তাহলে আমরা লগগুলি থেকে দেখতে পাব যে লগগুলি পরিবর্তন হয়েছে, যার মানে কিছু সমস্যা শুরু হয়েছে। আমরা দ্রুত এই জায়গায় ফিরে যাই, দেখি কি হয়।

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

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

মোটামুটিভাবে ফাইলারের সময় এবং কনসাল লগের সময় তুলনা করলে, আমরা দেখতে পাই যে কনসাল ক্লাস্টারে আমাদের প্রতিবেশীরা কনসাল ক্লাস্টারের অন্যান্য সদস্যদের অস্তিত্ব নিয়ে সন্দেহ করতে শুরু করে।

এবং আপনি যদি অন্যান্য কনসাল এজেন্টদের লগগুলি দেখেন তবে আপনি এটিও দেখতে পাবেন যে সেখানে এক ধরণের নেটওয়ার্ক পতন চলছে। এবং কনসাল ক্লাস্টারের সকল সদস্য একে অপরের অস্তিত্ব নিয়ে সন্দেহ করে। এবং এটি ফাইলারের জন্য প্রেরণা ছিল।

আপনি যদি এই ত্রুটিগুলির আগে কী ঘটেছিল তা দেখেন, আপনি দেখতে পাবেন যে সমস্ত ধরণের ত্রুটি রয়েছে, উদাহরণস্বরূপ, সময়সীমা, আরপিসি পড়ে গেছে, অর্থাৎ, কনসাল ক্লাস্টার সদস্যদের একে অপরের সাথে মিথস্ক্রিয়ায় স্পষ্টতই এক ধরণের সমস্যা রয়েছে। .

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

বিকল্প আছে:

• সবচেয়ে সহজ বিকল্প, যা লেখা আছে, আমার মতে, এমনকি ডকুমেন্টেশনেও, কনসাল চেকগুলি অক্ষম করা, অর্থাৎ, কেবল একটি খালি অ্যারে পাস করা। এবং আমরা কনসাল এজেন্টকে বলি কোনো চেক ব্যবহার না করতে। এই চেকগুলির মাধ্যমে, আমরা এই নেটওয়ার্ক ঝড় উপেক্ষা করতে পারি এবং একটি ফাইলার শুরু করতে পারি না।
• আরেকটি বিকল্প হল রাফ্ট_মাল্টিপ্লায়ারকে ডাবল চেক করা। এটি কনসাল সার্ভারের একটি প্যারামিটার। ডিফল্টরূপে, এটি 5 এ সেট করা হয়। স্টেজিং পরিবেশের জন্য ডকুমেন্টেশন দ্বারা এই মানটি সুপারিশ করা হয়। প্রকৃতপক্ষে, এটি কনসাল নেটওয়ার্কের সদস্যদের মধ্যে বার্তা পাঠানোর ফ্রিকোয়েন্সিকে প্রভাবিত করে। আসলে, এই প্যারামিটারটি কনসাল ক্লাস্টারের সদস্যদের মধ্যে পরিষেবা যোগাযোগের গতিকে প্রভাবিত করে। এবং উত্পাদনের জন্য, এটি ইতিমধ্যেই এটি হ্রাস করার পরামর্শ দেওয়া হচ্ছে যাতে নোডগুলি আরও প্রায়ই বার্তা বিনিময় করে।
• অন্য একটি বিকল্প যা আমরা নিয়ে এসেছি তা হল অপারেটিং সিস্টেমের প্রক্রিয়া নির্ধারণকারীর অন্যান্য প্রক্রিয়াগুলির মধ্যে কনসাল প্রক্রিয়াগুলির অগ্রাধিকার বাড়ানো। এমন একটি "সুন্দর" পরামিতি রয়েছে, এটি কেবলমাত্র প্রক্রিয়াগুলির অগ্রাধিকার নির্ধারণ করে যা সময়সূচী করার সময় ওএস শিডিউলারের দ্বারা বিবেচনা করা হয়। আমরা কনসাল এজেন্টদের জন্য চমৎকার মানও কমিয়েছি, যেমন অগ্রাধিকার বৃদ্ধি করেছে যাতে অপারেটিং সিস্টেম কনসাল প্রক্রিয়াগুলিকে কাজ করতে এবং তাদের কোড কার্যকর করতে আরও সময় দেয়। আমাদের ক্ষেত্রে, এটি আমাদের সমস্যার সমাধান করেছে।
• আরেকটি বিকল্প হল কনসাল ব্যবহার না করা। আমার একজন বন্ধু আছে যে Etcd এর বড় সমর্থক। এবং আমরা নিয়মিত তার সাথে তর্ক করি কোনটা ভালো Etcd বা কনসাল। কিন্তু কোনটির ক্ষেত্রে ভাল, আমরা সাধারণত তার সাথে একমত যে কনসালের একটি এজেন্ট রয়েছে যা একটি ডাটাবেস সহ প্রতিটি নোডে চলতে হবে। অর্থাৎ, কনসাল ক্লাস্টারের সাথে Patroni এর মিথস্ক্রিয়া এই এজেন্টের মাধ্যমে যায়। এবং এই এজেন্ট একটি বাধা হয়ে ওঠে. যদি এজেন্টের কিছু হয়, তাহলে Patroni আর কনসাল ক্লাস্টারের সাথে কাজ করতে পারবে না। এবং এই সমস্যা। Etcd প্ল্যানে কোন এজেন্ট নেই। Patroni Etcd সার্ভারের একটি তালিকার সাথে সরাসরি কাজ করতে পারে এবং ইতিমধ্যে তাদের সাথে যোগাযোগ করতে পারে। এই বিষয়ে, আপনি যদি আপনার কোম্পানিতে Etcd ব্যবহার করেন, তাহলে Etcd সম্ভবত কনসালের চেয়ে ভাল পছন্দ হবে। কিন্তু আমরা আমাদের গ্রাহকদের সবসময় ক্লায়েন্ট যা বেছে নিয়েছে এবং ব্যবহার করেছে তার দ্বারা সীমাবদ্ধ। এবং আমাদের কাছে বেশিরভাগ ক্লায়েন্টদের জন্য কনসাল রয়েছে।
• এবং শেষ বিন্দু পরামিতি মান সংশোধন করা হয়. আমরা এই প্যারামিটারগুলিকে এই আশায় বাড়াতে পারি যে আমাদের স্বল্প-মেয়াদী নেটওয়ার্ক সমস্যাগুলি ছোট হবে এবং এই প্যারামিটারগুলির সীমার বাইরে পড়বে না। এইভাবে কিছু নেটওয়ার্ক সমস্যা দেখা দিলে আমরা অটোফাইলের জন্য Patroni-এর আগ্রাসীতা কমাতে পারি।

আমি মনে করি যারা Patroni ব্যবহার করেন তারা অনেকেই এই কমান্ডের সাথে পরিচিত।

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

তদনুসারে, একটি অটোফাইল ছিল। এবং এই অটোফাইলের পরে, আমাদের প্রতিরূপ অদৃশ্য হয়ে গেছে। কেন তিনি অদৃশ্য হয়ে গেলেন তা আমাদের খুঁজে বের করতে হবে এবং তাকে ফিরিয়ে আনতে হবে, তাকে পুনরুদ্ধার করতে হবে। এবং আমরা আবার লগগুলিতে যাই এবং দেখি কেন আমাদের একটি অটো-ফাইলওভার ছিল।

এই ক্ষেত্রে, দ্বিতীয় প্রতিরূপ মাস্টার হয়ে ওঠে। এখানে সব ঠিক আছে.

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

এই ক্ষেত্রে, আমাদের একটি লেনদেন লগ নেই এবং প্রতিলিপি শুরু করতে পারে না। তদনুসারে, আমরা একটি ত্রুটি সহ পোস্টগ্রেস বন্ধ করি। এবং তাই এটি ক্লাস্টারে নেই।

আমাদের বুঝতে হবে কেন এটি ক্লাস্টারে নেই এবং কেন কোনও লগ ছিল না। আমরা নতুন মাস্টারের কাছে যাই এবং তার লগগুলিতে কী আছে তা দেখি। দেখা যাচ্ছে যে যখন pg_rewind করা হয়েছিল, একটি চেকপয়েন্ট ঘটেছে। এবং কিছু পুরানো লেনদেনের লগের নাম পরিবর্তন করা হয়েছে। যখন পুরানো মাস্টার নতুন মাস্টারের সাথে সংযোগ করার চেষ্টা করেছিল এবং এই লগগুলি জিজ্ঞাসা করেছিল, তখন সেগুলি ইতিমধ্যেই পুনঃনামকরণ করা হয়েছিল, সেগুলি বিদ্যমান ছিল না৷

আমি টাইমস্ট্যাম্প তুলনা করেছি যখন এই ঘটনাগুলো ঘটেছে। এবং সেখানে পার্থক্যটি আক্ষরিক অর্থে 150 মিলিসেকেন্ড, অর্থাৎ, চেকপয়েন্টটি 369 মিলিসেকেন্ডে সম্পন্ন হয়েছে, WAL বিভাগগুলির নাম পরিবর্তন করা হয়েছে। এবং আক্ষরিক অর্থে 517 সালে, 150 মিলিসেকেন্ডের পরে, পুরানো প্রতিলিপিতে রিওয়াইন্ড শুরু হয়েছিল। অর্থাৎ, আক্ষরিক অর্থে 150 মিলিসেকেন্ড আমাদের জন্য যথেষ্ট ছিল যাতে প্রতিরূপটি সংযোগ করতে এবং উপার্জন করতে পারে না।

বিকল্প কি?

আমরা প্রাথমিকভাবে প্রতিলিপি স্লট ব্যবহার করেছি। আমরা ভেবেছিলাম এটা ভালো। যদিও অপারেশনের প্রথম পর্যায়ে আমরা স্লটগুলি বন্ধ করে দিয়েছি। আমাদের কাছে মনে হয়েছিল যে স্লটগুলি যদি অনেকগুলি WAL সেগমেন্ট জমা করে তবে আমরা মাস্টারকে বাদ দিতে পারি। সে পড়ে যাবে। আমরা স্লট ছাড়া কিছু সময়ের জন্য ভোগা. এবং আমরা বুঝতে পেরেছি যে আমাদের স্লট দরকার, আমরা স্লটগুলি ফিরিয়ে দিয়েছি।

কিন্তু এখানে একটি সমস্যা আছে, যখন মাস্টার রেপ্লিকাতে যায়, তখন এটি স্লটগুলি মুছে দেয় এবং স্লটগুলির সাথে WAL সেগমেন্টগুলি মুছে ফেলে। এবং এই সমস্যা দূর করার জন্য, আমরা wal_keep_segments প্যারামিটার বাড়ানোর সিদ্ধান্ত নিয়েছি। এটি 8টি সেগমেন্টে ডিফল্ট। আমরা এটিকে 1-এ উন্নীত করেছি এবং আমাদের কতটা ফাঁকা জায়গা আছে তা দেখেছি। এবং আমরা ওয়াল_কিপ_সেগমেন্টের জন্য 000 গিগাবাইট দান করেছি। অর্থাৎ, স্যুইচ করার সময়, আমাদের কাছে সব নোডে সর্বদা 16 গিগাবাইট লেনদেন লগের রিজার্ভ থাকে।

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

আমরা একটি উত্পাদন ভিত্তি আছে. ইতিমধ্যে প্রজেক্ট চলছে।

একজন ফাইলার ছিল। আমরা ভিতরে গিয়ে দেখলাম - সবকিছু ঠিকঠাক আছে, প্রতিলিপিগুলো ঠিক আছে, কোনো প্রতিলিপির ব্যবধান নেই। লগগুলিতে কোনও ত্রুটি নেই, সবকিছু ঠিক আছে।

পণ্য দল বলে যে কিছু ডেটা থাকা উচিত, তবে আমরা এটি একটি উত্স থেকে দেখি, তবে আমরা এটি ডাটাবেসে দেখতে পাই না। এবং তাদের কি ঘটেছে তা আমাদের বুঝতে হবে।

এটা স্পষ্ট যে pg_rewind তাদের মিস করেছে। আমরা সঙ্গে সঙ্গে এটা বুঝতে পেরেছি, কিন্তু কি ঘটছে দেখতে গিয়েছিলাম.

লগগুলিতে, আমরা সর্বদা খুঁজে পেতে পারি যে ফাইলার কখন ঘটেছিল, কে মাস্টার হয়েছিলেন এবং আমরা নির্ধারণ করতে পারি কে পুরানো মাস্টার এবং কখন তিনি একটি প্রতিরূপ হতে চেয়েছিলেন, অর্থাৎ লেনদেনের লগের পরিমাণ খুঁজে বের করার জন্য আমাদের এই লগগুলির প্রয়োজন। হারিয়ে ছিল.

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

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

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

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

কিন্তু আমরা নিজেদের জন্য কি খুঁজে পেয়েছি?

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

এবং এর পরেই আমাদের সিদ্ধান্ত নিতে হবে যে আমরা এই ডেটাটি বাতিল করতে পারি বা আমরা এটি পুনরুদ্ধার করতে পারি, এই নোডটিকে আমাদের ক্লাস্টারে একটি প্রতিরূপ হিসাবে সংযুক্ত করতে পারি।

এছাড়াও, একটি "সর্বোচ্চ_ল্যাগ_অন_ফেইলওভার" প্যারামিটার রয়েছে। ডিফল্টরূপে, যদি আমার মেমরি আমাকে পরিবেশন করে, এই প্যারামিটারটির মান 1 মেগাবাইট থাকে।

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

কিন্তু একটি সমস্যা আছে যে প্যাট্রোনি ক্লাস্টার এবং ডিসিএস-এ প্রতিলিপিকরণ ল্যাগ একটি নির্দিষ্ট ব্যবধানে আপডেট করা হয়। আমি মনে করি 30 সেকেন্ড ডিফল্ট ttl মান।

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

আর ক্ষতির আশঙ্কা সব সময়ই থেকে যায়। এবং সবচেয়ে খারাপ ক্ষেত্রে, একটি সূত্র, এবং গড় ক্ষেত্রে, অন্য সূত্র। অর্থাৎ, যখন আমরা Patroni বাস্তবায়নের পরিকল্পনা করি এবং মূল্যায়ন করি যে আমরা কতটা ডেটা হারাতে পারি, আমাদের অবশ্যই এই সূত্রগুলির উপর নির্ভর করতে হবে এবং মোটামুটিভাবে কল্পনা করতে হবে যে আমরা কতটা ডেটা হারাতে পারি।

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

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

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

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

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

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

আমরা সিস্টেম dmesg (কার্নেল লগ) এ দেখেছি। এবং আমরা দেখেছি যে আমাদের একটি ডিস্কের সাথে সমস্যা রয়েছে। ডিস্ক সাবসিস্টেম ছিল সফটওয়্যার রেইড। আমরা /proc/mdstat দেখেছি এবং দেখেছি যে আমরা একটি ড্রাইভ হারিয়েছি। অর্থাৎ, 8টি ডিস্কের একটি রেইড আছে, আমরা একটি মিস করছি। আপনি যদি স্লাইডটি মনোযোগ সহকারে দেখেন তবে আউটপুটে আপনি দেখতে পাবেন যে আমাদের সেখানে sde নেই। আমাদের কাছে, শর্তসাপেক্ষে বলতে গেলে, ডিস্কটি বাদ পড়েছে। এটি ডিস্কের সমস্যা শুরু করে এবং পোস্টগ্রেস ক্লাস্টারের সাথে কাজ করার সময় অ্যাপ্লিকেশনগুলিও সমস্যার সম্মুখীন হয়।

এবং এই ক্ষেত্রে, Patroni আমাদের কোন ভাবেই সাহায্য করবে না, কারণ Patroni এর সার্ভারের অবস্থা, ডিস্কের অবস্থা পর্যবেক্ষণ করার কাজ নেই। এবং আমাদের অবশ্যই বাহ্যিক পর্যবেক্ষণের মাধ্যমে এই জাতীয় পরিস্থিতি পর্যবেক্ষণ করতে হবে। আমরা দ্রুত বাহ্যিক পর্যবেক্ষণে ডিস্ক পর্যবেক্ষণ যোগ করেছি।

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

আমার মতে, এটি একটি অদ্ভুত সমস্যা যা আমি খুব দীর্ঘ সময়ের জন্য গবেষণা করেছি, আমি প্রচুর লগ পড়েছি, পুনরায় বাছাই করেছি এবং এটিকে একটি ক্লাস্টার সিমুলেটর বলেছি।

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

এবং কিভাবে এটি সব শুরু হয়েছিল? এটি ডিস্ক ব্রেক দিয়ে আগের সমস্যার মতোই শুরু হয়েছিল। আমরা একটি সেকেন্ড, দুই জন্য প্রতিশ্রুতি ছিল.

সংযোগে বিচ্ছেদ ছিল, অর্থাৎ ক্লায়েন্টদের ছিঁড়ে ফেলা হয়েছিল।

বিভিন্ন তীব্রতার ব্লকেজ ছিল.

এবং, সেই অনুযায়ী, ডিস্ক সাবসিস্টেম খুব প্রতিক্রিয়াশীল নয়।

এবং আমার জন্য সবচেয়ে রহস্যজনক জিনিস হল অবিলম্বে শাটডাউন অনুরোধ যা এসেছে। Postgres তিনটি শাটডাউন মোড আছে:

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

কে এই সংকেত পাঠিয়েছে? পোস্টগ্রেস ব্যাকগ্রাউন্ড প্রসেস একে অপরের কাছে এই ধরনের সংকেত পাঠায় না, অর্থাৎ এটি হল kill-9। তারা একে অপরের কাছে এই জাতীয় জিনিস পাঠায় না, তারা কেবল এই জাতীয় জিনিসগুলিতে প্রতিক্রিয়া জানায়, যেমন এটি পোস্টগ্রেসের একটি জরুরি পুনঃসূচনা। কে পাঠিয়েছে, জানি না।

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

আরও তাকিয়ে দেখলাম যে পাত্রোনি লগে লেখেননি অনেক দিন - ৫৪ সেকেন্ড। এবং যদি আমরা দুটি টাইমস্ট্যাম্প তুলনা করি, প্রায় 54 সেকেন্ডের জন্য কোন বার্তা ছিল না।

এবং এই সময়ে একটি অটোফাইল ছিল. Patroni এখানে আবার একটি মহান কাজ করেছেন. আমাদের পুরানো মাস্টার অনুপলব্ধ ছিল, তার কিছু ঘটেছে. আর শুরু হলো নতুন প্রভুর নির্বাচন। সবকিছু এখানে ভাল কাজ করেছে. আমাদের pgsql01 নতুন নেতা হয়ে উঠেছে।

আমাদের একটা রেপ্লিকা আছে যেটা মাস্টার হয়ে গেছে। এবং একটি দ্বিতীয় প্রতিক্রিয়া আছে. এবং দ্বিতীয় রেপ্লিকা নিয়ে সমস্যা ছিল। তিনি পুনরায় কনফিগার করার চেষ্টা করেছিলেন। আমি এটি বুঝতে পেরেছি, তিনি recovery.conf পরিবর্তন করার, পোস্টগ্রেস পুনরায় চালু করার এবং নতুন মাস্টারের সাথে সংযোগ করার চেষ্টা করেছেন। তিনি প্রতি 10 সেকেন্ডে বার্তা লেখেন যে তিনি চেষ্টা করছেন, কিন্তু তিনি সফল হচ্ছেন না।

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

কিছু সময়ে, এটি কাজ করেছে, কিন্তু প্রতিলিপি শুরু হয়নি।

আমার একমাত্র অনুমান হল যে recovery.conf এ একটি পুরানো মাস্টার ঠিকানা ছিল। এবং যখন একটি নতুন মাস্টার হাজির, দ্বিতীয় প্রতিরূপটি এখনও পুরানো মাস্টারের সাথে সংযোগ করার চেষ্টা করেছিল।

Patroni যখন দ্বিতীয় প্রতিলিপিতে শুরু করে, নোডটি শুরু হয়েছিল কিন্তু প্রতিলিপি করতে পারেনি। এবং একটি প্রতিলিপি ল্যাগ গঠিত হয়েছিল, যা দেখতে এরকম কিছু ছিল। অর্থাৎ, তিনটি নোডই জায়গায় ছিল, কিন্তু দ্বিতীয় নোডটি পিছিয়ে ছিল।

একই সময়ে, আপনি যদি লিখিত লগগুলি দেখেন তবে আপনি দেখতে পাবেন যে প্রতিলিপি শুরু করা যায়নি কারণ লেনদেনের লগগুলি আলাদা ছিল। এবং সেই লেনদেন লগগুলি যেগুলি মাস্টার অফার করে, যেগুলি recovery.conf-এ নির্দিষ্ট করা আছে, কেবল আমাদের বর্তমান নোডের সাথে খাপ খায় না৷

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

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

প্রতিলিপি শুরু হয়েছে। কিন্তু এক মিনিট পরে, তিনি একটি ত্রুটির সাথে পড়ে যান যে লেনদেনের লগগুলি তার জন্য উপযুক্ত নয়৷

আমি ভেবেছিলাম আমি আবার শুরু করব। আমি Patroni আবার চালু করেছি, এবং আমি Postgres রিস্টার্ট করিনি, কিন্তু Patroni রিস্টার্ট করেছি এই আশায় যে এটি ডাটাবেসটি জাদুকরীভাবে শুরু করবে।

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

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

আমি Patroni রিস্টার্ট করলাম, মাস্টারে কয়েকটা চেকপয়েন্ট করলাম, রেপ্লিকা খোলার পর কয়েকটা রিস্টার্ট পয়েন্ট করলাম। এবং এটা সাহায্য করেছে. আমি দীর্ঘ সময়ের জন্য ভেবেছিলাম কেন এটি সাহায্য করেছে এবং এটি কীভাবে কাজ করে। আর রেপ্লিকা শুরু হল। এবং প্রতিলিপি আর ছেড়া ছিল না.

আমার জন্য এই জাতীয় সমস্যাটি আরও রহস্যময়গুলির মধ্যে একটি, যার উপরে আমি এখনও সেখানে কী ঘটেছিল তা নিয়ে ধাঁধাঁ দিয়ে যাচ্ছি।

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

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

এবং আমরা এই সমস্যাগুলির মধ্য দিয়ে যাওয়ার সাথে সাথে আমি সুপারিশ করব। আমি তাদের দুটি স্লাইডে একত্রিত করার চেষ্টা করেছি। সম্ভবত, সমস্ত গল্প দুটি স্লাইডে একত্রিত করা যেতে পারে এবং শুধুমাত্র বলা যেতে পারে।

আপনি যখন Patroni ব্যবহার করেন, আপনার অবশ্যই নজরদারি থাকতে হবে। একটি অটোফাইলওভার কখন ঘটেছিল তা আপনার সর্বদা জানা উচিত, কারণ আপনি যদি না জানেন যে আপনার একটি অটোফাইলওভার ছিল, তবে ক্লাস্টারের উপর আপনার কোনও নিয়ন্ত্রণ নেই। এবং এটা খারাপ.

প্রতিটি ফাইলারের পরে, আমাদের সর্বদা ম্যানুয়ালি ক্লাস্টারটি পরীক্ষা করতে হবে। আমাদের নিশ্চিত করতে হবে যে আমাদের কাছে সবসময় প্রতিলিপিগুলির একটি আপ-টু-ডেট সংখ্যা রয়েছে, কোনও প্রতিলিপি ল্যাগ নেই, স্ট্রিমিং প্রতিলিপি সম্পর্কিত লগগুলিতে কোনও ত্রুটি নেই, Patroni-এর সাথে, DCS সিস্টেমের সাথে।

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

আর পাত্রোনি সিলভার বুলেট নয়। পোস্টগ্রেস কীভাবে কাজ করে, কীভাবে প্রতিলিপি কাজ করে এবং প্যাট্রোনি পোস্টগ্রেসের সাথে কীভাবে কাজ করে এবং কীভাবে নোডের মধ্যে যোগাযোগ সরবরাহ করা হয় তা আমাদের এখনও বুঝতে হবে। আপনার হাত দিয়ে সমস্যা ঠিক করতে সক্ষম হওয়ার জন্য এটি প্রয়োজনীয়।

আমি কিভাবে রোগ নির্ণয়ের ইস্যুতে যোগাযোগ করব? এটি তাই ঘটেছে যে আমরা বিভিন্ন ক্লায়েন্টের সাথে কাজ করি এবং কারও কাছে ELK স্ট্যাক নেই, এবং আমাদের 6টি কনসোল এবং 2টি ট্যাব খোলার মাধ্যমে লগগুলি সাজাতে হবে৷ একটি ট্যাবে, এগুলি প্রতিটি নোডের জন্য প্যাট্রোনি লগ, অন্য ট্যাবে, এগুলি হল কনসাল লগ, বা প্রয়োজনে পোস্টগ্রেস৷ এটা নির্ণয় করা খুবই কঠিন।

আমি কি পন্থা গ্রহণ করেছি? প্রথমত, আমি সবসময় দেখি কখন ফাইলার এসেছে। এবং আমার জন্য এটি একটি জলাবদ্ধতা. ফাইলারের আগে, ফিলারের সময় এবং ফিলারের পরে কী হয়েছিল তা আমি দেখি। ফাইলওভারে দুটি চিহ্ন রয়েছে: এটি শুরু এবং শেষের সময়।

এর পরে, আমি ফাইলারের আগে ইভেন্টগুলির জন্য লগগুলি দেখি, যা ফাইলারের আগে ছিল, অর্থাত্ ফাইলারটি কেন ঘটেছে তার কারণগুলি আমি সন্ধান করি৷

এবং এটি কী ঘটেছে এবং ভবিষ্যতে কী করা যেতে পারে তা বোঝার একটি চিত্র দেয় যাতে এই জাতীয় পরিস্থিতি না ঘটে (এবং ফলস্বরূপ, কোনও ফাইলার নেই)।

এবং আমরা সাধারণত কোথায় তাকান? আমি দেখি:

• প্রথমত, Patroni লগ.
• এর পরে, Patroni লগগুলিতে যা পাওয়া গেছে তার উপর নির্ভর করে আমি Postgres লগগুলি বা DCS লগগুলি দেখি৷
• এবং সিস্টেম লগগুলিও কখনও কখনও ফাইলারটির কারণ সম্পর্কে একটি বোঝা দেয়।

Patroni সম্পর্কে আমার কেমন লাগছে? পাত্রনির সঙ্গে আমার খুব ভালো সম্পর্ক। আমার মতে, এটিই আজকের সেরা। আমি আরো অনেক পণ্য জানি. এগুলো হল Stolon, Repmgr, Pg_auto_failover, PAF। 4 টুল। আমি তাদের সব চেষ্টা. Patroni আমার প্রিয়.

যদি তারা আমাকে জিজ্ঞাসা করে: "আমি কি Patroni সুপারিশ করি?"। আমি হ্যাঁ বলব, কারণ আমি পাত্রনিকে পছন্দ করি। এবং আমি মনে করি আমি এটা কিভাবে রান্না করতে শিখেছি.

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

মানুষের পায়ে গুলি চালানোর কিছু মজার গল্প আছে। খুবই তথ্যবহুল. আপনি পড়ে বুঝতে পারেন যে এটি করার দরকার নেই। আমি নিজেই টিক দিলাম।

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

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

এখানেই শেষ. যদি আপনার কোন প্রশ্ন থাকে, তাহলে জিজ্ঞাসা করুন।

প্রশ্ন

প্রতিবেদনের জন্য ধন্যবাদ! যদি একটি ফাইলারের পরেও আপনাকে সেখানে খুব সাবধানে দেখতে হয়, তাহলে আমাদের কেন একটি স্বয়ংক্রিয় ফাইলার দরকার?

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

উদাহরণস্বরূপ, আমরা সকালে গিয়ে দেখেছি, তাই না?

সকালে নয়, আমরা সাধারণত অটোফাইল সম্পর্কে প্রায় সঙ্গে সঙ্গেই শিখি। আমরা বিজ্ঞপ্তি পাই, আমরা দেখতে পাই যে একটি অটোফাইল ঘটেছে। আমরা প্রায় সঙ্গে সঙ্গে গিয়ে দেখি। কিন্তু এই সব চেক মনিটরিং পর্যায়ে আনা উচিত। আপনি যদি REST API এর মাধ্যমে Patroni অ্যাক্সেস করেন তবে একটি ইতিহাস রয়েছে। ইতিহাস দ্বারা আপনি ফাইলার কখন ঘটেছে টাইমস্ট্যাম্প দেখতে পারেন। এর ভিত্তিতে মনিটরিং করা যেতে পারে। আপনি ইতিহাস দেখতে পারেন, কত ঘটনা ছিল. যদি আমাদের আরও ইভেন্ট থাকে, তাহলে একটি অটোফাইল ঘটেছে। গিয়ে দেখতে পারেন। অথবা আমাদের মনিটরিং অটোমেশন চেক করেছে যে আমাদের কাছে সমস্ত প্রতিলিপি রয়েছে, কোনও ব্যবধান নেই এবং সবকিছু ঠিক আছে।

ধন্যবাদ!

মহান গল্পের জন্য অনেক ধন্যবাদ! আমরা যদি ডিসিএস ক্লাস্টারটিকে পোস্টগ্রেস ক্লাস্টার থেকে দূরে কোথাও স্থানান্তরিত করি, তবে এই ক্লাস্টারটিও পর্যায়ক্রমে পরিষেবা করা দরকার? DCS ক্লাস্টারের কিছু অংশ বন্ধ করা, তাদের সাথে কিছু করা ইত্যাদির জন্য সেরা অনুশীলনগুলি কী কী? কিভাবে এই পুরো কাঠামো টিকে আছে? এবং আপনি এই জিনিস কিভাবে করবেন?

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

অর্থাৎ, আমি কি সঠিকভাবে বুঝতে পেরেছি যে হোস্টদের সাথে কিছু করার আগে আমাকে Patroni নিষ্ক্রিয় করতে হবে, ফাইলারকে নিষ্ক্রিয় করতে হবে, সবকিছু নিষ্ক্রিয় করতে হবে?

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

আপনাকে অনেক ধন্যবাদ!

আপনার প্রতিবেদনের জন্য আপনাকে অনেক ধন্যবাদ! ডেটা হারিয়ে যাওয়া সম্পর্কে পণ্য দল কেমন অনুভব করে?

প্রোডাক্ট টিম পাত্তা দেয় না, এবং টিম লিড চিন্তিত।

কি গ্যারান্টি আছে?

গ্যারান্টি খুব কঠিন। আলেকজান্ডার কুকুশকিনের একটি প্রতিবেদন রয়েছে "কীভাবে আরপিও এবং আরটিও গণনা করা যায়", অর্থাত্ পুনরুদ্ধারের সময় এবং আমরা কত ডেটা হারাতে পারি। আমি মনে করি আমাদের এই স্লাইডগুলি খুঁজে বের করা এবং সেগুলি অধ্যয়ন করা দরকার। যতদূর আমার মনে আছে, এই জিনিসগুলি কীভাবে গণনা করা যায় তার নির্দিষ্ট পদক্ষেপ রয়েছে। আমরা কত লেনদেন হারাতে পারি, কত ডেটা হারাতে পারি। একটি বিকল্প হিসাবে, আমরা Patroni স্তরে সিঙ্ক্রোনাস প্রতিলিপি ব্যবহার করতে পারি, কিন্তু এটি একটি দ্বি-ধারী তরোয়াল: আমাদের হয় ডেটা নির্ভরযোগ্যতা আছে, অথবা আমরা গতি হারাতে পারি। সিঙ্ক্রোনাস প্রতিলিপি আছে, তবে এটি ডেটা ক্ষতির বিরুদ্ধে 100% সুরক্ষার গ্যারান্টি দেয় না।

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

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

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

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

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

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

মোটামুটিভাবে বলতে গেলে, ডিসিএস আমাদের জন্য বেসের মতো গুরুত্বপূর্ণ একটি পরিষেবা হয়ে ওঠে?

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

ধন্যবাদ!

উত্স: www.habr.com