ফেইলওভার ক্লাস্টার PostgreSQL + Patroni. বাস্তবায়ন অভিজ্ঞতা

নিবন্ধে আমি আপনাকে বলব কিভাবে আমরা PostgreSQL ফল্ট টলারেন্স ইস্যুতে যোগাযোগ করেছি, কেন এটি আমাদের জন্য গুরুত্বপূর্ণ হয়ে উঠেছে এবং শেষ পর্যন্ত কী ঘটেছে।

আমাদের একটি অত্যন্ত লোড পরিষেবা রয়েছে: বিশ্বব্যাপী 2,5 মিলিয়ন ব্যবহারকারী, প্রতিদিন 50K+ সক্রিয় ব্যবহারকারী। সার্ভারগুলি আয়ারল্যান্ডের একটি অঞ্চলে আমাজোনে অবস্থিত: 100+ বিভিন্ন সার্ভার ক্রমাগত কাজ করছে, যার মধ্যে প্রায় 50টি ডাটাবেসের সাথে রয়েছে।

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

কেন আমরা Redis থেকে PostgreSQL এ স্যুইচ করেছি

প্রাথমিকভাবে, আমাদের পরিষেবা Redis-এর সাথে কাজ করেছিল, একটি মূল-মূল্যের দোকান যা সার্ভারের RAM-এ সমস্ত ডেটা সঞ্চয় করে৷

রেডিসের সুবিধা:

1. উচ্চ প্রতিক্রিয়া গতি, কারণ সবকিছু মেমরিতে সংরক্ষণ করা হয়;
2. ব্যাকআপ এবং প্রতিলিপি সহজ.

আমাদের জন্য Redis এর অসুবিধা:

1. কোন বাস্তব লেনদেন আছে. আমরা আমাদের অ্যাপ্লিকেশনের স্তরে তাদের অনুকরণ করার চেষ্টা করেছি। দুর্ভাগ্যবশত, এটি সবসময় ভাল কাজ করে না এবং খুব জটিল কোড লেখার প্রয়োজন হয়।
2. ডেটার পরিমাণ মেমরির পরিমাণ দ্বারা সীমিত। ডেটার পরিমাণ যত বাড়বে, মেমরি বাড়বে, এবং শেষ পর্যন্ত, আমরা নির্বাচিত দৃষ্টান্তের বৈশিষ্ট্যগুলিতে চলে যাব, যা AWS-এ দৃষ্টান্তের ধরণ পরিবর্তন করতে আমাদের পরিষেবা বন্ধ করতে হবে৷
3. এটা ক্রমাগত একটি কম লেটেন্সি স্তর বজায় রাখা প্রয়োজন, কারণ. আমরা অনুরোধ একটি খুব বড় সংখ্যা আছে. আমাদের জন্য সর্বোত্তম বিলম্বের স্তর হল 17-20 ms। 30-40 ms এর স্তরে, আমরা আমাদের আবেদন থেকে অনুরোধের দীর্ঘ প্রতিক্রিয়া এবং পরিষেবার অবনতি পাই। দুর্ভাগ্যবশত, এটি আমাদের সাথে 2018 সালের সেপ্টেম্বরে ঘটেছিল, যখন Redis-এর সাথে একটি ঘটনা স্বাভাবিকের চেয়ে 2 গুণ বেশি লেটেন্সি পেয়েছে। সমস্যা সমাধানের জন্য, আমরা অনির্ধারিত রক্ষণাবেক্ষণের জন্য মিড-ডে পরিষেবা বন্ধ করে দিয়েছি এবং সমস্যাযুক্ত রেডিস উদাহরণ প্রতিস্থাপন করেছি।
4. কোডে ছোটখাটো ত্রুটি থাকলেও ডেটার অসঙ্গতি পাওয়া সহজ এবং তারপর এই ডেটা সংশোধন করতে কোড লেখার জন্য অনেক সময় ব্যয় করা।

আমরা অসুবিধাগুলি বিবেচনায় নিয়েছি এবং বুঝতে পেরেছি যে আমাদের স্বাভাবিক লেনদেন এবং বিলম্বের উপর কম নির্ভরতা সহ আরও সুবিধাজনক কিছুতে যেতে হবে। গবেষণা পরিচালনা করেছেন, অনেক বিকল্প বিশ্লেষণ করেছেন এবং PostgreSQL বেছে নিয়েছেন।

