ওডিসি রোডম্যাপ: সংযোগ পুলার থেকে আমরা আর কী চাই। আন্দ্রে বোরোডিন (2019)

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

ভিডিও:

হাই সব! আমার নাম এন্ড্রু.

ইয়ানডেক্সে, আমি ওপেন সোর্স ডেটাবেস তৈরি করি। এবং আজ আমরা সংযোগ পুলার সংযোগ সম্পর্কে একটি বিষয় আছে.

আপনি যদি রাশিয়ান ভাষায় সংযোগ পুলার কল করতে জানেন, তাহলে আমাকে বলুন। আমি সত্যিই একটি ভাল প্রযুক্তিগত শব্দ খুঁজে পেতে চাই যা প্রযুক্তিগত সাহিত্যে প্রতিষ্ঠিত হওয়া উচিত।

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

Yandex এর Postgres আছে। Yandex.Cloud-এ অনেক Yandex পরিষেবা থাকে। এবং আমাদের কাছে বেশ কয়েকটি পেটাবাইট ডেটা রয়েছে যা পোস্টগ্রেসে প্রতি সেকেন্ডে কমপক্ষে এক মিলিয়ন অনুরোধ তৈরি করে।

এবং আমরা সমস্ত পরিষেবার জন্য একটি মোটামুটি স্ট্যান্ডার্ড ক্লাস্টার প্রদান করি - এটি নোডের প্রধান প্রাথমিক নোড, স্বাভাবিক দুটি প্রতিলিপি (সিঙ্ক্রোনাস এবং অ্যাসিঙ্ক্রোনাস), ব্যাকআপ, প্রতিলিপিতে পড়ার অনুরোধের স্কেলিং।

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

সংযোগ পুলারের মূল উদ্দেশ্য কি?

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

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

3টি সম্ভাব্য পন্থা রয়েছে:

• আবেদনের দিকে।
• ডাটাবেসের দিকে।
• এবং মধ্যে, যে, সমন্বয় সব ধরনের.

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

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

যে সমস্যাটি দেখা দেয় তা হল একটি নির্দিষ্ট সময়ে আপনি ব্যাকএন্ড স্কেল করতে চান, আপনি এটি অনেক ভার্চুয়াল মেশিনে স্থাপন করতে চান।

তারপরে আপনি বুঝতে পারবেন যে আপনার আরও বেশ কয়েকটি প্রাপ্যতা অঞ্চল, বেশ কয়েকটি ডেটা সেন্টার রয়েছে। এবং ক্লায়েন্ট সাইড পুলিং পদ্ধতি বড় সংখ্যার দিকে নিয়ে যায়। বড়গুলি প্রায় 10 সংযোগ। এটি এমন প্রান্ত যা স্বাভাবিকভাবে কাজ করতে পারে।

আমরা যদি প্রক্সি পুলার সম্পর্কে কথা বলি, তাহলে দুটি পুলার আছে যারা অনেক কিছু করতে পারে। তারা শুধু পুলার নয়। তারা পুলার + আরও শান্ত কার্যকারিতা। এই পিজিপুল и ক্রাঞ্চি-প্রক্সি.

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

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

এবং আমাদের কাজের চাপে, এটি সত্য। কিন্তু কিছু সমস্যা আছে.

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

অবশ্যই আপনি application_name_add_host ব্যবহার করতে পারেন। অ্যাপ্লিকেশন_নামে একটি আইপি ঠিকানা যোগ করার জন্য এটি বাউন্সার সাইডের একটি উপায়। কিন্তু অ্যাপ্লিকেশন_নাম একটি অতিরিক্ত সংযোগ দ্বারা সেট করা হয়েছে।

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

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

এই নেতৃত্ব কি? আপনার কাছে C++ এ লেখা একটি লোড করা পরিষেবা রয়েছে এবং কাছাকাছি কোথাও একটি নোডে একটি ছোট পরিষেবা রয়েছে যা ডাটাবেসের সাথে ভয়ানক কিছু করে না, তবে এর ড্রাইভার পাগল হয়ে যায়। এটি 20 সংযোগ খোলে এবং বাকি সবকিছু অপেক্ষা করবে। এমনকি আপনার কোড স্বাভাবিক.

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

