Couchbase উৎপাদনে উচ্চ প্রাপ্যতা: XDCR, Kubernetes অপারেটর, এবং বহু-অঞ্চল স্থাপনা
এক্সডিসিআর, স্বায়ত্তশাসিত অপারেটর এবং মাল্টি-ক্লাউড স্থাপনার সাথে এন্টারপ্রাইজ Couchbase HA
ভূমিকা: কেন উচ্চ প্রাপ্যতা উত্পাদন কাজের চাপের জন্য Couchbase
Couchbase সার্ভার হল একটি বিতরণ, মাল্টি-মডেল NoSQL ডাটাবেস যা ইন্টারেক্টিভ অ্যাপ্লিকেশনগুলির জন্য তৈরি করা হয়েছে যা যেকোনো স্কেলে সামঞ্জস্যপূর্ণ নিম্ন-বিলম্বিত কর্মক্ষমতা দাবি করে। ডেটাবেসগুলির বিপরীতে যেগুলি বিতরণ করা বৈশিষ্ট্যগুলিকে একটি আফটার থট হিসাবে বোল্ট করে, Couchbase এর সূচনা থেকে একটি শেয়ার্ড-নথিং, পিয়ার-টু-পিয়ার টপোলজির চারপাশে স্থাপিত হয়েছিল যেখানে প্রতিটি নোড সমান এবংvBucketsনামক একটি ডিটারমিনিস্টিক হ্যাশিং মেকানিজম ব্যবহার করে ক্লাস্টার জুড়ে ডেটা স্বয়ংক্রিয়ভাবে শার্ড করা হয়। এই স্থাপত্য পছন্দ ডেটা স্তরে ব্যর্থতার একক পয়েন্ট দূর করে এবং অ্যাপ্লিকেশন পরিবর্তন ছাড়াই অনুভূমিক স্কেলিং সক্ষম করে।
উচ্চ প্রাপ্যতা ল্যান্ডস্কেপে Couchbase কে আলাদা করে তা হল এরক্রস ডেটা সেন্টার রেপ্লিকেশন (XDCR)— একটি অন্তর্নির্মিত, অ্যাসিঙ্ক্রোনাস রেপ্লিকেশন ইঞ্জিন যা ভৌগলিকভাবে বিতরণ করা ক্লাস্টারগুলির মধ্যে ক্রমাগত মিউটেশনগুলিকে প্রবাহিত করে৷ স্বয়ংক্রিয় ফেইলওভার, র্যাক/জোন সচেতনতা, এবং সমন্বিত পরিষেবাগুলির একটি সমৃদ্ধ সেট (ডেটা, ইনডেক্স, কোয়েরি, অনুসন্ধান, বিশ্লেষণ এবং ইভেন্টিং) এর সাথে মিলিত, Couchbase একটি ইউনিফাইড প্ল্যাটফর্ম প্রদান করে যা আধুনিক অ্যাপ্লিকেশনের জন্য অপারেশনাল ডাটাবেস এবং বিশ্লেষণাত্মক ইঞ্জিন উভয় হিসাবে কাজ করতে পারে।
এই বিস্তৃত নির্দেশিকায়, আমরা উচ্চ প্রাপ্যতা উত্পাদন পরিবেশে Couchbase সার্ভার চালানোর প্রতিটি দিক অন্বেষণ করব: অভ্যন্তরীণ স্থাপত্য যা HA কে সম্ভব করে তোলে, বহু-অঞ্চল স্থাপনার জন্য XDCR কনফিগারেশন, Kubernetes এর জন্য Couchbase স্বায়ত্তশাসিত অপারেটর, ক্লাউড-নির্দিষ্ট স্থাপনার জন্য, XPRX5 প্যাটার্ন এবং XPRX5 এর জন্য Couchbase স্বায়ত্তশাসিত অপারেটর। GCP GKE, Rancher এবং Longhorn-এর সাথে বেয়ার মেটাল k3s স্থাপনা, ব্যাকআপ এবং পুনরুদ্ধারের কৌশল, N1QL ক্যোয়ারী টিউনিং, সিকিউরিটি হার্ডনিং, মনিটরিং এবং Couchbase মোবাইল সিঙ্ক গেটওয়ের সাথে প্রান্ত স্থাপনের জন্য। শেষ নাগাদ, যেকোনো পরিকাঠামোতে প্রোডাকশন-গ্রেড Couchbase ক্লাস্টার স্থাপন ও পরিচালনা করার জন্য আপনার কাছে কার্যকর জ্ঞান থাকবে।
Couchbase সার্ভার আর্কিটেকচার: পরিষেবা, vBuckets, এবং স্বয়ংক্রিয় শার্ডিং
উচ্চ প্রাপ্যতার জন্য স্থাপন করার আগে Couchbase এর অভ্যন্তরীণ স্থাপত্য বোঝা গুরুত্বপূর্ণ। Couchbase একটিমাল্টি-ডাইমেনশনাল স্কেলিং (MDS)আর্কিটেকচার ব্যবহার করে যেখানে বিভিন্ন পরিষেবা স্বাধীনভাবে স্থাপন করা যায় এবং ক্লাস্টার নোড জুড়ে স্কেল করা যায়। এটি অপারেটরদের সম্পদ বরাদ্দ এবং কর্মক্ষমতা বিচ্ছিন্নতার উপর সূক্ষ্ম নিয়ন্ত্রণ দেয়।
ছয়টি মূল পরিষেবা
Couchbase সার্ভার ছয়টি সমন্বিত পরিষেবা প্রদান করে, প্রতিটি একটি স্বতন্ত্র কাজের লোড পরিচালনা করে:
- ডেটা পরিষেবা (KV)— একটি মেমরি-প্রথম আর্কিটেকচারে নির্মিত মূল কী-মানের ইঞ্জিন। এটি CRUD ক্রিয়াকলাপ পরিচালনা করে, vBucket বিতরণ পরিচালনা করে এবং অধ্যবসায় স্তর হিসাবে কাজ করে। ডেটা মেমরিতে (পরিচালিত ক্যাশে) সংরক্ষণ করা হয় এবং অসিঙ্ক্রোনাসভাবে ডিস্কে স্থায়ী হয়। এই পরিষেবাটি অবশ্যই প্রতিটি ক্লাস্টারে কমপক্ষে একটি নোডে চলবে৷
- ইনডেক্স সার্ভিস (GSI)— গ্লোবাল সেকেন্ডারি ইনডেক্সগুলি বজায় রাখে যা N1QL প্রশ্নগুলিকে সমর্থন করে৷ ইনডেক্সগুলি ডেটা থেকে আলাদাভাবে সংরক্ষণ করা হয়, স্বাধীন স্কেলিং করার অনুমতি দেয়। স্ট্যান্ডার্ড এবং মেমরি-অপ্টিমাইজ করা সূচক স্টোরেজ মোড সমর্থন করে।
- কোয়েরি সার্ভিস (N1QL)— ক্লাস্টারের বিরুদ্ধে N1QL (JSON-এর জন্য SQL++) কোয়েরি চালায়। নকশা দ্বারা রাষ্ট্রহীন, অনুভূমিকভাবে স্কেল করা সহজ করে তোলে। পরিকল্পনা এবং প্রশ্ন চালানোর জন্য ডেটা এবং সূচক পরিষেবাগুলির সাথে সমন্বয় করে।
- সার্চ সার্ভিস (FTS)— Bleve সার্চ ইঞ্জিন দ্বারা চালিত পূর্ণ-পাঠ্য অনুসন্ধান ক্ষমতা প্রদান করে। অস্পষ্ট ম্যাচিং, ভূ-স্থানীয় প্রশ্ন, মুখী অনুসন্ধান এবং কাস্টম বিশ্লেষক সমর্থন করে। সূচীগুলি সার্চ নোড জুড়ে বিভাজিত এবং প্রতিলিপি করা হয়।
- অ্যানালিটিক্স সার্ভিস (CBAS)— Apache Asterix-এর উপর ভিত্তি করে একটি সমান্তরাল প্রসেসিং ইঞ্জিন ব্যবহার করে জটিল বিশ্লেষণমূলক প্রশ্ন চালায়। বিশ্লেষণাত্মক কাজের চাপ কখনই অপারেশনাল লেটেন্সিকে প্রভাবিত করে না তা নিশ্চিত করে ডেটার নিজস্ব অনুলিপিতে কাজ করে।
- ইভেন্টিং পরিষেবা— ডেটা মিউটেশনের প্রতিক্রিয়া হিসাবে সার্ভার-সাইড JavaScript ফাংশনগুলি চালায়। বাহ্যিক অবকাঠামো ছাড়াই রিয়েল-টাইম ডেটা সমৃদ্ধকরণ, রূপান্তর, ক্যাসকেড মুছে ফেলা এবং ইন্টিগ্রেশন ট্রিগার সক্ষম করে।
vBucket বিতরণ এবং স্বয়ংক্রিয় শার্ডিং
Couchbase1024 vBuckets(ভার্চুয়াল বাকেট) ব্যবহার করে ক্লাস্টার জুড়ে ডেটা বিতরণ করে। ডকুমেন্ট কী মডিউল 1024-এর একটি CRC32 হ্যাশ ব্যবহার করে প্রতিটি নথি একটি vBucket-এ ম্যাপ করা হয়। ক্লাস্টার মানচিত্র — প্রতিটি নোড দ্বারা রক্ষণাবেক্ষণ করা হয় এবং প্রতিটি SDK ক্লায়েন্ট দ্বারা ক্যাশে করা হয় — প্রতিটি vBucketকে একটি নির্দিষ্ট নোডে ম্যাপ করে৷ এই নির্ধারক ম্যাপিং মানে ক্লায়েন্টরা সর্বদা সঠিকভাবে জানে কোন নোড কোন প্রদত্ত নথি ধারণ করে, একক-হপ রিড এবং সাব-মিলিসেকেন্ড লেটেন্সি সহ লিখতে সক্ষম করে।
যখন নোডগুলি যোগ করা হয় বা সরানো হয়, Couchbaseরিব্যালেন্সনামে একটি প্রক্রিয়ার মাধ্যমে স্বয়ংক্রিয়ভাবে vBuckets পুনরায় বিতরণ করে। পুনঃভারসাম্যের সময়, ক্লাস্টারটি সম্পূর্ণরূপে কার্যকর থাকা অবস্থায় নোডগুলির মধ্যে vBuckets সরানো হয়। সর্বদা কনফিগার করা প্রতিলিপিগুলির সংখ্যা বজায় রাখার জন্য পুনঃভারসাম্য যত্ন সহকারে সাজানো হয়, এবং ক্লায়েন্টদের ক্লাস্টার মানচিত্র আপডেটের মাধ্যমে নির্বিঘ্নে নতুন vBucket অবস্থানগুলিতে পুনঃনির্দেশিত করা হয়।
ইন্ট্রা-ক্লাস্টার রেপ্লিকেশন এবং অটো-ফেলওভার
প্রতিটি vBucket এর একটিসক্রিয়কপি এবং তিনটি পর্যন্তপ্রতিরূপকপি বিভিন্ন নোড জুড়ে বিতরণ করা হয়েছে৷ যখন একজন ক্লায়েন্ট একটি নথি লেখে, তখন লেখাটি দায়ী নোডের সক্রিয় vBucket-এ যায়। ডেটা পরিষেবা তারপর অভ্যন্তরীণDCP (ডাটাবেস পরিবর্তন প্রোটোকল)স্ট্রীমের মাধ্যমে অন্য নোডগুলিতে প্রতিরূপ vBuckets-এ মিউটেশনের প্রতিলিপি করে। ডিফল্টরূপে, Couchbase একটি প্রতিলিপি কনফিগার করে, কিন্তু উৎপাদন HA স্থাপনার জন্য, দুটি প্রতিলিপি সুপারিশ করা হয়:
# Configure bucket with 2 replicas via CLI
/opt/couchbase/bin/couchbase-cli bucket-create \
--cluster localhost:8091 \
--username Administrator \
--password password \
--bucket production-data \
--bucket-type couchbase \
--bucket-ramsize 4096 \
--bucket-replica 2 \
--bucket-priority high \
--bucket-eviction-policy valueOnly \
--enable-flush 0 \
--compression-mode active \
--max-ttl 0 \
--durability-min-level majorityAndPersistActiveঅটো-ফেলওভারহল Couchbase-এর মেকানিজম যাতে নোডের ব্যর্থতাগুলি স্বয়ংক্রিয়ভাবে সনাক্ত করা এবং পুনরুদ্ধার করা যায়। যখন একটি নোড অপ্রতিক্রিয়াশীল হয়ে যায়, তখন ক্লাস্টার অর্কেস্ট্রেটর একটি কনফিগারযোগ্য টাইমআউটের জন্য অপেক্ষা করে (ন্যূনতম 5 সেকেন্ড, উৎপাদনের জন্য প্রস্তাবিত 30 সেকেন্ড), তারপর টিকে থাকা নোডের প্রতিরূপ vBucketsকে সক্রিয় অবস্থায় উন্নীত করে। এটি কোনো অ্যাপ্লিকেশন-সাইড হস্তক্ষেপ ছাড়াই ঘটে — SDK ক্লায়েন্টরা একটি আপডেট করা ক্লাস্টার ম্যাপ গ্রহণ করে এবং অবিলম্বে নতুন সক্রিয় vBuckets-এ রুট অনুরোধ করে।
# Configure auto-failover settings
/opt/couchbase/bin/couchbase-cli setting-autofailover \
--cluster localhost:8091 \
--username Administrator \
--password password \
--enable-auto-failover 1 \
--auto-failover-timeout 30 \
--max-failovers 3 \
--enable-failover-of-server-groups 1 \
--failover-on-data-disk-issues 1 \
--failover-data-disk-period 120 \
--can-abort-rebalance 1কী অটো-ফেলওভার প্যারামিটার:
- অটো-ফেলওভার-টাইমআউট— ফেইলওভার ট্রিগার করার আগে অপেক্ষা করতে সেকেন্ড। নিম্ন মান ডাউনটাইম কমায় কিন্তু মিথ্যা-ইতিবাচক ঝুঁকি বাড়ায়। 30 সেকেন্ড প্রস্তাবিত উত্পাদন সেটিং।
- max-failovers— ম্যানুয়াল হস্তক্ষেপের প্রয়োজনের আগে সর্বাধিক সংখ্যক অনুক্রমিক অটো-ফেলওভার। একটি 5-নোড ক্লাস্টারের জন্য 3 এ সেট করুন (কোরাম বজায় রাখার জন্য)।
- সক্ষম-ফেলওভার-অফ-সার্ভার-গ্রুপ— একটি সম্পূর্ণ সার্ভার গ্রুপের ব্যর্থতা সক্ষম করে (র্যাক/জোন), জোন-সচেতন স্থাপনার জন্য গুরুত্বপূর্ণ।
- ফেইলওভার-অন-ডেটা-ডিস্ক-ইস্যু— ডেটা পরিষেবা যখন ক্রমাগত ডিস্ক I/O ত্রুটি সনাক্ত করে তখন ব্যর্থতা ট্রিগার করে৷
XDCR: ক্রস ডেটা সেন্টার রেপ্লিকেশন
XDCR হল Couchbase এর ফ্ল্যাগশিপ মাল্টি-রিজিওন রেপ্লিকেশন প্রযুক্তি। ঐতিহ্যগত RDBMS সিস্টেমে পাওয়া ডাটাবেস-স্তরের প্রতিলিপির বিপরীতে, XDCRবালতি স্তর-এ কাজ করে এবং স্বাধীন Couchbase ক্লাস্টারগুলির মধ্যে পৃথক নথির মিউটেশনগুলি প্রবাহিত করে। প্রতিটি ক্লাস্টার সম্পূর্ণ স্বায়ত্তশাসিত থাকে — এটি স্বাধীনভাবে পঠন এবং লিখতে গ্রহণ করতে পারে, XDCR কে সক্রিয়-সক্রিয় বহু-অঞ্চল স্থাপনার জন্য আদর্শ করে তোলে যেখানে ব্যবহারকারীদের যেকোনো ভূগোল থেকে স্বল্প-বিলম্বিত অ্যাক্সেসের প্রয়োজন হয়।
একমুখী বনাম দ্বিমুখী XDCR
Unidirectional XDCRএকটি সোর্স ক্লাস্টার থেকে একটি টার্গেট ক্লাস্টারে মিউটেশনের প্রতিলিপি করে। এটি দুর্যোগ পুনরুদ্ধারের পরিস্থিতির জন্য উপযুক্ত, প্রত্যন্ত অঞ্চলে প্রতিলিপিগুলি পড়তে, বা একটি অপারেশনাল ক্লাস্টার থেকে একটি বিশ্লেষণ ক্লাস্টারে ডেটা ফিড করার জন্য।
দ্বিমুখী XDCRদুটি ক্লাস্টারের মধ্যে উভয় দিকের প্রতিলিপি লিঙ্ক তৈরি করে, সক্রিয়-সক্রিয় স্থাপনা সক্ষম করে যেখানে উভয় ক্লাস্টারই লেখা গ্রহণ করে। এটি সবচেয়ে শক্তিশালী কনফিগারেশন কিন্তু সতর্ক দ্বন্দ্ব সমাধান পরিকল্পনা প্রয়োজন।
XDCR রেপ্লিকেশন
সেট আপ করা হচ্ছেXDCR কনফিগার করার জন্য একটি দূরবর্তী ক্লাস্টার রেফারেন্স তৈরি করা এবং তারপর বালতি স্তরে প্রতিলিপি লিঙ্কগুলি সংজ্ঞায়িত করা জড়িত। নীচে একটি সম্পূর্ণ দ্বিমুখী সেটআপের জন্য CLI কমান্ড এবং REST API কল রয়েছে:
# Step 1: Create remote cluster reference on the US-EAST cluster
/opt/couchbase/bin/couchbase-cli xdcr-setup \
--cluster cb-us-east.example.com:8091 \
--username Administrator \
--password password \
--create \
--xdcr-cluster-name eu-west-cluster \
--xdcr-hostname cb-eu-west.example.com:8091 \
--xdcr-username Administrator \
--xdcr-password password \
--xdcr-demand-encryption 1 \
--xdcr-encryption-type full \
--xdcr-certificate /path/to/eu-west-ca.pem
# Step 2: Create replication from US-EAST to EU-WEST for the 'app' bucket
/opt/couchbase/bin/couchbase-cli xdcr-replicate \
--cluster cb-us-east.example.com:8091 \
--username Administrator \
--password password \
--create \
--xdcr-cluster-name eu-west-cluster \
--xdcr-from-bucket app \
--xdcr-to-bucket app \
--xdcr-replication-mode xmem \
--enable-compression 1 \
--filter-expression "" \
--priority high \
--network-usage-limit 0
# Step 3: Create the reverse replication on EU-WEST cluster (bidirectional)
/opt/couchbase/bin/couchbase-cli xdcr-setup \
--cluster cb-eu-west.example.com:8091 \
--username Administrator \
--password password \
--create \
--xdcr-cluster-name us-east-cluster \
--xdcr-hostname cb-us-east.example.com:8091 \
--xdcr-username Administrator \
--xdcr-password password \
--xdcr-demand-encryption 1 \
--xdcr-encryption-type full \
--xdcr-certificate /path/to/us-east-ca.pem
/opt/couchbase/bin/couchbase-cli xdcr-replicate \
--cluster cb-eu-west.example.com:8091 \
--username Administrator \
--password password \
--create \
--xdcr-cluster-name us-east-cluster \
--xdcr-from-bucket app \
--xdcr-to-bucket app \
--xdcr-replication-mode xmem \
--enable-compression 1দ্বন্দ্ব সমাধানের কৌশল
দ্বিমুখী XDCR-এ, একই নথি একই সাথে বিভিন্ন ক্লাস্টারে পরিবর্তন করা যেতে পারে, বিরোধ তৈরি করে। Couchbase একাধিক দ্বন্দ্ব সমাধানের কৌশল প্রদান করে:
- টাইমস্ট্যাম্প-ভিত্তিক (LWW — লাস্ট রাইট উইনস)— সাম্প্রতিক টাইমস্ট্যাম্প জয়ের মিউটেশন। এটি ডিফল্ট এবং বেশিরভাগ ব্যবহারের ক্ষেত্রে ভাল কাজ করে। সমস্ত ক্লাস্টার জুড়ে NTP সিঙ্ক্রোনাইজেশন প্রয়োজন (5 সেকেন্ডের মধ্যে তির্যক)। বালতি তৈরির সময় সেট করুন এবং পরে পরিবর্তন করা যাবে না।
- সিকোয়েন্স নম্বর-ভিত্তিক— বিজয়ী নির্ধারণ করতে অভ্যন্তরীণ সিকোয়েন্স নম্বর (রিভিশন আইডি) ব্যবহার করে। উচ্চতর পুনর্বিবেচনা গণনার সাথে মিউটেশন জয়ী হয়। টাইমস্ট্যাম্প সিঙ্ক্রোনাইজেশন অবিশ্বস্ত হলে দরকারী।
- কাস্টম কনফ্লিক্ট রেজোলিউশন (এন্টারপ্রাইজ)— Couchbase এন্টারপ্রাইজ সংস্করণ কাস্টম মার্জ ফাংশন সমর্থন করে যা সার্ভার-সাইড JavaScript এক্সিকিউট করে অ্যাপ্লিকেশান-নির্দিষ্ট যুক্তির সাথে দ্বন্দ্ব সমাধান করতে। এটি বিভিন্ন অঞ্চল থেকে শপিং কার্ট আইটেমগুলিকে একত্রিত করা বা ডোমেন-নির্দিষ্ট দ্বন্দ্ব সমাধানের নিয়ম প্রয়োগ করার মতো পরিস্থিতিগুলিকে সক্ষম করে৷
# Create a bucket with timestamp-based conflict resolution
curl -X POST http://localhost:8091/pools/default/buckets \
-u Administrator:password \
-d name=app \
-d ramQuota=4096 \
-d replicaNumber=2 \
-d bucketType=couchbase \
-d conflictResolutionType=lww \
-d compressionMode=active \
-d durabilityMinLevel=majorityAndPersistActive
# XDCR advanced settings via REST API
curl -X POST http://localhost:8091/settings/replications/<replication-id> \
-u Administrator:password \
-d optimisticReplicationThreshold=256 \
-d sourceNozzlePerNode=4 \
-d targetNozzlePerNode=4 \
-d checkpointInterval=600 \
-d batchCount=500 \
-d batchSize=2048 \
-d failureRestartInterval=10 \
-d docBatchSizeKb=2048 \
-d networkUsageLimit=0 \
-d priority=HighXDCR ফিল্টারিং
XDCR ফিল্টারিং সমর্থন করে যাতে আপনি নথির শুধুমাত্র একটি উপসেট প্রতিলিপি করতে পারেন। ফিল্টারগুলি ডকুমেন্ট কীগুলির বিরুদ্ধে নিয়মিত এক্সপ্রেশন ব্যবহার করে এবং ডকুমেন্টের মেয়াদ শেষ হওয়া বা মুছে ফেলার উপর ভিত্তি করে ফিল্টার করতে পারে:
# Replicate only documents with keys starting with 'user::'
/opt/couchbase/bin/couchbase-cli xdcr-replicate \
--cluster localhost:8091 \
--username Administrator \
--password password \
--create \
--xdcr-cluster-name remote-cluster \
--xdcr-from-bucket app \
--xdcr-to-bucket app-users \
--filter-expression "^user::" \
--filter-skip-restream 0
# Replicate documents matching a complex pattern
# (orders from 2026 with specific type)
--filter-expression "REGEXP_CONTAINS(META().id, '^order::2026') AND type='premium'"Kubernetesএর জন্যCouchbase স্বায়ত্তশাসিত অপারেটর
Couchbase অটোনোমাস অপারেটর (CAO)হল একটি এন্টারপ্রাইজ-গ্রেড Kubernetes অপারেটর যেটি Couchbase সার্ভার ক্লাস্টারগুলির স্থাপনা, ব্যবস্থাপনা, স্কেলিং এবং পুনরুদ্ধার স্বয়ংক্রিয় করে। সাধারণ স্টেটফুলসেট স্থাপনার বিপরীতে, স্বায়ত্তশাসিত অপারেটর Couchbase-এর অভ্যন্তরীণ টপোলজি বোঝে — এটি রিব্যালেন্স অপারেশন পরিচালনা করে, রোলিং আপগ্রেডগুলি সমন্বয় করে, সার্ভার গ্রুপ সচেতনতা পরিচালনা করে এবং Couchbase পডগুলির সর্বোত্তম স্থান নির্ধারণের জন্য Kubernetes শিডিউলিং আদিমগুলির সাথে সংহত করে৷
CouchbaseCluster CRD স্পেসিফিকেশন
CouchbaseCluster CRD হল কেন্দ্রীয় কনফিগারেশন যা আপনার Couchbase স্থাপনার পছন্দসই অবস্থা ঘোষণা করে। স্বায়ত্তশাসিত অপারেটর এটিকে স্টেটফুলসেট, পরিষেবা, PVC, গোপনীয়তা এবং RBAC সংস্থানগুলির মধ্যে সমন্বয় করে। নীচে একটি উত্পাদন-প্রস্তুত CRD:
apiVersion: couchbase.com/v2
kind: CouchbaseCluster
metadata:
name: cb-production
namespace: couchbase
spec:
image: couchbase/server:7.6.1-enterprise
antiAffinity: true
platform: aws
cluster:
autoFailoverTimeout: 30s
autoFailoverMaxCount: 3
autoFailoverOnDataDiskIssues: true
autoFailoverOnDataDiskIssuesTimePeriod: 120s
autoFailoverServerGroup: true
clusterName: cb-production
dataServiceMemoryQuota: 8Gi
indexServiceMemoryQuota: 4Gi
searchServiceMemoryQuota: 2Gi
analyticsServiceMemoryQuota: 4Gi
eventingServiceMemoryQuota: 2Gi
indexStorageSetting: memory_optimized
autoCompaction:
databaseFragmentationThreshold:
percent: 30
size: 1Gi
viewFragmentationThreshold:
percent: 30
size: 1Gi
parallelCompaction: false
timeWindow:
start: "02:00"
end: "06:00"
abortCompactionOutsideWindow: true
security:
adminSecret: cb-admin-credentials
rbac:
managed: true
selector:
matchLabels:
cluster: cb-production
ldap:
hosts:
- ldap.example.com
port: 636
encryption: TLS
networking:
tls:
static:
serverSecret: couchbase-server-tls
operatorSecret: couchbase-operator-tls
exposeAdminConsole: true
adminConsoleServices:
- data
adminConsoleServiceType: NodePort
exposedFeatures:
- client
- xdcr
exposedFeatureServiceType: NodePort
buckets:
managed: true
selector:
matchLabels:
cluster: cb-production
servers:
- name: data-zone-a
size: 2
services:
- data
- index
serverGroups:
- zone-a
pod:
metadata:
labels:
couchbase-service: data-index
annotations:
prometheus.io/scrape: "true"
prometheus.io/port: "9091"
spec:
nodeSelector:
topology.kubernetes.io/zone: us-east-1a
tolerations:
- key: couchbase
operator: Equal
value: "true"
effect: NoSchedule
resources:
requests:
cpu: "4"
memory: 16Gi
limits:
cpu: "8"
memory: 20Gi
volumeMounts:
default: couchbase-data
data: couchbase-data
index: couchbase-index
- name: data-zone-b
size: 2
services:
- data
- index
serverGroups:
- zone-b
pod:
spec:
nodeSelector:
topology.kubernetes.io/zone: us-east-1b
tolerations:
- key: couchbase
operator: Equal
value: "true"
effect: NoSchedule
resources:
requests:
cpu: "4"
memory: 16Gi
limits:
cpu: "8"
memory: 20Gi
volumeMounts:
default: couchbase-data
data: couchbase-data
index: couchbase-index
- name: query-search
size: 2
services:
- query
- search
serverGroups:
- zone-a
- zone-b
pod:
spec:
resources:
requests:
cpu: "4"
memory: 8Gi
limits:
cpu: "8"
memory: 12Gi
volumeMounts:
default: couchbase-default
- name: analytics-eventing
size: 2
services:
- analytics
- eventing
serverGroups:
- zone-c
pod:
spec:
nodeSelector:
topology.kubernetes.io/zone: us-east-1c
resources:
requests:
cpu: "8"
memory: 32Gi
limits:
cpu: "16"
memory: 40Gi
volumeMounts:
default: couchbase-analytics
analytics:
- couchbase-analytics
serverGroups:
- zone-a
- zone-b
- zone-c
volumeClaimTemplates:
- metadata:
name: couchbase-data
spec:
storageClassName: ebs-gp3-couchbase
resources:
requests:
storage: 100Gi
- metadata:
name: couchbase-index
spec:
storageClassName: ebs-gp3-couchbase
resources:
requests:
storage: 50Gi
- metadata:
name: couchbase-default
spec:
storageClassName: ebs-gp3-couchbase
resources:
requests:
storage: 20Gi
- metadata:
name: couchbase-analytics
spec:
storageClassName: ebs-gp3-couchbase
resources:
requests:
storage: 200GiHelmএর মাধ্যমেঅপারেটর ইনস্টলেশন# Add Couchbase Helm repository
helm repo add couchbase https://couchbase-partners.github.io/helm-charts/
helm repo update
# Install the Couchbase Autonomous Operator
helm install couchbase-operator couchbase/couchbase-operator \
--namespace couchbase \
--create-namespace \
--set operator.image.repository=couchbase/operator \
--set operator.image.tag=2.7.1 \
--set admissionController.enabled=true
# Create the admin credentials secret
kubectl create secret generic cb-admin-credentials \
--namespace couchbase \
--from-literal=username=Administrator \
--from-literal=password=$(openssl rand -base64 24)
# Deploy the CouchbaseCluster CRD
kubectl apply -f couchbase-cluster.yaml
# Verify deployment
kubectl get couchbaseclusters -n couchbase
kubectl get pods -n couchbase -l app=couchbase
kubectl get svc -n couchbase
সার্ভার গ্রুপ এবং র্যাক/জোন সচেতনতা
# Add Couchbase Helm repository
helm repo add couchbase https://couchbase-partners.github.io/helm-charts/
helm repo update
# Install the Couchbase Autonomous Operator
helm install couchbase-operator couchbase/couchbase-operator \
--namespace couchbase \
--create-namespace \
--set operator.image.repository=couchbase/operator \
--set operator.image.tag=2.7.1 \
--set admissionController.enabled=true
# Create the admin credentials secret
kubectl create secret generic cb-admin-credentials \
--namespace couchbase \
--from-literal=username=Administrator \
--from-literal=password=$(openssl rand -base64 24)
# Deploy the CouchbaseCluster CRD
kubectl apply -f couchbase-cluster.yaml
# Verify deployment
kubectl get couchbaseclusters -n couchbase
kubectl get pods -n couchbase -l app=couchbase
kubectl get svc -n couchbaseসার্ভার গ্রুপগুলি হল Couchbase এর প্রক্রিয়া যা নিশ্চিত করে যে সক্রিয় vBuckets এবং তাদের প্রতিলিপিগুলি বিভিন্ন ব্যর্থতা ডোমেনে (উপলভ্যতা অঞ্চল, র্যাক বা ডেটা সেন্টার) স্থাপন করা হয়েছে। যখন সার্ভার গ্রুপ কনফিগার করা হয়, Couchbase গ্যারান্টি দেয় যে একই সার্ভার গ্রুপে একই vBucket-এর জন্য কোনো সক্রিয় এবং প্রতিলিপি জোড়া থাকবে না। এর মানে একটি সম্পূর্ণ জোন ব্যর্থতার ফলে ডেটা ক্ষতি হবে না।
অটোনোমাস অপারেটর সার্ভার গ্রুপগুলিকে Kubernetes নোড টপোলজি লেবেলে ম্যাপ করে, সঠিক জোনে স্বয়ংক্রিয়ভাবে পড নির্ধারণ করে। পড অ্যান্টি-অ্যাফিনিটি নিয়মের সাথে মিলিত, এটি নিশ্চিত করে যে Couchbase পডগুলি সর্বাধিক স্থিতিস্থাপকতার জন্য শারীরিক পরিকাঠামো জুড়ে বিতরণ করা হয়েছে।
AWS EKS স্থাপনা
Amazon EKS-এর সর্বোত্তম Couchbase পারফরম্যান্সের জন্য নির্দিষ্ট কনফিগারেশন প্রয়োজন। মূল বিবেচ্য বিষয়গুলি হল স্টোরেজ (থ্রুপুটের জন্য EBS gp3), উদাহরণের ধরন (ডেটা নোডের জন্য মেমরি-অপ্টিমাইজ করা r6i/r7i), এবং নেটওয়ার্কিং (পড-লেভেল নেটওয়ার্কিংয়ের জন্য VPC CNI)।
# EBS gp3 StorageClass optimized for Couchbase
apiVersion: storage.k8s.io/v1
kind: StorageClass
metadata:
name: ebs-gp3-couchbase
provisioner: ebs.csi.aws.com
parameters:
type: gp3
iops: "6000"
throughput: "500"
encrypted: "true"
kmsKeyId: "arn:aws:kms:us-east-1:123456789:key/mrk-abcdef"
reclaimPolicy: Retain
volumeBindingMode: WaitForFirstConsumer
allowVolumeExpansion: true
---
# Recommended EKS node groups for Couchbase
# Data nodes: r6i.2xlarge (8 vCPU, 64 GiB) or r7i.2xlarge
# Index/Query: m6i.2xlarge (8 vCPU, 32 GiB)
# Analytics: r6i.4xlarge (16 vCPU, 128 GiB)
# Eventing: m6i.xlarge (4 vCPU, 16 GiB)
# EKS managed node group with taints for Couchbase
apiVersion: eksctl.io/v1alpha5
kind: ClusterConfig
metadata:
name: couchbase-eks
region: us-east-1
managedNodeGroups:
- name: cb-data
instanceType: r6i.2xlarge
desiredCapacity: 4
minSize: 4
maxSize: 8
volumeSize: 200
volumeType: gp3
volumeIOPS: 6000
volumeThroughput: 500
availabilityZones: ["us-east-1a", "us-east-1b"]
labels:
workload: couchbase-data
taints:
- key: couchbase
value: "true"
effect: NoSchedule
iam:
attachPolicyARNs:
- arn:aws:iam::policy/AmazonEBSCSIDriverPolicy
- name: cb-query
instanceType: m6i.2xlarge
desiredCapacity: 2
minSize: 2
maxSize: 4
availabilityZones: ["us-east-1a", "us-east-1b"]
labels:
workload: couchbase-queryAzure AKS স্থাপনা
Azure AKS Couchbase-এর I/O চাহিদাগুলির জন্য প্রিমিয়াম SSD v2 বা আল্ট্রা ডিস্ক এবং অঞ্চলগুলির মধ্যে নিরাপদ XDCR সংযোগের জন্য Azure ব্যক্তিগত লিঙ্ক ব্যবহার করে৷
# Azure Premium SSD v2 StorageClass
apiVersion: storage.k8s.io/v1
kind: StorageClass
metadata:
name: azure-premium-couchbase
provisioner: disk.csi.azure.com
parameters:
skuName: PremiumV2_LRS
DiskIOPSReadWrite: "6000"
DiskMBpsReadWrite: "500"
cachingMode: None
reclaimPolicy: Retain
volumeBindingMode: WaitForFirstConsumer
allowVolumeExpansion: true
---
# Ultra Disk StorageClass for high-performance workloads
apiVersion: storage.k8s.io/v1
kind: StorageClass
metadata:
name: azure-ultra-couchbase
provisioner: disk.csi.azure.com
parameters:
skuName: UltraSSD_LRS
DiskIOPSReadWrite: "10000"
DiskMBpsReadWrite: "1000"
cachingMode: None
reclaimPolicy: Retain
volumeBindingMode: WaitForFirstConsumer
allowVolumeExpansion: true
---
# AKS recommended VM sizes:
# Data nodes: Standard_E8s_v5 (8 vCPU, 64 GiB)
# Index/Query: Standard_D8s_v5 (8 vCPU, 32 GiB)
# Analytics: Standard_E16s_v5 (16 vCPU, 128 GiB)GCP GKE ডিপ্লয়মেন্ট
Google Kubernetes ইঞ্জিন ব্যাকআপের জন্য Google ক্লাউড স্টোরেজে নিরাপদ অ্যাক্সেসের জন্য SSD পারসিস্টেন্ট ডিস্ক এবং ওয়ার্কলোড আইডেন্টিটি ব্যবহার করে।
# GKE SSD Persistent Disk StorageClass
apiVersion: storage.k8s.io/v1
kind: StorageClass
metadata:
name: ssd-couchbase
provisioner: pd.csi.storage.gke.io
parameters:
type: pd-ssd
provisioned-iops-on-create: "6000"
provisioned-throughput-on-create: "500"
reclaimPolicy: Retain
volumeBindingMode: WaitForFirstConsumer
allowVolumeExpansion: true
---
# GKE Hyperdisk Balanced for cost-effective performance
apiVersion: storage.k8s.io/v1
kind: StorageClass
metadata:
name: hyperdisk-couchbase
provisioner: pd.csi.storage.gke.io
parameters:
type: hyperdisk-balanced
provisioned-iops-on-create: "6000"
provisioned-throughput-on-create: "500"
reclaimPolicy: Retain
volumeBindingMode: WaitForFirstConsumer
allowVolumeExpansion: true
---
# GKE recommended machine types:
# Data nodes: n2-highmem-8 (8 vCPU, 64 GB)
# Index/Query: n2-standard-8 (8 vCPU, 32 GB)
# Analytics: n2-highmem-16 (16 vCPU, 128 GB)বেয়ার মেটাল k3s/Rancher লংহর্ন
সহযে সংস্থাগুলির জন্য ক্লাউড ভেন্ডর লক-ইন ছাড়া সম্পূর্ণ অবকাঠামো নিয়ন্ত্রণের প্রয়োজন, বেয়ার মেটাল k3s রাঞ্চার ম্যানেজমেন্ট এবং লংহর্ন ডিস্ট্রিবিউটেড স্টোরেজ Couchbase HA-এর জন্য একটি চমৎকার ভিত্তি প্রদান করে। এই স্থাপত্যটি নিয়ন্ত্রিত শিল্প, প্রান্ত কম্পিউটিং পরিস্থিতি এবং খরচ-সংবেদনশীল পরিবেশে জনপ্রিয়।
# k3s bare metal setup for Couchbase
# Install k3s on master nodes (HA with embedded etcd)
curl -sfL https://get.k3s.io | sh -s - server \
--cluster-init \
--disable traefik \
--disable servicelb \
--write-kubeconfig-mode 644 \
--node-taint couchbase=true:NoSchedule \
--node-label topology.kubernetes.io/zone=rack-1
# Join additional server nodes
curl -sfL https://get.k3s.io | sh -s - server \
--server https://master-1:6443 \
--token $(cat /var/lib/rancher/k3s/server/node-token) \
--node-taint couchbase=true:NoSchedule \
--node-label topology.kubernetes.io/zone=rack-2
# Join agent nodes
curl -sfL https://get.k3s.io | sh -s - agent \
--server https://master-1:6443 \
--token $(cat /var/lib/rancher/k3s/server/node-token) \
--node-taint couchbase=true:NoSchedule \
--node-label topology.kubernetes.io/zone=rack-3
# Install Longhorn for distributed storage
helm repo add longhorn https://charts.longhorn.io
helm install longhorn longhorn/longhorn \
--namespace longhorn-system \
--create-namespace \
--set defaultSettings.defaultReplicaCount=3 \
--set defaultSettings.defaultDataPath=/mnt/longhorn \
--set defaultSettings.guaranteedInstanceManagerCPU=12
# Create Longhorn StorageClass for Couchbase
kubectl apply -f - <ব্যাকআপ এবং cbbackupmgr
দিয়ে পুনরুদ্ধার করুনCouchbasecbbackupmgrপ্রদান করে, একটি এন্টারপ্রাইজ ব্যাকআপ টুল যা ঐচ্ছিক কম্প্রেশন এবং এনক্রিপশন সহ সম্পূর্ণ, বর্ধিত এবং ডিফারেনশিয়াল ব্যাকআপ সমর্থন করে। উৎপাদন HA স্থাপনার জন্য, একটি শক্তিশালী ব্যাকআপ কৌশল Couchbase-স্তরের ব্যাকআপগুলিকে ক্লাউড স্ন্যাপশট ক্ষমতার সাথে একত্রিত করে।
ব্যাকআপ কনফিগারেশন
# Initialize a backup repository
/opt/couchbase/bin/cbbackupmgr config \
--archive /backup/couchbase \
--repo production-backup \
--include-data production-data \
--include-data user-profiles \
--exclude-data _system
# Run a full backup
/opt/couchbase/bin/cbbackupmgr backup \
--archive /backup/couchbase \
--repo production-backup \
--cluster couchbase://localhost \
--username Administrator \
--password "$CB_PASSWORD" \
--threads 4 \
--no-progress-bar
# Run an incremental backup (only mutations since last backup)
/opt/couchbase/bin/cbbackupmgr backup \
--archive /backup/couchbase \
--repo production-backup \
--cluster couchbase://localhost \
--username Administrator \
--password "$CB_PASSWORD" \
--threads 4
# List available backups
/opt/couchbase/bin/cbbackupmgr list \
--archive /backup/couchbase \
--repo production-backup
# Restore from a specific backup
/opt/couchbase/bin/cbbackupmgr restore \
--archive /backup/couchbase \
--repo production-backup \
--cluster couchbase://target-cluster:8091 \
--username Administrator \
--password "$CB_PASSWORD" \
--start 2026-04-12T00_00_00 \
--end 2026-04-12T14_30_00 \
--threads 4Kubernetesএর জন্যস্বয়ংক্রিয় ব্যাকআপ স্ক্রিপ্ট#!/bin/bash
# couchbase-backup.sh — Automated backup to S3-compatible storage
set -euo pipefail
CLUSTER_HOST="cb-production-srv.couchbase.svc.cluster.local"
BACKUP_DIR="/backup/couchbase"
REPO_NAME="prod-$(date +%Y%m%d)"
S3_BUCKET="s3://couchbase-backups/production"
RETENTION_DAYS=14
log() { echo "[$(date +'%Y-%m-%d %H:%M:%S')] $*"; }
log "Starting Couchbase backup for cluster: $CLUSTER_HOST"
if [ ! -d "$BACKUP_DIR/$REPO_NAME" ]; then
log "Configuring new backup repository: $REPO_NAME"
cbbackupmgr config \
--archive "$BACKUP_DIR" \
--repo "$REPO_NAME" \
--include-data production-data \
--include-data user-profiles
fi
log "Running incremental backup..."
cbbackupmgr backup \
--archive "$BACKUP_DIR" \
--repo "$REPO_NAME" \
--cluster "couchbase://$CLUSTER_HOST" \
--username "$CB_USERNAME" \
--password "$CB_PASSWORD" \
--threads 4 \
--no-progress-bar
BACKUP_SIZE=$(du -sh "$BACKUP_DIR/$REPO_NAME" | cut -f1)
log "Backup complete. Size: $BACKUP_SIZE"
log "Syncing to S3: $S3_BUCKET/$REPO_NAME"
aws s3 sync "$BACKUP_DIR/$REPO_NAME" "$S3_BUCKET/$REPO_NAME" \
--storage-class STANDARD_IA \
--sse aws:kms
log "Cleaning up backups older than $RETENTION_DAYS days..."
find "$BACKUP_DIR" -maxdepth 1 -name "prod-*" -mtime +"$RETENTION_DAYS" -exec rm -rf {} \;
log "Backup pipeline complete."
Couchbaseব্যাকআপ CRD (অপারেটর-পরিচালিত)
#!/bin/bash
# couchbase-backup.sh — Automated backup to S3-compatible storage
set -euo pipefail
CLUSTER_HOST="cb-production-srv.couchbase.svc.cluster.local"
BACKUP_DIR="/backup/couchbase"
REPO_NAME="prod-$(date +%Y%m%d)"
S3_BUCKET="s3://couchbase-backups/production"
RETENTION_DAYS=14
log() { echo "[$(date +'%Y-%m-%d %H:%M:%S')] $*"; }
log "Starting Couchbase backup for cluster: $CLUSTER_HOST"
if [ ! -d "$BACKUP_DIR/$REPO_NAME" ]; then
log "Configuring new backup repository: $REPO_NAME"
cbbackupmgr config \
--archive "$BACKUP_DIR" \
--repo "$REPO_NAME" \
--include-data production-data \
--include-data user-profiles
fi
log "Running incremental backup..."
cbbackupmgr backup \
--archive "$BACKUP_DIR" \
--repo "$REPO_NAME" \
--cluster "couchbase://$CLUSTER_HOST" \
--username "$CB_USERNAME" \
--password "$CB_PASSWORD" \
--threads 4 \
--no-progress-bar
BACKUP_SIZE=$(du -sh "$BACKUP_DIR/$REPO_NAME" | cut -f1)
log "Backup complete. Size: $BACKUP_SIZE"
log "Syncing to S3: $S3_BUCKET/$REPO_NAME"
aws s3 sync "$BACKUP_DIR/$REPO_NAME" "$S3_BUCKET/$REPO_NAME" \
--storage-class STANDARD_IA \
--sse aws:kms
log "Cleaning up backups older than $RETENTION_DAYS days..."
find "$BACKUP_DIR" -maxdepth 1 -name "prod-*" -mtime +"$RETENTION_DAYS" -exec rm -rf {} \;
log "Backup pipeline complete."স্বয়ংক্রিয় ব্যাকআপ পরিচালনার জন্য স্বায়ত্তশাসিত অপারেটর CRD প্রদান করে:
apiVersion: couchbase.com/v2
kind: CouchbaseBackup
metadata:
name: cb-daily-backup
namespace: couchbase
spec:
strategy: full_incremental
full:
schedule: "0 2 * * 0" # Full backup every Sunday at 2 AM
incremental:
schedule: "0 2 * * 1-6" # Incremental Mon-Sat at 2 AM
successfulJobsHistoryLimit: 5
failedJobsHistoryLimit: 3
backOffLimit: 3
logRetention: 168h
size: 100Gi
s3bucket: s3://couchbase-backups/production
---
apiVersion: couchbase.com/v2
kind: CouchbaseBackupRestore
metadata:
name: cb-restore-pitr
namespace: couchbase
spec:
backup: cb-daily-backup
repo: "20260412"
start:
int: 1
end:
int: 5
backOffLimit: 3N1QL কোয়েরি পারফরম্যান্স টিউনিং
৷N1QL (JSON-এর জন্য SQL++) হল Couchbase-এর কোয়েরি ভাষা। N1QL পারফরম্যান্স টিউন করার জন্য ক্যোয়ারী প্ল্যানার, সূচক ডিজাইন এবং সার্ভার-সাইড অপ্টিমাইজেশন বোঝার প্রয়োজন।
সূচক কৌশল: GSI এবং FTS
-- Global Secondary Index (GSI) for common query patterns
-- Composite index for user lookups
CREATE INDEX idx_users_email_status
ON `user-profiles`(email, status)
WHERE type = 'user'
WITH {"num_replica": 1, "defer_build": false};
-- Covering index (includes all queried fields to avoid fetch)
CREATE INDEX idx_orders_covering
ON `production-data`(customer_id, order_date, total_amount, status)
WHERE type = 'order'
WITH {"num_replica": 1};
-- Array index for nested documents
CREATE INDEX idx_order_items
ON `production-data`(DISTINCT ARRAY item.product_id FOR item IN items END)
WHERE type = 'order'
WITH {"num_replica": 1};
-- Partial index for active records only
CREATE INDEX idx_active_sessions
ON `production-data`(user_id, created_at)
WHERE type = 'session' AND status = 'active'
WITH {"num_replica": 1};
-- Adaptive index for dynamic query patterns
CREATE INDEX idx_adaptive_products
ON `production-data`(DISTINCT PAIRS(self))
WHERE type = 'product'
WITH {"num_replica": 1};
-- Check index status
SELECT name, state, num_docs_indexed, num_docs_pending
FROM system:indexes
WHERE keyspace_id = 'production-data';
-- Analyze query execution plan
EXPLAIN SELECT u.name, u.email, COUNT(o.id) AS order_count
FROM `user-profiles` u
JOIN `production-data` o ON o.customer_id = u.id
WHERE u.status = 'active' AND o.type = 'order'
GROUP BY u.name, u.email
ORDER BY order_count DESC
LIMIT 100;
-- Use ADVISE to get index recommendations
ADVISE SELECT * FROM `production-data`
WHERE type = 'order'
AND customer_id = 'cust-12345'
AND order_date BETWEEN '2026-01-01' AND '2026-04-12'
ORDER BY order_date DESC;ক্যোয়ারী অপ্টিমাইজেশান টিপস
৷-- Use PREPARE for frequently executed queries (cached plan)
PREPARE get_user_orders AS
SELECT o.id, o.order_date, o.total_amount, o.status
FROM `production-data` o
WHERE o.type = 'order'
AND o.customer_id = $customer_id
ORDER BY o.order_date DESC
LIMIT $page_size OFFSET $page_offset;
-- Execute prepared statement
EXECUTE get_user_orders
USING {"customer_id": "cust-12345", "page_size": 20, "page_offset": 0};
-- Use META().id for direct key-value lookups (fastest path)
SELECT META().id, *
FROM `production-data`
USE KEYS ["order::2026-001", "order::2026-002", "order::2026-003"];
-- Correlated subquery with USE KEYS for joins
SELECT u.name,
(SELECT o.id, o.total_amount
FROM `production-data` o
USE KEYS u.order_ids
WHERE o.status = 'completed') AS completed_orders
FROM `user-profiles` u
WHERE META(u).id = 'user::12345';
-- Use INFER to understand document schema
INFER `production-data` WITH {"sample_size": 10000, "similarity_metric": 0.6};মেমরি ম্যানেজমেন্ট এবং বাকেট কনফিগারেশন
Couchbase এর মেমরি-প্রথম আর্কিটেকচার মানে RAM বরাদ্দ সরাসরি কর্মক্ষমতা প্রভাবিত করে। প্রতিটি পরিষেবার নিজস্ব মেমরি কোটা রয়েছে এবং বালতিগুলি ডেটা পরিষেবা কোটা ভাগ করে নেয়৷ সঠিক মাপ ক্যাশে উচ্ছেদ প্রতিরোধ করে যা লেটেন্সি হ্রাস করে।
# Configure cluster-level memory quotas
/opt/couchbase/bin/couchbase-cli setting-cluster \
--cluster localhost:8091 \
--username Administrator \
--password password \
--cluster-ramsize 8192 \
--cluster-index-ramsize 4096 \
--cluster-fts-ramsize 2048 \
--cluster-eventing-ramsize 2048 \
--cluster-analytics-ramsize 4096
# Memory allocation guidelines:
# Data Service: 60% of available node RAM
# Index Service: 20% of available node RAM
# Search Service: 10% of available node RAM
# OS/overhead: 10% reserved
# Bucket memory sizing formula:
# Required RAM = (avg_doc_size * num_docs * 2.5) / num_data_nodes
# The 2.5 multiplier accounts for:
# - Metadata overhead (~56 bytes per document)
# - Internal fragmentation
# - Replica copies in memory
# Create an optimized production bucket
curl -X POST http://localhost:8091/pools/default/buckets \
-u Administrator:password \
-d name=production-data \
-d ramQuota=4096 \
-d bucketType=couchbase \
-d replicaNumber=2 \
-d threadsNumber=8 \
-d evictionPolicy=valueOnly \
-d compressionMode=active \
-d maxTTL=0 \
-d conflictResolutionType=lww \
-d flushEnabled=0 \
-d durabilityMinLevel=majorityAndPersistActive
# Eviction policies:
# valueOnly - Evicts document values but keeps metadata in RAM
# Best for workloads where key access patterns are predictable
# fullEviction - Evicts both values and metadata
# Best for very large datasets that exceed available RAM
# noEviction - (Ephemeral buckets only) Rejects writes when RAM is full
# Best for caching use casesTLS এনক্রিপশন এবং RBAC
উৎপাদনে Couchbase সুরক্ষিত করার জন্য ট্রানজিটে ডেটার এনক্রিপশন (TLS), সূক্ষ্ম-দানাযুক্ত ভূমিকা-ভিত্তিক অ্যাক্সেস নিয়ন্ত্রণ (RBAC) এবং অডিট লগিং প্রয়োজন।
# Enable TLS for all Couchbase services
/opt/couchbase/bin/couchbase-cli ssl-manage \
--cluster localhost:8091 \
--username Administrator \
--password password \
--set-node-certificate
# Enforce minimum TLS version
/opt/couchbase/bin/couchbase-cli setting-security \
--cluster localhost:8091 \
--username Administrator \
--password password \
--set \
--tls-min-version tlsv1.2 \
--tls-honor-cipher-order 1 \
--hsts-max-age 31536000 \
--hsts-preload-enabled 1
# Create application-specific RBAC users
/opt/couchbase/bin/couchbase-cli user-manage \
--cluster localhost:8091 \
--username Administrator \
--password password \
--set \
--rbac-username app-service \
--rbac-password "$(openssl rand -base64 32)" \
--rbac-name "Application Service Account" \
--roles 'data_reader[production-data],data_writer[production-data],query_select[production-data],query_insert[production-data],query_update[production-data],query_delete[production-data]' \
--auth-domain local
# Create a read-only analytics user
/opt/couchbase/bin/couchbase-cli user-manage \
--cluster localhost:8091 \
--username Administrator \
--password password \
--set \
--rbac-username analytics-reader \
--rbac-password "$(openssl rand -base64 32)" \
--roles 'data_reader[production-data],query_select[production-data],analytics_reader[production-data]' \
--auth-domain local
# Enable audit logging
/opt/couchbase/bin/couchbase-cli setting-audit \
--cluster localhost:8091 \
--username Administrator \
--password password \
--set \
--audit-enabled 1 \
--audit-log-path /opt/couchbase/var/lib/couchbase/logs \
--audit-log-rotate-interval 86400 \
--audit-log-rotate-size 20971520Kubernetes TLS সার্ট-ম্যানেজার
সহ# Certificate for Couchbase server TLS
apiVersion: cert-manager.io/v1
kind: Certificate
metadata:
name: couchbase-server-tls
namespace: couchbase
spec:
secretName: couchbase-server-tls
duration: 8760h # 1 year
renewBefore: 720h # 30 days before expiry
privateKey:
algorithm: RSA
size: 4096
usages:
- server auth
- client auth
dnsNames:
- "*.cb-production.couchbase.svc.cluster.local"
- "*.cb-production.couchbase.svc"
- "cb-production-srv.couchbase.svc.cluster.local"
- "localhost"
issuerRef:
name: couchbase-ca-issuer
kind: ClusterIssuerPrometheus এক্সপোর্টারএর সাথেমনিটরিং
Couchbase এর REST API এর মাধ্যমে সমৃদ্ধ মেট্রিক্স প্রকাশ করে৷couchbase-exporterব্যাপক পর্যবেক্ষণের জন্য Prometheus ফর্ম্যাটে অনুবাদ করে।
# Deploy Couchbase Prometheus Exporter
apiVersion: apps/v1
kind: Deployment
metadata:
name: couchbase-exporter
namespace: couchbase
spec:
replicas: 1
selector:
matchLabels:
app: couchbase-exporter
template:
metadata:
labels:
app: couchbase-exporter
annotations:
prometheus.io/scrape: "true"
prometheus.io/port: "9091"
spec:
containers:
- name: exporter
image: couchbase/exporter:1.0.9
args:
- --couchbase-address=cb-production-srv.couchbase.svc.cluster.local
- --couchbase-port=8091
- --couchbase-username=$(CB_USERNAME)
- --couchbase-password=$(CB_PASSWORD)
- --server-address=0.0.0.0:9091
- --per-node-refresh=5
env:
- name: CB_USERNAME
valueFrom:
secretKeyRef:
name: cb-admin-credentials
key: username
- name: CB_PASSWORD
valueFrom:
secretKeyRef:
name: cb-admin-credentials
key: password
ports:
- containerPort: 9091
name: metrics
resources:
requests:
cpu: 100m
memory: 128Mi
limits:
cpu: 500m
memory: 256Mi
---
apiVersion: monitoring.coreos.com/v1
kind: ServiceMonitor
metadata:
name: couchbase-monitor
namespace: couchbase
spec:
selector:
matchLabels:
app: couchbase-exporter
endpoints:
- port: metrics
interval: 15s
path: /metricsনিরীক্ষণের জন্যকী Couchbase মেট্রিক্স৷- cb_bucket_ops_per_sec— বালতি প্রতি সেকেন্ডে মোট অপারেশন। আপনার স্বাভাবিক থ্রুপুট বেসলাইন এবং অসঙ্গতি সম্পর্কে সতর্কতা.
- cb_bucket_mem_used_bytes— বালতি মেমরি ব্যবহার। উচ্ছেদ রোধ করতে RAM কোটার কাছে যাওয়ার সময় সতর্কতা।
- cb_bucket_cache_miss_ratio— অনুরোধের অনুপাত যা ক্যাশে মিস করে এবং ডিস্ক আনার প্রয়োজন হয়৷ সর্বোত্তম কর্মক্ষমতার জন্য 2% এর নিচে থাকা উচিত।
- cb_bucket_disk_queue_items— ডিস্ক রাইট সারি গভীরতা। একটি ক্রমবর্ধমান সারি নির্দেশ করে যে ডিস্ক I/O লেখার থ্রুপুট ধরে রাখতে পারে না।
- cb_xdcr_changes_left— XDCR প্রতিলিপি মুলতুবি থাকা মিউটেশনের সংখ্যা। ক্রস-অঞ্চল প্রতিলিপি ল্যাগ নির্দেশ করে।
- cb_xdcr_docs_written— XDCR এর মাধ্যমে প্রতি সেকেন্ডে নথি প্রতিলিপি করা হয়েছে৷
- cb_node_cpu_utilization_percent— প্রতি-নোড CPU ব্যবহার। Couchbase কমপ্যাকশন এবং ইন্ডেক্সিংয়ের জন্য CPU-নিবিড়।
- cb_bucket_vbucket_active_num— নোড প্রতি সক্রিয় vBucket সংখ্যা। ডাটা নোড জুড়ে মোটামুটি হওয়া উচিত।
- cb_index_num_docs_pending— মুলতুবি থাকা নথি সূচক আপডেট৷ সূচক বিল্ড ল্যাগ নির্দেশ করে।
- cb_n1ql_requests_per_sec— N1QL কোয়েরি থ্রুপুট। গড় বিলম্বের সাথে মিলিত, ক্যোয়ারী কর্মক্ষমতা সমস্যা চিহ্নিত করে।
Prometheus সতর্কতার নিয়ম
apiVersion: monitoring.coreos.com/v1
kind: PrometheusRule
metadata:
name: couchbase-alerts
namespace: couchbase
spec:
groups:
- name: couchbase.rules
rules:
- alert: CouchbaseNodeDown
expr: cb_node_healthy == 0
for: 1m
labels:
severity: critical
annotations:
summary: "Couchbase node {{ $labels.node }} is unhealthy"
- alert: CouchbaseHighCacheMissRate
expr: cb_bucket_cache_miss_ratio > 0.05
for: 5m
labels:
severity: warning
annotations:
summary: "Cache miss rate {{ $value | humanizePercentage }} on bucket {{ $labels.bucket }}"
- alert: CouchbaseXDCRLag
expr: cb_xdcr_changes_left > 10000
for: 10m
labels:
severity: warning
annotations:
summary: "XDCR replication lag: {{ $value }} pending mutations"
- alert: CouchbaseDiskQueueGrowing
expr: rate(cb_bucket_disk_queue_items[5m]) > 100
for: 10m
labels:
severity: warning
annotations:
summary: "Disk queue growing on bucket {{ $labels.bucket }}"
- alert: CouchbaseMemoryPressure
expr: cb_bucket_mem_used_bytes / cb_bucket_mem_quota_bytes > 0.9
for: 5m
labels:
severity: critical
annotations:
summary: "Memory usage at {{ $value | humanizePercentage }} for bucket {{ $labels.bucket }}"
HAএর জন্যSDK সংযোগ স্ট্রিং কনফিগারেশন
apiVersion: monitoring.coreos.com/v1
kind: PrometheusRule
metadata:
name: couchbase-alerts
namespace: couchbase
spec:
groups:
- name: couchbase.rules
rules:
- alert: CouchbaseNodeDown
expr: cb_node_healthy == 0
for: 1m
labels:
severity: critical
annotations:
summary: "Couchbase node {{ $labels.node }} is unhealthy"
- alert: CouchbaseHighCacheMissRate
expr: cb_bucket_cache_miss_ratio > 0.05
for: 5m
labels:
severity: warning
annotations:
summary: "Cache miss rate {{ $value | humanizePercentage }} on bucket {{ $labels.bucket }}"
- alert: CouchbaseXDCRLag
expr: cb_xdcr_changes_left > 10000
for: 10m
labels:
severity: warning
annotations:
summary: "XDCR replication lag: {{ $value }} pending mutations"
- alert: CouchbaseDiskQueueGrowing
expr: rate(cb_bucket_disk_queue_items[5m]) > 100
for: 10m
labels:
severity: warning
annotations:
summary: "Disk queue growing on bucket {{ $labels.bucket }}"
- alert: CouchbaseMemoryPressure
expr: cb_bucket_mem_used_bytes / cb_bucket_mem_quota_bytes > 0.9
for: 5m
labels:
severity: critical
annotations:
summary: "Memory usage at {{ $value | humanizePercentage }} for bucket {{ $labels.bucket }}"Couchbase SDKগুলি টপোলজি-সচেতন — তারা একটি অভ্যন্তরীণ ক্লাস্টার মানচিত্র এবং সঠিক নোডে সরাসরি রুট অপারেশন বজায় রাখে। সঠিক SDK কনফিগারেশন HA এর জন্য গুরুত্বপূর্ণ, দ্রুত ব্যর্থতা সনাক্তকরণ এবং ক্ষণস্থায়ী ত্রুটির উপর স্বয়ংক্রিয়ভাবে পুনরায় চেষ্টা নিশ্চিত করে।
// Node.js SDK configuration for HA
const couchbase = require('couchbase');
const clusterConnStr = 'couchbases://cb-node1.example.com,cb-node2.example.com,cb-node3.example.com';
const cluster = await couchbase.connect(clusterConnStr, {
username: process.env.CB_USERNAME,
password: process.env.CB_PASSWORD,
timeouts: {
kvTimeout: 2500, // Key-value operation timeout (ms)
kvDurableTimeout: 10000, // Durable write timeout
queryTimeout: 75000, // N1QL query timeout
searchTimeout: 75000, // FTS search timeout
analyticsTimeout: 75000, // Analytics query timeout
connectTimeout: 10000, // Initial connection timeout
managementTimeout: 75000 // Management API timeout
},
security: {
trustStorePath: '/etc/couchbase/ca.pem'
},
transactions: {
durabilityLevel: couchbase.DurabilityLevel.MajorityAndPersistToActive,
timeout: 15000
}
});
const bucket = cluster.bucket('production-data');
const collection = bucket.defaultCollection();
// Durable write with observe-based durability
await collection.upsert('order::2026-001', orderDocument, {
durabilityLevel: couchbase.DurabilityLevel.MajorityAndPersistToActive,
timeout: 10000
});
// Read with replica fallback for HA
try {
const result = await collection.get('user::12345');
} catch (err) {
if (err instanceof couchbase.errors.TimeoutError) {
const replicaResult = await collection.getAnyReplica('user::12345');
}
}# Java SDK configuration for HA
import com.couchbase.client.java.*;
import com.couchbase.client.java.env.*;
import java.time.Duration;
ClusterEnvironment env = ClusterEnvironment.builder()
.timeoutConfig(TimeoutConfig.builder()
.kvTimeout(Duration.ofMillis(2500))
.kvDurableTimeout(Duration.ofSeconds(10))
.queryTimeout(Duration.ofSeconds(75))
.connectTimeout(Duration.ofSeconds(10))
.build())
.ioConfig(IoConfig.builder()
.numKvConnections(4)
.enableMutationTokens(true)
.enableDnsSrv(true)
.build())
.securityConfig(SecurityConfig.builder()
.enableTls(true)
.trustCertificate(Paths.get("/etc/couchbase/ca.pem"))
.build())
.build();
Cluster cluster = Cluster.connect(
"couchbases://cb-node1.example.com,cb-node2.example.com",
ClusterOptions.clusterOptions("username", "password")
.environment(env)
);SDK সংযোগের জন্যKubernetes পরিষেবা DNS
# When using the Autonomous Operator, connect via the headless service:
# couchbase://cb-production-srv.couchbase.svc.cluster.local
#
# The operator creates these services:
# cb-production-srv - Headless service for SDK auto-discovery
# cb-production-ui - Web Console (port 8091/18091)
# cb-production-cloud - External connectivity (NodePort/LoadBalancer)
#
# For external SDK access (outside Kubernetes), use:
# - NodePort with explicit node addresses
# - LoadBalancer with MetalLB (bare metal)
# - Ingress with TCP passthrough for port 11210 (SDK) and 11207 (SDK TLS)Couchbase মোবাইল এবং প্রান্ত স্থাপনার জন্য সিঙ্ক গেটওয়ে
Couchbase মোবাইল Couchbase ইকোসিস্টেমকে প্রান্ত ডিভাইস এবং মোবাইল অ্যাপ্লিকেশনগুলিতে প্রসারিত করে৷Couchbase LiteiOS, Android, এবং IoT ডিভাইসে এম্বেড করা চলে, যখনসিঙ্ক গেটওয়েCouchbase Lite এবং Couchbase সার্ভারের মধ্যে সিঙ্ক্রোনাইজেশন মিডলওয়্যার হিসাবে কাজ করে।
// Sync Gateway configuration for production
{
"interface": ":4984",
"adminInterface": "127.0.0.1:4985",
"logging": {
"console": {
"log_level": "info",
"log_keys": ["HTTP", "Sync", "Auth", "Changes"]
}
},
"databases": {
"mobile-app": {
"server": "couchbases://cb-production-srv.couchbase.svc.cluster.local",
"bucket": "production-data",
"username": "sync-gateway",
"password": "${SG_PASSWORD}",
"enable_shared_bucket_access": true,
"import_docs": true,
"num_index_replicas": 1,
"delta_sync": {
"enabled": true,
"rev_max_age_seconds": 86400
},
"cache": {
"channel_cache": {
"max_number": 50000,
"compact_high_watermark_pct": 80,
"compact_low_watermark_pct": 60
},
"rev_cache": {
"size": 5000,
"shard_count": 16
}
},
"users": {
"GUEST": {"disabled": true}
},
"sync": "function(doc, oldDoc) { if (doc.type === 'user-data') { channel(doc.channels); requireAccess(doc.channels); } else { channel('public'); } }"
}
}
}
# Deploy Sync Gateway on Kubernetes
apiVersion: apps/v1
kind: Deployment
metadata:
name: sync-gateway
namespace: couchbase
spec:
replicas: 3
selector:
matchLabels:
app: sync-gateway
template:
metadata:
labels:
app: sync-gateway
spec:
containers:
- name: sync-gateway
image: couchbase/sync-gateway:3.1.4-enterprise
args: ["/etc/sync-gateway/config.json"]
ports:
- containerPort: 4984
name: public
- containerPort: 4985
name: admin
resources:
requests:
cpu: "2"
memory: 4Gi
limits:
cpu: "4"
memory: 8Gi
volumeMounts:
- name: config
mountPath: /etc/sync-gateway
volumes:
- name: config
configMap:
name: sync-gateway-configক্যাপাসিটি প্ল্যানিং এবং সাইজিং
Couchbase কর্মক্ষমতা এবং খরচ অপ্টিমাইজেশানের জন্য সঠিক ক্ষমতা পরিকল্পনা অপরিহার্য। নিচের সারণীটি কাজের চাপের স্তরের উপর ভিত্তি করে সাইজিং নির্দেশিকা প্রদান করে:
| কাজের চাপ স্তর | ডেটা নোড | সূচক/কোয়েরি | নোড প্রতিRAM | স্টোরেজ | থ্রুপুট |
|---|---|---|---|---|---|
| ডেভেলপমেন্ট | 1 (সমস্ত পরিষেবা) | সহ-অবস্থিত | ৷4 GB | 20 GB SSD | <1k অপ্স/s |
| ছোট উৎপাদন | 3 ডেটা | 2 কোয়েরি+ইনডেক্স | 16 GB | 100 GB SSD | 10k ops/s |
| মাঝারি উৎপাদন | 5 ডেটা | 3 কোয়েরি+ইনডেক্স | 32 GB | 500 GB SSD | 50k ops/s |
| বড় উৎপাদন | 7-10 ডেটা | 4+ ক্যোয়ারী+ইনডেক্স | 64 GB | 1 TB NVMe | 200k+ ops/s |
| এন্টারপ্রাইজ / গ্লোবাল | 10+ ডেটা (মাল্টি-রিজিয়ন) | 6+ ক্যোয়ারী+ইনডেক্স | 128 GB | 2+ TB NVMe | 500k+ ops/s |
সাইজিং সূত্র
# Data Service RAM sizing
# Required RAM per node = (num_documents * (doc_metadata_size + avg_value_size)) / num_data_nodes * (1 + num_replicas)
# doc_metadata_size = 56 bytes (fixed overhead per document)
# Include 25% headroom for fragmentation and growth
# Example: 100M documents, 1KB avg size, 3 data nodes, 1 replica
# RAM = (100,000,000 * (56 + 1024)) / 3 * 2 = ~72 GB per node
# With 25% headroom: ~90 GB per node
# Index Service RAM sizing (memory-optimized)
# RAM = total_index_size * 3 (for build/merge overhead)
# Use system:indexes to check current index sizes
# Disk sizing
# Disk = (num_documents * avg_doc_size * (1 + num_replicas)) * 3 (compaction headroom)
# Use SSD/NVMe with provisioned IOPS for predictable performanceদুর্যোগ পুনরুদ্ধার এবং ব্যর্থতার প্রক্রিয়া
একটি ব্যাপক দুর্যোগ পুনরুদ্ধার পরিকল্পনা ব্যবসার ধারাবাহিকতা নিশ্চিত করে যখন অবকাঠামোগত ব্যর্থতা স্বয়ংক্রিয় ব্যর্থতার সুযোগ অতিক্রম করে।
একক নোড ব্যর্থতা (স্বয়ংক্রিয়)
# Auto-failover handles single node failures automatically.
# Verify failover occurred:
/opt/couchbase/bin/couchbase-cli server-list \
--cluster localhost:8091 \
--username Administrator \
--password password
# After replacing the failed node, add and rebalance:
/opt/couchbase/bin/couchbase-cli server-add \
--cluster localhost:8091 \
--username Administrator \
--password password \
--server-add new-node.example.com:8091 \
--server-add-username Administrator \
--server-add-password password \
--services data,index
/opt/couchbase/bin/couchbase-cli rebalance \
--cluster localhost:8091 \
--username Administrator \
--password passwordসম্পূর্ণ ক্লাস্টার ব্যর্থতা (ম্যানুয়াল)
# Scenario: Primary region (US-EAST) completely lost
# Step 1: Verify XDCR target cluster (EU-WEST) has latest data
# Check XDCR replication status before failure
curl -s http://eu-west-node:8091/pools/default/remoteClusters \
-u Administrator:password | jq .
# Step 2: Pause XDCR replications pointing to the failed cluster
/opt/couchbase/bin/couchbase-cli xdcr-replicate \
--cluster cb-eu-west.example.com:8091 \
--username Administrator \
--password password \
--pause \
--xdcr-replicator <replication-id>
# Step 3: Update application connection strings to EU-WEST cluster
# (via DNS update, service mesh, or environment variable change)
# Step 4: Scale up EU-WEST cluster if needed to handle full production load
# In Kubernetes, update the CouchbaseCluster CRD:
kubectl patch couchbasecluster cb-eu-west -n couchbase --type merge \
-p '{"spec":{"servers":[{"name":"data-zone-a","size":4}]}}'
# Step 5: After US-EAST cluster is restored, re-establish XDCR
# and perform a full resync from EU-WEST back to US-EASTগ্রেসফুল ফেইলওভার এবং রিকভারি
# Graceful failover (for maintenance, drains data before removal)
/opt/couchbase/bin/couchbase-cli failover \
--cluster localhost:8091 \
--username Administrator \
--password password \
--server-failover node-to-remove.example.com:8091
# Recovery (re-add the node after maintenance)
/opt/couchbase/bin/couchbase-cli recovery \
--cluster localhost:8091 \
--username Administrator \
--password password \
--server-recovery node-to-recover.example.com:8091 \
--recovery-type delta
# Delta recovery re-synchronizes only the changed data,
# which is much faster than full recovery.
# Full recovery rebuilds the node from scratch.
# Rebalance to complete the recovery
/opt/couchbase/bin/couchbase-cli rebalance \
--cluster localhost:8091 \
--username Administrator \
--password passwordসম্পূর্ণ উত্পাদন স্থাপনার জন্যHelm মানগুলি
নীচে একটি উত্পাদন পরিবেশে স্বায়ত্তশাসিত অপারেটরের সাথে Couchbase স্থাপনের জন্য একটি ব্যাপক Helm মান ফাইল রয়েছে:
# helm-values-production.yaml
couchbase-operator:
operator:
image:
repository: couchbase/operator
tag: 2.7.1
resources:
requests:
cpu: 500m
memory: 512Mi
limits:
cpu: "1"
memory: 1Gi
admissionController:
enabled: true
resources:
requests:
cpu: 100m
memory: 128Mi
cluster:
image: couchbase/server:7.6.1-enterprise
antiAffinity: true
autoFailoverTimeout: 30s
autoFailoverMaxCount: 3
autoFailoverOnDataDiskIssues: true
autoFailoverServerGroup: true
security:
adminSecret: cb-admin-credentials
networking:
tls:
static:
serverSecret: couchbase-server-tls
operatorSecret: couchbase-operator-tls
exposeAdminConsole: true
adminConsoleServiceType: NodePort
buckets:
managed: true
servers:
data:
size: 4
services:
- data
- index
serverGroups:
- zone-a
- zone-b
resources:
requests:
cpu: "4"
memory: 16Gi
limits:
cpu: "8"
memory: 20Gi
volumeMounts:
default: couchbase-data
data: couchbase-data
index: couchbase-index
query:
size: 2
services:
- query
- search
resources:
requests:
cpu: "4"
memory: 8Gi
limits:
cpu: "8"
memory: 12Gi
volumeMounts:
default: couchbase-default
analytics:
size: 2
services:
- analytics
- eventing
serverGroups:
- zone-c
resources:
requests:
cpu: "8"
memory: 32Gi
limits:
cpu: "16"
memory: 40Gi
volumeMounts:
default: couchbase-analytics
analytics:
- couchbase-analytics
serverGroups:
- zone-a
- zone-b
- zone-c
volumeClaimTemplates:
- metadata:
name: couchbase-data
spec:
storageClassName: ebs-gp3-couchbase
resources:
requests:
storage: 100Gi
- metadata:
name: couchbase-index
spec:
storageClassName: ebs-gp3-couchbase
resources:
requests:
storage: 50Gi
- metadata:
name: couchbase-default
spec:
storageClassName: ebs-gp3-couchbase
resources:
requests:
storage: 20Gi
- metadata:
name: couchbase-analytics
spec:
storageClassName: ebs-gp3-couchbase
resources:
requests:
storage: 200Giউপসংহার
Couchbase সার্ভারের আর্কিটেকচার - vBucket-ভিত্তিক শার্ডিং, মেমরি-প্রথম ডেটা অ্যাক্সেস এবং সমন্বিত মাল্টি-মডেল পরিষেবাগুলির চারপাশে নির্মিত—উচ্চ প্রাপ্যতা উত্পাদন স্থাপনার জন্য একটি অনন্য শক্তিশালী ভিত্তি প্রদান করে৷ স্বয়ংক্রিয় ব্যর্থতার সাথে ইন্ট্রা-ক্লাস্টার প্রতিলিপির সংমিশ্রণ নিশ্চিত করে যে একক-নোড ব্যর্থতাগুলি স্বচ্ছভাবে পরিচালনা করা হয়, যখন XDCR বিশ্বব্যাপী অ্যাপ্লিকেশনগুলির জন্য ভৌগলিক অঞ্চল জুড়ে এই স্থিতিস্থাপকতাকে প্রসারিত করে।
Kubernetes-এর জন্য Couchbase স্বায়ত্তশাসিত অপারেটর যা জটিল ম্যানুয়াল অপারেশনগুলিকে ঘোষণামূলক, স্ব-নিরাময় স্থাপনায় রূপান্তরিত করে। সার্ভার গ্রুপগুলি র্যাক/জোন সচেতনতা প্রদান করে, অপারেটর স্কেলিং ইভেন্টের সময় রিব্যালেন্স অপারেশন পরিচালনা করে, এবং সমন্বিত ব্যাকআপ CRDs স্বয়ংক্রিয় দুর্যোগ পুনরুদ্ধারের প্রস্তুতি।
এই গাইড থেকেমূল টেকওয়ে:
- লিভারেজ মাল্টি-ডাইমেনশনাল স্কেলিং— স্বাধীন স্কেলিং এবং রিসোর্স আইসোলেশনের জন্য ডেডিকেটেড নোড পুলগুলিতে পৃথক ডেটা, সূচক, ক্যোয়ারী, অনুসন্ধান, বিশ্লেষণ এবং ইভেন্টিং পরিষেবাগুলি।
- মাল্টি-রিজিয়ন স্থিতিস্থাপকতার জন্য XDCR কনফিগার করুন— টাইমস্ট্যাম্প-ভিত্তিক দ্বন্দ্ব রেজোলিউশন সহ দ্বিমুখী XDCR AWS, Azure এবং GCP জুড়ে সক্রিয়-সক্রিয় স্থাপনা সক্ষম করে। সর্বদা এনটিপি সিঙ্ক্রোনাইজেশন নিশ্চিত করুন।
- জোন সচেতনতার জন্য সার্ভার গোষ্ঠীগুলি ব্যবহার করুন— সক্রিয় এবং প্রতিরূপ vBuckets বিভিন্ন ব্যর্থ ডোমেনে রয়েছে তা গ্যারান্টি দিতে প্রাপ্যতা অঞ্চল বা র্যাকগুলিতে সার্ভার গ্রুপগুলি ম্যাপ করুন৷
- সাইজ মেমরি সাবধানে— Couchbase-এর কর্মক্ষমতা সরাসরি RAM-তে কতটা কাজের সেট ফিট করে তার সাথে যুক্ত। সাইজিং সূত্র ব্যবহার করুন এবং ক্যাশে মিস অনুপাত নিরীক্ষণ করুন।
- ব্যাপক পর্যবেক্ষণপ্রয়োগ করুন — Prometheus রপ্তানিকারককে প্রথম দিন থেকে স্থাপন করুন৷ XDCR রেপ্লিকেশন ল্যাগ, ক্যাশে মিস রেশিও, ডিস্ক কিউ গভীরতা এবং নোডের স্বাস্থ্য হল আপনার গুরুত্বপূর্ণ সংকেত।
- cbbackupmgrএর সাথে স্বয়ংক্রিয় ব্যাকআপগুলি — ক্লাউড স্ন্যাপশটগুলির সাথে সম্পূর্ণ এবং বর্ধিত ব্যাকআপগুলিকে একত্রিত করুন৷ নিয়মিত পরীক্ষা পুনরুদ্ধার পদ্ধতি.
- TLS এবং RBACসহ সুরক্ষিত — নোড-টু-নোড এবং ক্লায়েন্ট-টু-নোড TLS এনক্রিপশন সক্ষম করুন। প্রতিটি অ্যাপ্লিকেশন পরিষেবা অ্যাকাউন্টের জন্য সূক্ষ্ম-দানাযুক্ত RBAC ভূমিকা ব্যবহার করুন।
- HA-এর জন্য SDK কনফিগার করুন — একাধিক বুটস্ট্র্যাপ নোড ব্যবহার করুন, উপযুক্ত টাইমআউট কনফিগার করুন, ফলব্যাক হিসাবে রেপ্লিকা রিড প্রয়োগ করুন, এবং সমালোচনামূলক ডেটার জন্য টেকসই লেখার সুবিধা নিন।
- দুর্যোগ পুনরুদ্ধারের জন্য পরিকল্পনা— একক-নোড, মাল্টি-নোড, এবং সম্পূর্ণ ক্লাস্টার ব্যর্থতার পরিস্থিতিগুলির জন্য নথি এবং ব্যর্থতার পদ্ধতিগুলি অনুশীলন করুন। XDCR স্ট্যান্ডবাই ক্লাস্টারগুলি সর্বদা প্রচারের জন্য প্রস্তুত থাকা উচিত।
এই ব্যাপক ফাউন্ডেশনের সাহায্যে, আপনি যেকোন অবকাঠামো জুড়ে উচ্চ প্রাপ্যতা উত্পাদন পরিবেশে Couchbase সার্ভার স্থাপন এবং পরিচালনা করতে সজ্জিত - AWS, Azure, এবং GCP-এ পরিচালিত Kubernetes থেকে Rancher দ্বারা পরিচালিত বেয়ার মেটাল k3s ক্লাস্টার পর্যন্ত৷ Kubernetes অর্কেস্ট্রেশনের সাথে Couchbase এর নেটিভ ডিস্ট্রিবিউটেড আর্কিটেকচারের সংমিশ্রণ একটি ডাটাবেস প্ল্যাটফর্ম সরবরাহ করে যা আধুনিক, বিশ্বব্যাপী বিতরণ করা অ্যাপ্লিকেশনগুলির চাহিদা পূরণ করে।