আমরা ইতিমধ্যেই 1,5 বছর ধরে একটি নতুন ডাটাবেসে চলে এসেছি এবং ডেটার একটি ছোট অংশই স্থানান্তরিত করেছি, তাই এখন আমরা Redis এবং PostgreSQL এর সাথে একযোগে কাজ করছি। ডাটাবেসের মধ্যে ডেটা স্থানান্তর এবং স্যুইচ করার পর্যায় সম্পর্কে আরও তথ্য লেখা আছে আমার সহকর্মীর নিবন্ধ.

যখন আমরা প্রথম সরানো শুরু করি, আমাদের অ্যাপ্লিকেশন সরাসরি ডাটাবেসের সাথে কাজ করে এবং মাস্টার রেডিস এবং PostgreSQL অ্যাক্সেস করেছিল। PostgreSQL ক্লাস্টারে একটি মাস্টার এবং অ্যাসিঙ্ক্রোনাস প্রতিলিপি সহ একটি প্রতিরূপ রয়েছে। ডাটাবেস স্কিমটি দেখতে এইরকম:

PgBouncer বাস্তবায়ন করা হচ্ছে

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

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

আমরা নিম্নলিখিত কাজের স্কিম সেট আপ করেছি: আমাদের অ্যাপ্লিকেশন একটি PgBouncer অ্যাক্সেস করে, যার পিছনে পোস্টগ্রেএসকিউএল মাস্টার রয়েছে এবং প্রতিটি মাস্টারের পিছনে অ্যাসিঙ্ক্রোনাস প্রতিলিপি সহ একটি প্রতিলিপি রয়েছে।


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

PgBouncer ফেইলওভার

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

এর পরে, আমরা PgBouncer এবং PostgreSQL ক্লাস্টারগুলির ত্রুটি সহনশীলতা সম্পর্কে গুরুত্ব সহকারে চিন্তা করেছি, কারণ আমাদের AWS অ্যাকাউন্টে যে কোনও উদাহরণে একই রকম পরিস্থিতি ঘটতে পারে।

আমরা নিম্নরূপ PgBouncer ফল্ট টলারেন্স স্কিম তৈরি করেছি: সমস্ত অ্যাপ্লিকেশন সার্ভার নেটওয়ার্ক লোড ব্যালেন্সার অ্যাক্সেস করে, যার পিছনে দুটি পিজিবাউন্সার রয়েছে। প্রতিটি PgBouncer প্রতিটি শার্ডের একই PostgreSQL মাস্টারের দিকে তাকায়। যদি একটি AWS দৃষ্টান্ত ক্র্যাশ আবার ঘটে, সমস্ত ট্র্যাফিক অন্য PgBouncer এর মাধ্যমে পুনঃনির্দেশিত হয়। নেটওয়ার্ক লোড ব্যালেন্সার ফেইলওভার AWS দ্বারা প্রদান করা হয়।

এই স্কিমটি নতুন PgBouncer সার্ভার যোগ করা সহজ করে তোলে।

একটি PostgreSQL ফেইলওভার ক্লাস্টার তৈরি করুন

এই সমস্যাটি সমাধান করার সময়, আমরা বিভিন্ন বিকল্প বিবেচনা করেছি: স্ব-লিখিত ব্যর্থতা, repmgr, AWS RDS, Patroni।

স্ব-লিখিত স্ক্রিপ্ট

তারা মাস্টারের কাজ নিরীক্ষণ করতে পারে এবং যদি এটি ব্যর্থ হয়, তাহলে প্রতিরূপটিকে মাস্টারের কাছে প্রচার করতে পারে এবং PgBouncer কনফিগারেশন আপডেট করতে পারে।

এই পদ্ধতির সুবিধাগুলি সর্বাধিক সরলতা, কারণ আপনি নিজেই স্ক্রিপ্টগুলি লেখেন এবং ঠিক কীভাবে কাজ করে তা বুঝতে পারেন।

কনস:

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

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

Repmgr