পোস্টগ্রেসের দিকে এটি করা সম্ভব হবে, অর্থাৎ, সংযোগের সংখ্যা দ্বারা ডাটাবেসের ভূমিকা সীমিত করুন।

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

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

উপরের দিকে তাকান এবং দেখুন যে বাউন্সার একক-থ্রেডেড। এটি সেবার জীবনের একটি টার্নিং পয়েন্ট। আপনি বুঝতে পেরেছেন যে আপনি দেড় বছরে ডাটাবেস স্কেল করার জন্য প্রস্তুতি নিচ্ছেন এবং আপনাকে পুলার স্কেল করতে হবে।

আমরা উপসংহারে এসেছি যে আমাদের আরও পিজিবাউন্সার দরকার।

https://lwn.net/Articles/542629/

বাউন্সার কিছুটা প্যাচ করা হয়েছে।

এবং তারা এটি তৈরি করেছে যাতে TCP পোর্ট পুনরায় ব্যবহার করে বেশ কয়েকটি বাউন্সার তৈরি করা যায়। এবং অপারেটিং সিস্টেম স্বয়ংক্রিয়ভাবে রাউন্ড-রবিন ব্যবহার করে তাদের মধ্যে ইনকামিং TCP সংযোগ স্থানান্তর করে।

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

এবং একটি নির্দিষ্ট মুহুর্তে আপনি লক্ষ্য করতে পারেন যে এই 3টি বাউন্সার প্রতিটি তাদের মূল 100% খেয়ে ফেলে। আপনার বেশ কয়েকটি বাউন্সার দরকার। কেন?

কারণ আপনার টিএলএস আছে। আপনার একটি এনক্রিপ্ট করা সংযোগ আছে৷ এবং আপনি যদি TLS এর সাথে এবং ছাড়া পোস্টগ্রেসকে বেঞ্চমার্ক করেন, তাহলে আপনি দেখতে পাবেন যে এনক্রিপশন সক্ষম করে প্রতিষ্ঠিত সংযোগের সংখ্যা প্রায় দুই অর্ডারের পরিমাণ কমে যায়, কারণ TLS হ্যান্ডশেক CPU সংস্থানগুলি ব্যবহার করে।

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

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

এখানে 16টি পিজিবাউন্সারের একটি উদাহরণ রয়েছে যা 16% এ 100 কোর লোড করে।

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

এই কনফিগারেশনে, একটি মসৃণ পুনরায় চালু করা সম্ভব। আপনি এই সমস্ত 18টি বাউন্সার একে একে পুনরায় চালু করতে পারেন। কিন্তু এই ধরনের কনফিগারেশন বজায় রাখা বেশ কঠিন। Sysadmins, DevOps, এবং যারা আসলে এই সার্ভারের জন্য দায়ী তারা এই ব্যবস্থায় খুব একটা খুশি হবে না।

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

https://www.postgresql.org/docs/current/libpq-cancel.html

https://github.com/pgbouncer/pgbouncer/pull/79

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

এটি প্যাচ করা হয়েছে এবং এই সমস্যাটি এখনও বাউন্সারের আপস্ট্রিমে একত্রিত হয়নি।

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

আমরা প্রধান কাজ হিসাবে মাল্টিথ্রেডিং সেট. আমাদের ইনকামিং TLS সংযোগের তরঙ্গ ভালভাবে পরিচালনা করতে সক্ষম হতে হবে।

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

ফলস্বরূপ, আমাদের কাছে একটি থ্রেড রয়েছে যা TCP গ্রহণ করে এবং রাউন্ড-রবিন অনেক কর্মীদের কাছে TPC সংযোগটি পাস করে।

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

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

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

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

