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

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

কেন আমি এটা প্রয়োজন?

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

আপস পূরণ

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

ট্রেডঅফ 1: কর্মক্ষমতা

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

ট্রেডঅফ 2: ধারাবাহিকতা

এই দুটি পদ্ধতিতে নেতার ব্যর্থতার ক্ষেত্রে ফলাফলও ভিন্ন হবে। যদি কাজটি অ্যাসিঙ্ক্রোনাসভাবে সঞ্চালিত হয়, তাহলে যদি এমন একটি ত্রুটি ঘটে, তবে সমস্ত রেকর্ড প্রতিলিপি দ্বারা প্রতিশ্রুতিবদ্ধ হবে না। কতটা নষ্ট হবে? অ্যাপ্লিকেশন নিজেই এবং প্রতিলিপি দক্ষতার উপর নির্ভর করে। কম্পোজ প্রতিলিপি একটি প্রতিলিপিকে নেতা হতে বাধা দেবে যদি এতে তথ্যের পরিমাণ লিডারের তুলনায় 1 MB কম হয়, অর্থাৎ, অ্যাসিঙ্ক্রোনাস অপারেশন চলাকালীন 1 MB পর্যন্ত রেকর্ড সম্ভাব্যভাবে হারিয়ে যেতে পারে।

এটি সিঙ্ক্রোনাস মোডে ঘটবে না। নেতা ব্যর্থ হলে, সমস্ত প্রতিলিপি আপডেট করা হয়, যেহেতু নেতার বিষয়ে নিশ্চিত হওয়া যেকোনো লেখা অবশ্যই প্রতিলিপিগুলিতে নিশ্চিত হওয়া উচিত। এই ধারাবাহিকতা.

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

ট্রেড-অফ 3: ক্র্যাশ

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

প্রতি লেনদেনে একটি সংযোগ?

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

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

অনুশীলনে নিয়ন্ত্রণ নিশ্চিত করা

ডিফল্টরূপে, PostgreSQL ধারাবাহিকতা প্রদান করে। এটি সার্ভার প্যারামিটার দ্বারা নিয়ন্ত্রিত হয় synchronous_commit. ডিফল্টরূপে এটি অবস্থানে আছে on, কিন্তু এটির আরও তিনটি বিকল্প রয়েছে: local, remote_write বা off.

প্যারামিটার সেট করার সময় off সমস্ত সিঙ্ক্রোনাস কমিট বন্ধ করা হয়, এমনকি স্থানীয় সিস্টেমেও। স্থানীয় পরামিতি স্থানীয় সিস্টেমের জন্য সিঙ্ক্রোনাস মোড নির্দিষ্ট করে, কিন্তু প্রতিলিপিগুলি অসিঙ্ক্রোনাসভাবে সঞ্চালিত হয়। Remote_write আরও এগিয়ে যায়: প্রতিলিপিতে লেখাগুলি অ্যাসিঙ্ক্রোনাসভাবে তৈরি করা হয়, কিন্তু যখন প্রতিলিপি লেখাটি গ্রহণ করে কিন্তু ডিস্কে না লিখে তখন ফেরত দেওয়া হয়।

বিকল্পগুলির উপলব্ধ পরিসর বিবেচনা করে, আমরা একটি আচরণ বেছে নিই এবং এটি মনে রেখে on - এগুলি সিঙ্ক্রোনাস রেকর্ডিং, আমরা বেছে নেব local নেটওয়ার্কে অ্যাসিঙ্ক্রোনাস কমিটের জন্য, স্থানীয় কমিট সিঙ্ক্রোনাস ছেড়ে যাওয়ার সময়।

এখন, আমরা আপনাকে এক মুহূর্তের মধ্যে এটি কীভাবে সেট আপ করব তা বলব, তবে কল্পনা করুন যে আমরা সেট আপ করেছি synchronous_commit в local সার্ভারের জন্য। আমরা ভাবছিলাম যে প্যারামিটার পরিবর্তন করা সম্ভব কিনা synchronous_commit ফ্লাইতে, এবং দেখা গেল যে এটি কেবল সম্ভব নয়, এটি করার দুটি উপায়ও রয়েছে। প্রথমটি হল আপনার সংযোগের সেশনটি নিম্নরূপ সেট করা:

SET SESSION synchronous_commit TO ON;  
// Your writes go here

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

দ্বিতীয় পদ্ধতিটি ভাল যখন আপনি নিশ্চিত করতে চান যে আপনি একটি একক লেনদেনের জন্য সিঙ্ক্রোনাস প্রতিলিপি পান। অনেক NoSQL প্রজন্মের ডাটাবেসে লেনদেনের ধারণাটি বিদ্যমান নেই, তবে এটি PostgreSQL-এ আছে। এই ক্ষেত্রে আপনি একটি লেনদেন শুরু করুন এবং তারপর সেট করুন synchronous_commit в on লেনদেনের জন্য এন্ট্রি কার্যকর করার আগে। COMMIT যেকোনো প্যারামিটার মান ব্যবহার করে লেনদেন কমিট করবে synchronous_commit, যা সেই সময়ে সেট করা হয়েছিল, যদিও অন্য ডেভেলপাররা বুঝতে পারে যে লেখাগুলি অ্যাসিঙ্ক্রোনাস নয় তা নিশ্চিত করার জন্য ভেরিয়েবলটি আগেভাগে সেট করা ভাল।

BEGIN;  
SET LOCAL synchronous_commit TO ON;  
// Your writes go here
COMMIT;  

ডাটাবেস সংযুক্ত ক্লায়েন্টকে একটি ইতিবাচক প্রতিক্রিয়া ফেরত দেওয়ার আগে সমস্ত লেনদেনের প্রতিশ্রুতিগুলি এখন প্রতিলিপিগুলিতে লেখা হিসাবে নিশ্চিত করা হবে।

PostgreSQL সেট আপ করা হচ্ছে

এর আগে, আমরা এর সাথে একটি PostgreSQL সিস্টেম কল্পনা করেছি synchronous_commit, এ ইনস্টল করা হয়েছে local. সার্ভারের দিকে এটি বাস্তবসম্মত করতে, আপনাকে দুটি সার্ভার কনফিগারেশন বিকল্প সেট করতে হবে। আরও একটি প্যারামিটার synchronous_standby_names যখন তার নিজের মধ্যে আসবে synchronous_commit ভিতরে হবে on. এটি নির্ধারণ করে যে কোন প্রতিলিপিগুলি সিঙ্ক্রোনাস কমিটের জন্য যোগ্য এবং আমরা এটি সেট করব *, যার মানে হবে যে সমস্ত প্রতিলিপি জড়িত। এই মানগুলি সাধারণত কনফিগার করা হয় কনফিগারেশন ফাইল যোগ করে:

synchronous_commit = local  
synchronous_standby_names='*'

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

আপনি যদি উন্নয়ন অনুসরণ করা হয়েছে গভর্নর প্রকল্পআপনি হয়ত কিছু সাম্প্রতিক পরিবর্তন লক্ষ্য করেছেন (1, 2), যা গভর্নর ব্যবহারকারীদের এই পরামিতিগুলি পরীক্ষা করতে এবং তাদের সামঞ্জস্য নিরীক্ষণ করার অনুমতি দেয়।

আরো কিছু শব্দ ...

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

এই সেটিং যে কোনো সময় পরিবর্তন করা যেতে পারে. যে কোনো লেনদেনের আচরণ প্রতিশ্রুতির সময়ে কার্যকর সেটিং দ্বারা নির্ধারিত হয়। অতএব, কিছু লেনদেনের জন্য সিঙ্ক্রোনাসভাবে এবং অন্যদের জন্য অ্যাসিঙ্ক্রোনাসভাবে করা সম্ভব এবং দরকারী। উদাহরণস্বরূপ, একজনকে জোর করা multistatement প্যারামিটারের ডিফল্ট মান বিপরীতে সেট করা হলে অ্যাসিঙ্ক্রোনাসভাবে কমিট করার জন্য লেনদেন SET LOCAL synchronous_commit TO OFF একটি লেনদেনে

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

উত্স: www.habr.com