PostgreSQL ক্লাস্টারগুলির জন্য প্রতিলিপি ব্যবস্থাপক, যা একটি PostgreSQL ক্লাস্টারের অপারেশন পরিচালনা করতে পারে। একই সময়ে, এটির বাক্সের বাইরে একটি স্বয়ংক্রিয় ব্যর্থতা নেই, তাই কাজের জন্য আপনাকে সমাপ্ত সমাধানের উপরে আপনার নিজের "র্যাপার" লিখতে হবে। তাই সবকিছু স্ব-লিখিত স্ক্রিপ্টের চেয়ে আরও জটিল হতে পারে, তাই আমরা Repmgr চেষ্টাও করিনি।

AWS RDS

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

অসুবিধার মধ্যে রয়েছে সূক্ষ্ম সমন্বয়ের অভাব। সূক্ষ্ম টিউনিংয়ের উদাহরণ হিসাবে: আমাদের উদাহরণগুলিতে tcp সংযোগের জন্য বিধিনিষেধ রয়েছে, যা দুর্ভাগ্যবশত, RDS-এ করা যায় না:

net.ipv4.tcp_keepalive_time=10
net.ipv4.tcp_keepalive_intvl=1
net.ipv4.tcp_keepalive_probes=5
net.ipv4.tcp_retries2=3

উপরন্তু, AWS RDS নিয়মিত দৃষ্টান্ত মূল্যের তুলনায় প্রায় দ্বিগুণ ব্যয়বহুল, যা এই সমাধানটি পরিত্যাগ করার প্রধান কারণ ছিল।

পৃষ্ঠপোষক

ভাল ডকুমেন্টেশন, স্বয়ংক্রিয় ব্যর্থতা এবং গিথুবে সোর্স কোড সহ PostgreSQL পরিচালনার জন্য এটি একটি পাইথন টেমপ্লেট।

Patroni এর সুবিধা:

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

কনস:

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

ফলস্বরূপ, আমরা একটি ফেইলওভার ক্লাস্টার তৈরি করতে Patroni বেছে নিয়েছি।

পৃষ্ঠপোষকতা বাস্তবায়ন প্রক্রিয়া

Patroni এর আগে, আমাদের কাছে একটি মাস্টারের কনফিগারেশনে 12টি PostgreSQL শার্ড এবং অ্যাসিঙ্ক্রোনাস প্রতিলিপি সহ একটি প্রতিলিপি ছিল। অ্যাপ্লিকেশন সার্ভারগুলি নেটওয়ার্ক লোড ব্যালেন্সারের মাধ্যমে ডেটাবেসগুলি অ্যাক্সেস করেছিল, যার পিছনে দুটি উদাহরণ ছিল PgBouncer, এবং তাদের পিছনে সমস্ত PostgreSQL সার্ভার ছিল৷


Patroni বাস্তবায়ন করতে, আমাদের একটি বিতরণ করা স্টোরেজ ক্লাস্টার কনফিগারেশন নির্বাচন করতে হবে। Patroni বিতরণকৃত কনফিগারেশন স্টোরেজ সিস্টেমের সাথে কাজ করে যেমন etcd, Zookeeper, Consul. আমাদের বাজারে শুধু একটি পূর্ণাঙ্গ কনসাল ক্লাস্টার আছে, যা Vault-এর সাথে একত্রে কাজ করে এবং আমরা এটি আর ব্যবহার করি না। কনসাল এর উদ্দিষ্ট উদ্দেশ্যে ব্যবহার শুরু করার একটি বড় কারণ।

প্যাট্রোনি কনসালের সাথে কীভাবে কাজ করে

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

প্যাট্রোনিকে কনসালের সাথে সংযোগ করার জন্য, অফিসিয়াল ডকুমেন্টেশন অধ্যয়ন করা যথেষ্ট, যা বলে যে আমরা কনসালের সাথে কীভাবে কাজ করি তার উপর নির্ভর করে আপনাকে HTTP বা https ফর্ম্যাটে একটি হোস্ট নির্দিষ্ট করতে হবে এবং বিকল্পভাবে সংযোগ স্কিম:

host: the host:port for the Consul endpoint, in format: http(s)://host:port
scheme: (optional) http or https, defaults to http

এটা সহজ দেখায়, কিন্তু এখানে pitfalls শুরু. কনসালের সাথে, আমরা https এর মাধ্যমে একটি সুরক্ষিত সংযোগ নিয়ে কাজ করি এবং আমাদের সংযোগ কনফিগারেশনটি এরকম দেখাবে:

consul:
  host: https://server.production.consul:8080 
  verify: true
  cacert: {{ consul_cacert }}
  cert: {{ consul_cert }}
  key: {{ consul_key }}

কিন্তু তাতে কাজ হয় না। স্টার্টআপে, Patroni কনসালের সাথে সংযোগ করতে পারে না, কারণ এটি যেভাবেই হোক http দিয়ে যাওয়ার চেষ্টা করে।

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

consul:
  host: server.production.consul:8080
  scheme: https
  verify: true
  cacert: {{ consul_cacert }}
  cert: {{ consul_cert }}
  key: {{ consul_key }}

কনসাল-টেমপ্লেট

সুতরাং, আমরা কনফিগারেশনের জন্য স্টোরেজ বেছে নিয়েছি। এখন আমাদের বুঝতে হবে কিভাবে PgBouncer তার কনফিগারেশন পরিবর্তন করবে যখন Patroni ক্লাস্টারে লিডার পরিবর্তন করবে। ডকুমেন্টেশনে এই প্রশ্নের কোন উত্তর নেই, কারণ. সেখানে, নীতিগতভাবে, PgBouncer এর সাথে কাজ বর্ণনা করা হয়নি।

একটি সমাধানের সন্ধানে, আমরা একটি নিবন্ধ পেয়েছি (দুর্ভাগ্যবশত শিরোনামটি আমার মনে নেই) যেখানে লেখা ছিল যে Сonsul-template PgBouncer এবং Patroni জুড়িতে অনেক সাহায্য করেছে। এটি আমাদের কনসাল-টেমপ্লেট কীভাবে কাজ করে তা তদন্ত করতে প্ররোচিত করেছে।

দেখা গেল যে কনসাল-টেমপ্লেট ক্রমাগত Consul-এ PostgreSQL ক্লাস্টারের কনফিগারেশন নিরীক্ষণ করে। যখন নেতা পরিবর্তন হয়, এটি PgBouncer কনফিগারেশন আপডেট করে এবং এটি পুনরায় লোড করার জন্য একটি কমান্ড পাঠায়।

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

Patroni সঙ্গে নতুন স্থাপত্য

ফলস্বরূপ, আমরা নিম্নলিখিত কাজের স্কিম পেয়েছি:


সমস্ত অ্যাপ্লিকেশন সার্ভার ব্যালেন্সার অ্যাক্সেস করে → এর পিছনে PgBouncer-এর দুটি উদাহরণ রয়েছে প্রতিটি ক্লাস্টারের।

ম্যানুয়াল টেস্টিং

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

স্টিকারটি 10-20 সেকেন্ডের মধ্যে ফিরে আসে এবং তারপরে আবার স্বাভাবিকভাবে চলতে শুরু করে। এর অর্থ হল প্যাট্রোনি ক্লাস্টার সঠিকভাবে কাজ করেছে: এটি নেতাকে পরিবর্তন করেছে, কনসুলে তথ্য পাঠিয়েছে এবং কনসুল-টেমপ্লেট অবিলম্বে এই তথ্যটি তুলে নিয়েছে, PgBouncer কনফিগারেশন প্রতিস্থাপন করেছে এবং পুনরায় লোড করার জন্য কমান্ড পাঠিয়েছে।

কিভাবে উচ্চ লোড অধীনে বেঁচে থাকা এবং ডাউনটাইম ন্যূনতম রাখা?

সবকিছু নিখুঁতভাবে কাজ করে! কিন্তু নতুন প্রশ্ন আছে: কিভাবে এটি উচ্চ লোড অধীনে কাজ করবে? কিভাবে দ্রুত এবং নিরাপদে উত্পাদন সবকিছু রোল আউট?

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

উভয় কাজই উচ্চাভিলাষী দেখায়, কিন্তু আমাদের PostgreSQL 9.6 আছে। আমরা কি অবিলম্বে 11.2 এ আপগ্রেড করতে পারি?

আমরা এটি 2টি ধাপে করার সিদ্ধান্ত নিয়েছি: প্রথমে 11.2-এ আপগ্রেড করুন, তারপর Patroni চালু করুন।

PostgreSQL আপডেট