আমরা Yandex.Cloud এর স্বার্থে কাজ করি। এবং যদি আপনি পরিচালিত PostgreSQL ব্যবহার করেন এবং একটি সংযোগ পুলার ইনস্টল করা থাকে, তাহলে আপনি যৌক্তিক প্রতিলিপি ব্যবহার করে বাইরের দিকে যৌক্তিক প্রতিলিপি তৈরি করতে পারেন, অর্থাৎ, আপনি চাইলে আমাদের ছেড়ে দিন। বাউন্সার বাইরে যৌক্তিক প্রতিলিপি প্রবাহ প্রকাশ করবে না।

এটি যৌক্তিক প্রতিলিপি সেট আপ করার একটি উদাহরণ।

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

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

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

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

নকশা

ওডিসি সোর্স কোড সম্পর্কে কয়েকটি শব্দ।

https://github.com/yandex/odyssey/pull/66

উদাহরণস্বরূপ, "পজ/রিজুম" কমান্ড রয়েছে। এগুলি সাধারণত ডেটাবেস আপডেট করতে ব্যবহৃত হয়। আপনার যদি Postgres আপডেট করতে হয়, তাহলে আপনি সংযোগ পুলারে এটিকে বিরতি দিতে পারেন, pg_upgrade করতে পারেন, তারপর পুনরায় শুরু করতে পারেন। এবং ক্লায়েন্টের দিক থেকে দেখে মনে হবে যে ডাটাবেসটি কেবল ধীর হয়ে যাচ্ছে। এই কার্যকারিতা সম্প্রদায়ের লোকেরা আমাদের কাছে নিয়ে এসেছে। তিনি এখনও হিমায়িত নন, তবে শীঘ্রই সবকিছু হয়ে যাবে। (ইতিমধ্যে হিমায়িত)

https://github.com/yandex/odyssey/pull/73 - ইতিমধ্যে হিমায়িত

এছাড়াও, PgBouncer-এর নতুন বৈশিষ্ট্যগুলির মধ্যে একটি হল SCRAM প্রমাণীকরণের জন্য সমর্থন, যা আমাদের কাছে এমন একজন ব্যক্তি এনেছিলেন যিনি Yandex.Cloud-এ কাজ করেন না। উভয়ই জটিল কার্যকারিতা এবং গুরুত্বপূর্ণ।

অতএব, আমি আপনাকে বলতে চাই ওডিসি কি দিয়ে তৈরি, যদি আপনি এখন একটু কোড লিখতে চান।

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

মেশিনারিয়াম লাইব্রেরি হল একটি থ্রেড বাস্তবায়ন লাইব্রেরি। এই মেশিনারিয়ামের একটি ছোট অংশ সমাবেশের ভাষায় লেখা হয়েছে। কিন্তু আতঙ্কিত হবেন না, শুধুমাত্র 15 লাইন আছে.

ওডিসি স্থাপত্য। একটি প্রধান মেশিন আছে যার উপর কোরোটিন চলছে। এই মেশিনটি ইনকামিং টিসিপি সংযোগ গ্রহণ করে এবং শ্রমিকদের মধ্যে বিতরণ করে।

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

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

উপরন্তু, অনেক ড্রাইভার আছে যে তাদের নিজস্ব পরীক্ষা আছে। এবং আমরা ওডিসি পরীক্ষা করার জন্য তাদের পরীক্ষা ব্যবহার করি।

এছাড়াও, আমাদের ক্যাসকেড কনফিগারেশনের কারণে, আমাদের বিভিন্ন বান্ডিল পরীক্ষা করতে হবে: Postgres + Odyssey, PgBouncer + Odyssey, Odyssey + Odyssey যাতে ক্যাসকেডের কোনো অংশে ওডিসি শেষ হয়ে যায়, এটি এখনও কাজ করে। আমরা আশা করি।

মই দিয়া আহরণ করা

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

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

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

প্লাগযোগ্য প্রমাণীকরণ পদ্ধতি হল অন্তর্নির্মিত লুনাক্স টুল ব্যবহার করে প্রমাণীকরণ করার ক্ষমতা। PgBouncer-এ এটি এমনভাবে প্রয়োগ করা হয় যে PAM থেকে প্রতিক্রিয়ার জন্য অপেক্ষা করার জন্য একটি পৃথক থ্রেড রয়েছে এবং একটি প্রধান PgBouncer থ্রেড রয়েছে যা বর্তমান সংযোগের পরিষেবা দেয় এবং তাদের PAM থ্রেডে থাকতে বলতে পারে।