PostgreSQL সংস্করণ দ্রুত আপডেট করতে, বিকল্পটি ব্যবহার করুন -k, যাতে হার্ড লিঙ্কগুলি ডিস্কে তৈরি করা হয় এবং আপনার ডেটা অনুলিপি করার প্রয়োজন নেই। 300-400 GB এর ভিত্তিতে, আপডেট হতে 1 সেকেন্ড সময় লাগে।

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

/usr/lib/postgresql/11/bin/pg_upgrade 
<b>--link </b>
--old-datadir='' --new-datadir='' 
 --old-bindir=''  --new-bindir='' 
 --old-options=' -c config_file=' 
 --new-options=' -c config_file='

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

Patroni চালু করুন

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

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

rm -rf /var/lib/postgresql/

এটা শুধু দাসের উপরই করা দরকার!

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

আরেকটি অসুবিধা হল যে সমস্ত PostgreSQL ক্লাস্টার ডিফল্টরূপে প্রধান নামকরণ করা হয়। যখন প্রতিটি ক্লাস্টার অন্য সম্পর্কে কিছুই জানে না, এটি স্বাভাবিক। কিন্তু আপনি যখন Patroni ব্যবহার করতে চান, তখন সমস্ত ক্লাস্টারের একটি অনন্য নাম থাকতে হবে। সমাধান হল PostgreSQL কনফিগারেশনে ক্লাস্টারের নাম পরিবর্তন করা।

লোড পরীক্ষা

আমরা একটি পরীক্ষা চালু করেছি যা বোর্ডে ব্যবহারকারীর অভিজ্ঞতার অনুকরণ করে। যখন লোড আমাদের গড় দৈনিক মান পৌঁছেছে, আমরা ঠিক একই পরীক্ষা পুনরাবৃত্তি করেছি, আমরা PostgreSQL নেতার সাথে একটি উদাহরণ বন্ধ করে দিয়েছি। স্বয়ংক্রিয় ব্যর্থতা আমাদের প্রত্যাশা অনুযায়ী কাজ করেছে: Patroni নেতা পরিবর্তন করেছে, কনসাল-টেমপ্লেট PgBouncer কনফিগারেশন আপডেট করেছে এবং পুনরায় লোড করার জন্য একটি কমান্ড পাঠিয়েছে। Grafana-এ আমাদের গ্রাফ অনুসারে, এটা স্পষ্ট যে ডাটাবেসের সাথে সংযোগের সাথে যুক্ত সার্ভার থেকে 20-30 সেকেন্ডের বিলম্ব এবং অল্প পরিমাণে ত্রুটি রয়েছে। এটি একটি স্বাভাবিক পরিস্থিতি, এই ধরনের মানগুলি আমাদের ব্যর্থতার জন্য গ্রহণযোগ্য এবং পরিষেবা ডাউনটাইম থেকে অবশ্যই ভাল।

পাত্রোনিকে উৎপাদনে নিয়ে আসা

ফলস্বরূপ, আমরা নিম্নলিখিত পরিকল্পনা নিয়ে এসেছি:

• PgBouncer সার্ভারে কনসাল-টেমপ্লেট স্থাপন করুন এবং চালু করুন;
• PostgreSQL সংস্করণ 11.2 আপডেট;
• ক্লাস্টারের নাম পরিবর্তন করুন;
• Patroni ক্লাস্টার শুরু করা হচ্ছে।

একই সময়ে, আমাদের স্কিমটি আমাদের প্রায় যেকোনো সময় প্রথম পয়েন্ট তৈরি করতে দেয়, আমরা প্রতিটি পিজিবাউন্সারকে কাজ থেকে সরিয়ে দিতে পারি এবং এটিতে কনসাল-টেমপ্লেট স্থাপন ও চালাতে পারি। তাই আমরা করেছি।

দ্রুত মোতায়েন করার জন্য, আমরা Ansible ব্যবহার করেছি, যেহেতু আমরা ইতিমধ্যেই একটি পরীক্ষার পরিবেশে সমস্ত প্লেবুক পরীক্ষা করেছি, এবং সম্পূর্ণ স্ক্রিপ্টের সম্পাদনের সময় ছিল প্রতিটি শার্ডের জন্য 1,5 থেকে 2 মিনিট। আমরা আমাদের পরিষেবা বন্ধ না করেই প্রতিটি শার্ডে পালাক্রমে সবকিছু রোল আউট করতে পারি, তবে আমাদের প্রতিটি PostgreSQL কয়েক মিনিটের জন্য বন্ধ করতে হবে। এই ক্ষেত্রে, যে ব্যবহারকারীদের ডেটা এই শার্ডে রয়েছে তারা এই সময়ে পুরোপুরি কাজ করতে পারেনি এবং এটি আমাদের জন্য অগ্রহণযোগ্য।

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