আমরা একটি সাধারণ কারণে এটি বাস্তবায়ন করিনি। আমরা থ্রেড অনেক আছে. আমাদের কেন এটা দরকার?

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

আরেকটি রেক ছিল যে আমাদের কাছে একটি থ্রেড রয়েছে যা সমস্ত আগত সংযোগ গ্রহণ করে। এবং তারপরে তারা কর্মী পুলে স্থানান্তরিত হয়, যেখানে TLS হ্যান্ডশেক হবে।

নীচের লাইনে, আপনার যদি 20 নেটওয়ার্ক সংযোগগুলির একটি সুসংগত তরঙ্গ থাকে তবে সেগুলি সবই গ্রহণ করা হবে৷ এবং ক্লায়েন্ট সাইডে libpq টাইমআউট রিপোর্ট করা শুরু করবে। ডিফল্টরূপে এটি 000 সেকেন্ড বলে মনে হয়।

যদি তারা সবাই একই সময়ে ডাটাবেসে প্রবেশ করতে না পারে, তাহলে তারা ডাটাবেসে প্রবেশ করতে পারবে না, কারণ এই সমস্ত অ-সূচক পুনঃপ্রচেষ্টা দ্বারা কভার করা যেতে পারে।

আমরা এই সিদ্ধান্তে উপনীত হয়েছি যে আমরা PgBouncer থেকে এই স্কিমটি এখানে কপি করেছি যে আমরা TCP সংযোগের সংখ্যা থ্রোটলিং করেছি যা আমরা গ্রহণ করি।

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

রোডম্যাপ

ওডিসিতে আপনি ভবিষ্যতে কী দেখতে চান? আমরা নিজেদেরকে বিকশিত করতে কী প্রস্তুত এবং সম্প্রদায়ের কাছ থেকে আমরা কী আশা করি?

আগস্ট 2019 অনুযায়ী।

আগস্টে ওডিসি রোডম্যাপটি এইরকম ছিল:

• আমরা SCRAM এবং PAM প্রমাণীকরণ চেয়েছিলাম।
• আমরা স্ট্যান্ডবাই পড়ার অনুরোধ ফরোয়ার্ড করতে চেয়েছিলাম।
• আমি একটি অনলাইন রিস্টার্ট চাই।
• এবং সার্ভারে বিরতি দেওয়ার ক্ষমতা।

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

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

নীতিগতভাবে, Postgres-এ, 10 থেকে শুরু করে, সংযোগ করার সময় session_attrs নির্দিষ্ট করা সম্ভব। আপনি সংযোগে থাকা সমস্ত ডাটাবেস হোস্টের তালিকা করতে পারেন এবং বলতে পারেন কেন আপনি ডাটাবেসে যাচ্ছেন: কেবল লিখুন বা পড়ুন। এবং ড্রাইভার নিজেই তালিকার প্রথম হোস্ট নির্বাচন করবে যা তার সবচেয়ে ভালো লাগে, যা সেশন_এটিআর-এর প্রয়োজনীয়তা পূরণ করে।

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

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

এটি বাস্তবায়নের জন্য একটি সময়সীমা দেওয়া কঠিন, কারণ এটি ওপেন সোর্স। কিন্তু, আমি আশা করি, PgBouncer থেকে আমার সহকর্মীদের মতো 2,5 বছর নয়। এই বৈশিষ্ট্যটি আমি ওডিসিতে দেখতে চাই।

সম্প্রদায়ে, লোকেরা প্রস্তুত বিবৃতিটির সমর্থন সম্পর্কে জিজ্ঞাসা করেছিল. এখন আপনি দুটি উপায়ে একটি প্রস্তুত বিবৃতি তৈরি করতে পারেন। প্রথমে, আপনি এসকিউএল কমান্ড চালাতে পারেন, যথা "প্রস্তুত"। এই এসকিউএল কমান্ড বোঝার জন্য, আমাদের বাউন্সার সাইডে এসকিউএল বুঝতে শিখতে হবে। এটি একটি ওভারকিল হবে, কারণ এটি ওভারকিল, যেহেতু আমাদের সম্পূর্ণ পার্সার প্রয়োজন। আমরা প্রতিটি SQL কমান্ড পার্স করতে পারি না।

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

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

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

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

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

সবচেয়ে গুরুত্বপূর্ণ বিষয় হল আমি সংস্করণ 1.0 চাই (সংস্করণ 1.1 ইতিমধ্যে প্রকাশিত হয়েছে)। আসল বিষয়টি হল ওডিসি এখন 1.0rc সংস্করণে রয়েছে, অর্থাৎ মুক্তি প্রার্থী৷ এবং আমি তালিকাভুক্ত সমস্ত সমস্যাগুলি ঠিক একই সংস্করণে ঠিক করা হয়েছিল, মেমরি লিক বাদে।

সংস্করণ 1.0 আমাদের জন্য কি মানে? আমরা ওডিসিকে আমাদের ঘাঁটিতে নিয়ে যাচ্ছি। এটি ইতিমধ্যেই আমাদের ডাটাবেসে চলছে, কিন্তু যখন এটি প্রতি সেকেন্ডে 1 অনুরোধের বিন্দুতে পৌঁছায়, তখন আমরা বলতে পারি যে এটি রিলিজ সংস্করণ এবং এটি একটি সংস্করণ যাকে 000 বলা যেতে পারে।

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

আমি আপনার টান অনুরোধ জন্য অপেক্ষা করছি. বাউন্সার নিয়ে আপনার কী সমস্যা আছে তাও আমি শুনতে চাই। তাদের আলোচনা করা যাক. হয়তো আমরা আপনার প্রয়োজনীয় কিছু ফাংশন বাস্তবায়ন করতে পারি।

এই আমার অংশ শেষ, আমি আপনার শুনতে চাই. ধন্যবাদ!

প্রশ্ন

যদি আমি আমার নিজের অ্যাপ্লিকেশন_নাম সেট করি, তাহলে ওডিসিতে লেনদেন পুলিং সহ এটি কি সঠিকভাবে ফরোয়ার্ড করা হবে?

ওডিসি নাকি বাউন্সার?

ওডিসিতে। বাউন্সারে এটি নিক্ষেপ করা হয়।

আমরা একটি সেট করব।

এবং যদি আমার আসল সংযোগ অন্য সংযোগগুলিতে লাফ দেয় তবে তা কি প্রেরণ করা হবে?

আমরা তালিকায় তালিকাভুক্ত সমস্ত পরামিতিগুলির একটি সেট তৈরি করব। অ্যাপ্লিকেশন_নাম এই তালিকায় আছে কিনা তা আমি বলতে পারব না। আমি মনে করি আমি তাকে সেখানে দেখেছি। আমরা একই প্যারামিটার সেট করব। একটি অনুরোধের সাথে, সেটটি স্টার্টআপের সময় ক্লায়েন্ট দ্বারা ইনস্টল করা সমস্ত কিছু করবে।

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

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

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

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

হ্যাঁ এটা সত্য. pcache-এ আপনার পছন্দের ডেটা ব্লক থাকবে না, আসল ক্যাশে আপনার পছন্দসই টেবিলগুলি সম্পর্কে তথ্য থাকবে না, পরিকল্পনাগুলিতে পার্স করা প্রশ্ন থাকবে না, কিছুই থাকবে না।

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

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

হ্যাঁ, ওজন বাড়ান।

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

Nginx এই বিকল্প আছে slowly start সার্ভারের জন্য একটি ক্লাস্টারে। আর সে ধীরে ধীরে ভার বাড়ায়।

হ্যাঁ, দুর্দান্ত ধারণা, আমরা এটির কাছাকাছি গেলে আমরা এটি চেষ্টা করব।

উত্স: www.habr.com