আমরা আমাদের পরিষেবা পুনঃসূচনা করেছি, সবকিছু যেমন উচিত ছিল তেমন কাজ করেছে, ব্যবহারকারীরা কাজ চালিয়ে যাচ্ছেন, কিন্তু গ্রাফগুলিতে আমরা কনসাল সার্ভারগুলিতে অস্বাভাবিকভাবে উচ্চ লোড লক্ষ্য করেছি।


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

Patroni ক্লাস্টার রিস্টার্ট করুন

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

ERROR: get_cluster
Traceback (most recent call last):
...
RetryFailedError: 'Exceeded retry deadline'
ERROR: Error communicating with DCS
<b>LOG: database system is shut down</b>

Patroni ক্লাস্টার তার ক্লাস্টার সম্পর্কে তথ্য পুনরুদ্ধার করতে অক্ষম ছিল এবং পুনরায় চালু হয়েছে।

একটি সমাধান খুঁজতে, আমরা গিথুবের একটি সমস্যার মাধ্যমে Patroni লেখকদের সাথে যোগাযোগ করেছি। তারা আমাদের কনফিগারেশন ফাইলগুলির উন্নতির পরামর্শ দিয়েছে:

consul:
 consul.checks: []
bootstrap:
 dcs:
   retry_timeout: 8

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

সমস্যাটি এখনও অমীমাংসিত রয়ে গেছে। আমরা নিম্নলিখিত সমাধানগুলি চেষ্টা করার পরিকল্পনা করছি:

• প্রতিটি Patroni ক্লাস্টার উদাহরণে কনসাল-এজেন্ট ব্যবহার করুন;
• কোডে সমস্যাটি ঠিক করুন।

আমরা বুঝতে পারি কোথায় ত্রুটি ঘটেছে: সমস্যাটি সম্ভবত ডিফল্ট টাইমআউটের ব্যবহার, যা কনফিগারেশন ফাইলের মাধ্যমে ওভাররাইড করা হয় না। যখন ক্লাস্টার থেকে শেষ কনসাল সার্ভারটি সরানো হয়, তখন পুরো কনসাল ক্লাস্টারটি এক সেকেন্ডের বেশি সময় ধরে স্তব্ধ হয়ে যায়, এই কারণে, Patroni ক্লাস্টারের স্ট্যাটাস পেতে পারে না এবং সম্পূর্ণ ক্লাস্টারটি পুনরায় চালু করে।

সৌভাগ্যবশত, আমরা আর কোনো ত্রুটির সম্মুখীন হইনি।

Patroni ব্যবহারের ফলাফল

Patroni-এর সফল লঞ্চের পর, আমরা প্রতিটি ক্লাস্টারে একটি অতিরিক্ত রেপ্লিকা যোগ করেছি। এখন প্রতিটি ক্লাস্টারে একটি কোরামের আভাস রয়েছে: একজন নেতা এবং দুটি প্রতিলিপি, স্যুইচ করার সময় বিভক্ত-মস্তিষ্কের ক্ষেত্রে সুরক্ষা জালের জন্য।


তিন মাসেরও বেশি সময় ধরে প্রযোজনার কাজ করছেন পাত্রোনি। এই সময়ের মধ্যে, তিনি ইতিমধ্যে আমাদের সাহায্য করতে পরিচালিত করেছেন। সম্প্রতি, একটি ক্লাস্টারের নেতা AWS-তে মারা গেছে, স্বয়ংক্রিয় ব্যর্থতা কাজ করেছে এবং ব্যবহারকারীরা কাজ চালিয়ে যাচ্ছেন। পৃষ্ঠপোষক তার প্রধান কাজ সম্পন্ন.

Patroni ব্যবহারের একটি ছোট সারসংক্ষেপ:

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

উত্স: www.habr.com