Backup, replication আর high availability

১ · ডেটা কীভাবে হারায় — আর backup কেন আলাদা জিনিস

পর্ব ৪৮-এ (Recovery) দেখেছেন, বিদ্যুৎ গেলে DBMS নিজের WAL পড়ে নিজেকে সারায়। কিন্তু দুটি বিপদে সে অসহায়: ডিস্কটিই নষ্ট হলে log-ও হয়তো গেছে; আর কেউ ভুল করে DROP TABLE orders চালালে সেটি একটি বৈধ, commit হওয়া কাজ — recovery একে “সারাবে” না, বরং টেকসই রাখবে। এই পর্বের বিষয় তাই দুটি প্রশ্ন: ডেটা হারালে ফেরত আনব কীভাবে (backup আর restore), আর একটি সার্ভার বন্ধ হলেও সেবা চালু রাখব কীভাবে (replication আর high availability).

২ · RPO আর RTO — কতটা হারানো চলে, কতক্ষণ বন্ধ থাকা চলে

backup-এর পরিকল্পনা শুরু হয় প্রযুক্তি দিয়ে নয়, দুটি ব্যবসায়িক প্রশ্ন দিয়ে।

শেষ ভালো কপি          বিপর্যয়             সেবা আবার চালু
     │◄──── RPO: হারানো ডেটা ───►│◄──── RTO: বন্ধ থাকা ────►│
─────●──────────────────────────✗──────────────────────────●────► সময়

সংখ্যা ঠিক হয় কাজের ধরন দেখে। মোবাইলে টাকা পাঠানোর সেবায় একটি নিশ্চিত লেনদেনও হারানো চলে না (RPO শূন্য), আর কয়েক মিনিট বন্ধ থাকলেই লাখো মানুষ আটকে যান। বিশ্ববিদ্যালয়ের ফল প্রকাশের সাইটে আগের রাতের backup হয়তো যথেষ্ট, কারণ ফল আবার upload করা যায়। নিয়ম: RPO আর RTO যত ছোট, ব্যবস্থা তত দামি। রাতের backup সস্তা; সারাক্ষণ WAL archive করলে RPO কয়েক মিনিট; synchronous replica-তে প্রায় শূন্য, কিন্তু দ্বিতীয় সার্ভার আর ধীর commit-এর দামে। লক্ষ্য ঠিক করা তাই দর-কষাকষি: এক ঘণ্টা বন্ধে কত ক্ষতি, ঠেকাতে কত খরচ।

একটি সূক্ষ্ম কথা: RPO নির্ভর করে সফল backup-এর মাঝের ফাঁকের ওপর, সময়সূচির ওপর নয়। কোনো রাতে backup চুপচাপ ব্যর্থ হলে আসল RPO দ্বিগুণ হয়ে যায়। নিচের এডিটর দোকানের নমুনা ডেটাবেসে চলে, তবে এখানে শুধু একটি বাড়তি টেবিল লাগবে: backup_runs (run_id, kind — full না incremental, finished_at — কখন শেষ, status — ফল)। LAG window function (পর্ব ২৬) দিয়ে পরপর দুটি সফল backup-এর ফাঁক মাপি:

SELECT run_id, kind, finished_at,
       ROUND((julianday(finished_at)
            - julianday(LAG(finished_at) OVER (ORDER BY finished_at))) * 24, 1)
         AS hours_since_prev_ok
FROM backup_runs
WHERE status = 'ok'
ORDER BY finished_at;
SELECT run_id, finished_at, status FROM backup_runs WHERE status <> 'ok';

৩ · Backup-এর ধরন — logical, physical, full, incremental আর snapshot

প্রথম ভাগ: কী কপি করা হচ্ছে। Logical backup ডেটাকে আবার বানানোর নির্দেশ লেখে — CREATE TABLE আর INSERT বা COPY-এর একটি ফাইল। Physical backup ডেটাবেসের আসল ফাইলগুলো (data page, WAL) বাইট ধরে কপি করে।

কয়েক GB-তে logical dump চমৎকার; TB-তে restore-এ ঘণ্টার পর ঘণ্টা লাগে (প্রতিটি index শূন্য থেকে গড়তে হয়) — তখন RTO-ই physical backup বাধ্য করে। dump টুল ব্যস্ত ডেটাবেসেও সংগত কপি দেয়: pg_dump একটি transaction-এর snapshot-এ (পর্ব ৪৭-এর MVCC) সব পড়ে, আর InnoDB-তে mysqldump-কে --single-transaction দিলে একই কাজ হয়।

# PostgreSQL: custom format (-Fc) — সংকুচিত, pg_restore দিয়ে বাছাই আর parallel restore
pg_dump -h db1 -U backup_user -d shop -Fc -f shop_2025-10-10.dump
pg_restore -h db-test -U postgres -d shop_check -j 4 shop_2025-10-10.dump
pg_dumpall -h db1 -U postgres --globals-only > globals.sql   # role আর ব্যবহারকারী আলাদা

# MySQL/InnoDB: lock ছাড়া সংগত dump, সাথে procedure, trigger আর event
mysqldump --single-transaction --routines --triggers --events shop > shop.sql
mysql shop_check < shop.sql

# SQLite: পুরো ডেটাবেস SQL লেখা হিসেবে
sqlite3 shop.db .dump > shop.sql

# PostgreSQL: চলমান সার্ভারের base backup, সাথে দরকারি WAL (-X stream)
pg_basebackup -h db1 -U replicator -D /backup/base_2025-10-05 -Ft -z -X stream -P

দ্বিতীয় ভাগ: প্রতিবার কতটা কপি।

ধরুন রবিবার full, আর বৃহস্পতিবার সকালে বিপদ। incremental-এ লাগবে রবি + সোম + মঙ্গল + বুধ — চারটি ফাইল। differential-এ রবি + বুধ — দুটি। PostgreSQL ১৭ থেকে pg_basebackup নিজেই incremental backup নিতে পারে, আর pg_combinebackup সেগুলো জুড়ে দেয়; MySQL-এ Percona XtraBackup-এর মতো টুল অনেক দিন ধরে এটি করে।

তৃতীয় পথ storage snapshot: LVM, ZFS বা ক্লাউডের ডিস্ক (যেমন একটি volume-এর snapshot) এক মুহূর্তে পুরো ডিস্কের ছবি রাখে, copy-on-write কৌশলে প্রায় সঙ্গে সঙ্গে। এটি “crash-consistent” — যেন ঠিক ওই মুহূর্তে বিদ্যুৎ গিয়েছিল; restore-এর পর DBMS পর্ব ৪৮-এর crash recovery চালিয়ে সংগত হয়, যদি data আর WAL একই মুহূর্তের snapshot-এ থাকে (নইলে PostgreSQL-এর pg_backup_start()/pg_backup_stop() দিয়ে সীমা চিহ্নিত করতে হয়)। আর একই ডিস্ক-ব্যবস্থার snapshot সেই ব্যবস্থার সাথেই মরে — অন্য জায়গায় কপি না করলে এটি পুরো backup নয়।

৪ · Continuous archiving আর point-in-time recovery

রাতের backup-এর RPO ২৪ ঘণ্টা। কমানোর উপায় পর্ব ৪৮-এর WAL-এই লুকিয়ে আছে: প্রতিটি commit হওয়া পরিবর্তন তো WAL-এ লেখা হয়ই। পূর্ণ হওয়া প্রতিটি WAL segment ফাইল অন্য জায়গায় কপি করে রাখলে — continuous archiving — হাতে থাকে একটি base backup আর তার পরের পুরো ইতিহাস। restore মানে base backup ফেরানো, তারপর archived WAL redo করে যেকোনো মুহূর্তে থামা: point-in-time recovery (PITR). RPO তখন শুধু শেষ archive না হওয়া WAL-টুকু — কয়েক মিনিট বা তারও কম। PostgreSQL-এ সেটিং:

# মূল সার্ভারে: প্রতিটি পূর্ণ WAL segment archive-এ কপি
archive_mode = on
archive_command = 'test ! -f /mnt/archive/%f && cp %p /mnt/archive/%f'
archive_timeout = 300          # কম লেখার সময়ও অন্তত ৫ মিনিটে একবার segment বদল

# restore-এর সার্ভারে (PostgreSQL 12+; সাথে data ফোল্ডারে খালি recovery.signal ফাইল)
restore_command = 'cp /mnt/archive/%f %p'
recovery_target_time = '2025-10-07 15:04:59+06'
recovery_target_action = 'pause'   # লক্ষ্যে পৌঁছে থামো, আগে যাচাই করি

MySQL-এ একই ভূমিকা binary log-এর (binlog): full backup ফেরানোর পর mysqlbinlog --stop-datetime দিয়ে binlog একটি মুহূর্ত পর্যন্ত চালানো হয়। এবার পুরো ঘটনাটি ধাপে ধাপে। মঙ্গলবার বিকেল ৩:০৫-এ একজন ডেভেলপার পরীক্ষার সার্ভার ভেবে আসল সার্ভারে পুরোনো অর্ডার মোছার একটি DELETE চালালেন:

SQL-এর ভেতরে সময়ভ্রমণ — history টেবিল

PITR পুরো ডেটাবেসকে অতীতে নেয়। অনেক সময় দরকার শুধু একটি টেবিলের একটি column — আর তখন ভালো উপায় ডেটাবেসের ভেতরেই একটি history রাখা। SQL:2011 standard-এ এর নাম temporal table; SQL Server আর MariaDB-তে system-versioned টেবিল আছে, Oracle-এ Flashback Query, আর অন্যত্র trigger দিয়ে বানানো audit log (পর্ব ২৯)। আমাদের দোকানে stock_history টেবিল প্রতিটি পণ্যের মজুদ (stock) কখন থেকে কত ছিল তা রাখে: product_id, stock, valid_from (কখন থেকে এই মান), changed_by (কে বা কী বদলাল)। ঘটনা: সকালে খোলার মান, দিনের বেলা তিনটি বিক্রি, তারপর ৩:০৫-এ কেউ WHERE ছাড়া UPDATE products SET stock = 0 চালিয়েছেন, আর ৩:১০-এ Power Bank (103)-এর নতুন চালান এসে মজুদ ২০ হয়েছে। এডিটর খোলার সময় এসব আগেই ঘটে গেছে। ৩:০৪:৫৯-এ মজুদ কত ছিল?

SELECT p.product_id, p.name,
       (SELECT h.stock FROM stock_history h
        WHERE h.product_id = p.product_id
          AND h.valid_from <= '2025-10-10 15:04:59'
        ORDER BY h.valid_from DESC LIMIT 1) AS stock_at_1504,
       p.stock AS stock_now
FROM products p
ORDER BY p.product_id;

এবার শুধু ভুলটুকু উল্টাই: যে পণ্যগুলোর মজুদ ৩:০৫-এর পরে আর বদলায়নি, তাদের ৩:০৪:৫৯-এর মানে ফেরানো। ৩:১০-এর চালান যেন না মোছে:

UPDATE products
SET stock = (SELECT h.stock FROM stock_history h
             WHERE h.product_id = products.product_id
               AND h.valid_from <= '2025-10-10 15:04:59'
             ORDER BY h.valid_from DESC LIMIT 1)
WHERE product_id NOT IN (SELECT product_id FROM stock_history
                         WHERE valid_from > '2025-10-10 15:05:00');
SELECT product_id, stock FROM products ORDER BY product_id;
SELECT SUM(stock) AS total_stock FROM products;

৫ · 3-2-1, encryption, retention — আর restore-এর মহড়া

backup কোথায়, কয়টি, কতদিন — এর সবচেয়ে প্রচলিত নিয়ম 3-2-1, যা ফটোগ্রাফার Peter Krogh-এর লেখার মাধ্যমে জনপ্রিয় হয়েছে বলে ধরা হয়:

অর্থাৎ মূল ডেটা ছাড়াও দুটি backup; একই ডিস্ক-ব্যবস্থায় সব নয় (যেমন একটি ডিস্কে, একটি object storage-এ); আর একটি অন্য শহরে বা অন্য ক্লাউড region-এ — ঢাকার অফিসে আগুন বা বন্যা হলে যেন চট্টগ্রাম বা অন্য কোথাও একটি কপি বাঁচে। ransomware-এর যুগে অনেকে যোগ করেন আরও দুটি অঙ্ক: একটি কপি immutable বা অফলাইন (নির্দিষ্ট সময় পর্যন্ত কেউ মুছতে বা বদলাতে পারে না, এমনকি admin-এর পাসওয়ার্ড চুরি হলেও), আর restore-যাচাইয়ে শূন্য ত্রুটি।

• Encryption: backup-এ পুরো ডেটাবেস থাকে — গ্রাহকের ফোন নম্বর, ঠিকানা, লেনদেন। পথে (TLS) আর জমায় দুই জায়গাতেই encrypt করুন (পর্ব ৫১), চাবি রাখুন আলাদা জায়গায়। চাবি হারালে backup-ও হারাল।
• Retention: প্রচলিত ধাঁচ: প্রতিদিনেরটি ১৪ দিন, সাপ্তাহিকটি ৮ সপ্তাহ, মাসিকটি ১২ মাস। নীরব bug ধরা পড়ে সপ্তাহ পরে, তাই খুব ছোট retention বিপজ্জনক; আবার গোপনীয়তার নিয়মে পুরোনো ব্যক্তিগত ডেটা মোছার দায় backup-এও পড়ে।
• যাচাই: নিয়মিত অন্য সার্ভারে পুরো restore করে সারি গোনা, পরিচিত কোয়েরি চালানো আর সময় মাপা। মাপা সময়টিই আপনার আসল RTO.

SQLite-এর backup

SQLite একটিমাত্র ফাইল, তাই লোভ হয় cp করতে। কিন্তু লেখার মাঝে কপি করলে অর্ধেক-বদলানো ফাইল আসতে পারে, আর WAL মোডে commit হওয়া ডেটার একটি অংশ থাকে আলাদা -wal ফাইলে। নিরাপদ পথ তিনটি: online backup API (CLI-তে .backup), VACUUM INTO (৩.২৭.০ সংস্করণ, ২০১৯ থেকে — একটি সংকুচিত, সংগত কপি নতুন ফাইলে), আর ক্রমাগত কপির জন্য Litestream-এর মতো বাইরের টুল, যা WAL-এর পরিবর্তন object storage-এ পাঠিয়ে SQLite-এও PITR-ধাঁচের restore দেয়।

sqlite3 shop.db ".backup 'backup_2025-10-10.db'"
sqlite3 shop.db "VACUUM INTO 'copy_2025-10-10.db'"
sqlite3 backup_2025-10-10.db "PRAGMA integrity_check"     # ok আসা চাই

নিচের Python প্রোগ্রাম (stdlib-এর sqlite3, আসল ফাইলে) পুরো চক্রটি দেখায়: ৩,০০০ অর্ডারের একটি ডেটাবেসের online backup, তারপর যাচাই — integrity check আর প্রতিটি সারির hash মিলিয়ে — তারপর একটি “ভুল DELETE” আর backup থেকে restore:

import hashlib, os, sqlite3, tempfile
d = tempfile.mkdtemp()
live = sqlite3.connect(os.path.join(d, "shop.db"))
live.execute("CREATE TABLE orders (id INTEGER PRIMARY KEY, customer TEXT, amount INTEGER)")
live.executemany("INSERT INTO orders (customer, amount) VALUES (?, ?)",
                 [(f"cust{i % 40}", i * 10) for i in range(1, 3001)]); live.commit()
def fingerprint(con):  # row count + hash of every row, in key order
    rows = con.execute("SELECT * FROM orders ORDER BY id").fetchall()
    return len(rows), hashlib.sha256(repr(rows).encode()).hexdigest()[:12]
def progress(status, remaining, total):
    print(f"  copied {total - remaining} of {total} pages")
backup = sqlite3.connect(os.path.join(d, "backup.db"))
live.backup(backup, pages=5, progress=progress)   # 5 pages per step; writers may run in between
print("integrity:", backup.execute("PRAGMA integrity_check").fetchone()[0])
print("live:", fingerprint(live), " backup:", fingerprint(backup))
live.execute("DELETE FROM orders WHERE amount > 100"); live.commit()   # the bad DELETE
print("after bad DELETE:", fingerprint(live)[0], "rows")
backup.backup(live)                                # restore: copy the backup over the live db
print("after restore   :", fingerprint(live))
live.execute(f"VACUUM INTO '{os.path.join(d, 'copy2.db')}'")         # another consistent copy
print("VACUUM INTO file bytes:", os.path.getsize(os.path.join(d, "copy2.db")))

  copied 5 of 15 pages
  copied 10 of 15 pages
  copied 15 of 15 pages
integrity: ok
live: (3000, '79061664e07a')  backup: (3000, '79061664e07a')
after bad DELETE: 10 rows
after restore   : (3000, '79061664e07a')
VACUUM INTO file bytes: 61440

৬ · Replication — কেন, আর কীভাবে

Replication মানে একই ডেটার একাধিক জীবন্ত কপি, যা সারাক্ষণ হালনাগাদ থাকে। কারণ তিনটি: high availability (একটি সার্ভার মরলে আরেকটি সেকেন্ডে দায়িত্ব নেয়), পড়ার চাপ ভাগ (রিপোর্টের কোয়েরি কপিতে), আর ভৌগোলিক দূরত্ব (দূরের ব্যবহারকারীর কাছে কপি, শহরের বিপর্যয়ে অন্য শহরের কপি)। backup নেওয়াও replica-তে চালানো যায়।

সবচেয়ে প্রচলিত গঠন primary–replica (leader–follower; পুরোনো লেখায় master–slave). সব লেখা যায় একটি primary-তে। primary নিজের log replica-দের পাঠায়, আর replica সেই log নিজের কপিতে প্রয়োগ করে — পর্ব ৪৮-এর redo-ই, শুধু অন্য যন্ত্রে, সারাক্ষণ। replica-গুলো পড়ার কোয়েরি নিতে পারে। log পাঠানোর ধরনে দুটি পরিবার:

replica কতটা পিছিয়ে আছে — replication lag — সেটিই replication-এর প্রধান স্বাস্থ্য-সংকেত। নিচের এডিটরে দুটি বাড়তি টেবিল। replication_log হলো primary-র commit-এর ধারা: lsn (ক্রমিক অবস্থান), committed_at (কখন), tbl (কোন টেবিল), summary (কী বদলাল)। replicas-এ তিনটি কপি: name, mode (sync বা async), city আর replayed_lsn — কোন lsn পর্যন্ত নিজের কপিতে প্রয়োগ করেছে। sessions টেবিলটি পরের অংশে লাগবে।

SELECT r.name, r.mode, r.replayed_lsn,
       (SELECT MAX(lsn) FROM replication_log) - r.replayed_lsn AS commits_behind,
       CAST(ROUND((julianday((SELECT MAX(committed_at) FROM replication_log))
                 - julianday(l.committed_at)) * 86400) AS INTEGER) AS lag_seconds
FROM replicas r
JOIN replication_log l ON l.lsn = r.replayed_lsn
ORDER BY lag_seconds;

ঠিক এই মুহূর্তে primary মরে গেলে কোন replica-কে primary বানালে কী হারাবে? replica যে commit-গুলো দেখেনি সেগুলোই ঝুঁকিতে:

SELECT r.name, l.lsn, l.committed_at, l.summary
FROM replicas r
JOIN replication_log l ON l.lsn > r.replayed_lsn
WHERE r.name = 'ctg-dr'
ORDER BY l.lsn;
SELECT r.name, COUNT(l.lsn) AS unseen_commits
FROM replicas r
LEFT JOIN replication_log l ON l.lsn > r.replayed_lsn
GROUP BY r.name
ORDER BY unseen_commits;

৭ · Synchronous বনাম asynchronous — durability বনাম গতি

মূল প্রশ্ন: primary কখন অ্যাপকে “commit সফল” বলবে? Asynchronous-এ নিজের ডিস্কে WAL লিখেই; log পরে replica-তে যায়। Synchronous-এ অন্তত একটি replica “পেয়েছি” বলার পর। পার্থক্যটি একটি bKash-ধাঁচের লেনদেনে দেখুন — primary ঢাকায়, replica চট্টগ্রামে, এক দিকে নেটওয়ার্কে ধরুন ৪ ms:

বাস্তব সিস্টেমে মাঝামাঝি অনেক বিকল্প। PostgreSQL-এ synchronous_standby_names ঠিক করে কোন replica sync, আর synchronous_commit ঠিক করে কতটা অপেক্ষা:

একটি মাত্র sync replica-র ঝুঁকি কমাতে quorum ধাঁচ: ANY 1 (dhaka_b, ctg_c) মানে দুটির যেকোনো একটির ack যথেষ্ট। MySQL-এর semi-synchronous replication অন্তত একটি replica-র “পেয়েছি” (relay log-এ লেখা) পর্যন্ত অপেক্ষা করে, আর নির্দিষ্ট সময়ে (default ১০ সেকেন্ড) উত্তর না এলে async-এ নেমে যায় — অর্থাৎ চাপের মুহূর্তে নিঃশব্দে RPO শূন্য থাকে না।

Lag-এর দুই ফাঁদ — নিজের লেখা না দেখা, আর সময় পেছনে যাওয়া

async replica-তে পড়া পাঠালে আরেক সমস্যা: ব্যবহারকারী নিজের করা কাজই দেখতে পান না। Read-your-own-writes নিশ্চয়তা বলে — আপনি যা লিখেছেন, পরে পড়লে অন্তত তা দেখবেন। Monotonic reads বলে — একবার নতুন অবস্থা দেখলে পরে পুরোনোটি দেখবেন না। আগের এডিটরের তিন replica দিয়ে:

শেষ ধাপের নিয়মটি SQL-এ একটি CROSS JOIN আর CASE — প্রতিটি session আর প্রতিটি async replica-র জোড়ায় সিদ্ধান্ত (customer 1 কখনো লেখেননি, তাই তাঁর last_write_lsn NULL):

SELECT s.customer_id, r.name, r.replayed_lsn, s.last_write_lsn,
       CASE WHEN r.replayed_lsn >= COALESCE(s.last_write_lsn, 0)
            THEN 'ok: read here'
            ELSE 'stale: go to primary' END AS route
FROM sessions s
CROSS JOIN replicas r
WHERE r.mode = 'async'
ORDER BY s.customer_id, r.name;

এবার পুরো ছবি একটি ছোট simulation-এ: দুটি আলাদা SQLite ডেটাবেস primary আর replica, মাঝে log পাঠানো। async replica log পায় দুটি commit-এর একটি দলে (দেরির অনুকরণ); তৃতীয় commit-এর পর primary মারা যায় আর replica-কে promote করা হয়। ফল নির্দিষ্ট — কোনো এলোমেলো সংখ্যা নেই:

import sqlite3
def scenario(mode, rtt_ms=8):
    primary, replica = sqlite3.connect(":memory:"), sqlite3.connect(":memory:")
    for db in (primary, replica):
        db.execute("CREATE TABLE payments (id INTEGER PRIMARY KEY, amount INTEGER)")
    log, shipped, latency = [], 0, 0
    for pid, amount in [(1, 500), (2, 1200), (3, 300)]:
        primary.execute("INSERT INTO payments VALUES (?, ?)", (pid, amount))
        primary.commit(); log.append((pid, amount)); latency += 1   # 1 ms local WAL flush
        if mode == "sync" or len(log) % 2 == 0:       # async: log reaches replica in batches of 2
            replica.executemany("INSERT INTO payments VALUES (?, ?)", log[shipped:])
            replica.commit(); shipped = len(log)
            latency += rtt_ms if mode == "sync" else 0  # sync waits for the replica's reply
        print(f"{mode:5} commit {pid} -> OK to client | replica has {shipped}/{len(log)}")
    seen = replica.execute("SELECT COUNT(*) FROM payments WHERE id = 3").fetchone()[0]
    print(f"{mode:5} read payment 3 from replica: {'found' if seen else 'NOT FOUND (lag)'}")
    primary.close()                                    # primary dies; promote the replica
    n, total = replica.execute("SELECT COUNT(*), SUM(amount) FROM payments").fetchone()
    print(f"{mode:5} after failover: {n} of 3 payments, total {total}, latency {latency} ms\n")
for m in ("async", "sync"):
    scenario(m)

async commit 1 -> OK to client | replica has 0/1
async commit 2 -> OK to client | replica has 2/2
async commit 3 -> OK to client | replica has 2/3
async read payment 3 from replica: NOT FOUND (lag)
async after failover: 2 of 3 payments, total 1700, latency 3 ms

sync  commit 1 -> OK to client | replica has 1/1
sync  commit 2 -> OK to client | replica has 2/2
sync  commit 3 -> OK to client | replica has 3/3
sync  read payment 3 from replica: found
sync  after failover: 3 of 3 payments, total 2000, latency 27 ms

Multi-primary, সংক্ষেপে। একাধিক নোডে একসাথে লেখা নিলে (multi-primary) একই সারি দুই জায়গায় একসাথে বদলালে কোনটি টিকবে? “শেষ লেখক জেতে” নিঃশব্দে একটি লেখা ফেলে দেয়; commit-এর আগে দ্বন্দ্ব যাচাই (MySQL Group Replication বা Galera-র ধাঁচ) একটিকে বাতিল করে। তাই বেশিরভাগ ব্যবস্থা একটি primary-তেই লেখে, আর লেখার চাপ বেশি হলে ডেটা ভাগ করে (sharding, পর্ব ৫৪)।

৮ · Failover, split-brain আর consensus

primary মরলে একটি replica-কে primary বানিয়ে (promote) অ্যাপকে তার দিকে ঘোরানো — failover. পরিকল্পিত, শান্ত অবস্থায় একই কাজ (যেমন সার্ভার আপডেটের জন্য) হলো switchover — এতে আগে সব log পাঠিয়ে নেওয়া যায়, তাই কিছু হারায় না। হাতে (manual) failover-এ মানুষ বুঝে সিদ্ধান্ত নেন, কিন্তু রাত তিনটায় কাউকে জাগিয়ে কমান্ড চালাতে মিনিট থেকে ঘণ্টা লাগে। স্বয়ংক্রিয় failover সেকেন্ডে কাজ করে, কিন্তু কঠিন প্রশ্নের মুখে পড়ে: primary কি সত্যিই মরেছে, নাকি শুধু আমি তাকে দেখতে পাচ্ছি না?

এখানে মূল যন্ত্র quorum: n সদস্যের দলে সিদ্ধান্তে লাগে ⌊n/২⌋ + ১ জনের সম্মতি। দুটি majority সবসময় অন্তত একজন সদস্যে মেলে, তাই একই সময়ে দুই দিকে দুটি “বৈধ” সিদ্ধান্ত হতে পারে না। ৩ সদস্য ১টি, ৫ সদস্য ২টি ব্যর্থতা সইতে পারে; আর ৪ সদস্য ৩-এর চেয়ে বেশি কিছু সয় না (majority ৩), তাই সংখ্যাটি সাধারণত বিজোড়। etcd এর জন্য Raft নামের consensus অ্যালগরিদম ব্যবহার করে। প্রচলিত টুল: PostgreSQL-এ Patroni (etcd, Consul, ZooKeeper বা Kubernetes-এর ওপর); MySQL-এ orchestrator বা InnoDB Cluster; আর ক্লাউডের managed database-এ (পর্ব ৬১) প্রদানকারী নিজেই standby আর failover চালায় — তবে কতটা হারাতে পারে আর কতক্ষণ লাগে, ডকুমেন্টেশনে পড়ে নেওয়া আপনার দায়িত্ব।

Read replica-য় পড়া পাঠানো

Read replica-র সুবিধা পেতে কোয়েরিকে ঠিক জায়গায় পাঠাতে হয়। পথ তিনটি: অ্যাপে দুটি সংযোগ (লেখায় primary, পড়ায় replica); ProxySQL (MySQL) বা HAProxy, Pgpool-II-এর মতো proxy; আর ড্রাইভারের সুবিধা — PostgreSQL-এর libpq একাধিক host থেকে target_session_attrs দিয়ে লেখা-যোগ্য সার্ভারটি খুঁজে নেয়। নিয়ম: transaction-এর ভেতরের আর লেখার পরপর একই ব্যবহারকারীর পড়া primary-তে; রিপোর্টের মতো কিছুটা পুরোনো ডেটা চলে এমন পড়া replica-তে।

# প্রথমে db1, না পেলে db2 — যেটি লেখা নিতে পারে (primary) সেটিতে যুক্ত হও
postgresql://app@db1:5432,db2:5432/shop?target_session_attrs=read-write

৯ · Availability মাপা — “কয়টি nine”

Availability = সেবা চালু থাকার সময় ÷ মোট সময়। চুক্তিতে (SLA) প্রায়ই লেখা থাকে “৯৯.৯%” বা “তিনটি nine”. শুনতে কাছাকাছি, কিন্তু প্রতিটি বাড়তি nine অনুমোদিত বন্ধ-সময় দশ ভাগের এক ভাগে নামায়। এক বছর = ৩৬৫ × ২৪ = ৮,৭৬০ ঘণ্টা; ৯৯.৯% মানে ০.১% বন্ধ = ৮.৭৬ ঘণ্টা। পুরো সারণি SQL-এ (এটি নমুনা ডেটাবেস ছাড়াই চলে):

WITH targets(label, a) AS (
  VALUES ('99%', 0.99), ('99.9%', 0.999), ('99.99%', 0.9999), ('99.999%', 0.99999))
SELECT label,
       ROUND((1 - a) * 365 * 24, 2)      AS hours_per_year,
       ROUND((1 - a) * 365 * 24 * 60, 1) AS minutes_per_year,
       ROUND((1 - a) * 30 * 24 * 60, 1)  AS minutes_per_30_days
FROM targets;
SELECT ROUND(0.999 * 0.999 * 100, 3)                   AS app_then_db_percent,
       ROUND((1 - (1 - 0.999) * (1 - 0.999)) * 100, 4) AS two_db_copies_percent;

আরেকটি দৃষ্টিভঙ্গি: availability = MTBF ÷ (MTBF + MTTR) — গড়ে কতদিন পরপর ব্যর্থতা, আর সারাতে গড়ে কত সময়। ব্যর্থতা কমানো কঠিন, কিন্তু MTTR কমানো প্রায়ই সহজ: স্বয়ংক্রিয় failover, অনুশীলন করা runbook, মহড়া দেওয়া restore. বছরে চারবার ব্যর্থ হয়ে প্রতিবার ২ মিনিটে ফেরা (মোট ৮ মিনিট) বছরে একবার ৬ ঘণ্টা বন্ধ থাকার চেয়ে অনেক ভালো।

১০ · AI-এর যুগে backup আর replication-এর পরিকল্পনা

AI মিনিটে একটি backup script বা replication-এর কনফিগ লিখে দেয়। সমস্যা হলো, সেগুলো প্রায়ই চলে — আর ভুলটি ধরা পড়ে বিপদের দিনে। সাধারণ ভুল:

AI-এর পরিকল্পনা মানার আগে — চেকলিস্ট

• প্রতিটি বিপদের (হার্ডওয়্যার, ভুল কমান্ড, ransomware, শহরের বিপর্যয়) জন্য কোন কপি বাঁচাবে, লিখে নিয়েছি
• অন্য সার্ভারে পুরো restore আর একটি PITR নিজে করে সময় মেপেছি, আর সারির সংখ্যা ও কয়েকটি কোয়েরির ফল মিলিয়েছি
• ব্যর্থ backup আর বেশি replication lag-এ সতর্কবার্তা আসে, আর সেটি সত্যিই কারও কাছে পৌঁছায় — পরীক্ষা করেছি
• অন্তত একটি কপি অন্য জায়গায় আর এমন নিয়ন্ত্রণে, যা মূল সার্ভারের পাসওয়ার্ড দিয়ে মোছা যায় না; encryption-এর চাবি আলাদা রাখা
• স্বয়ংক্রিয় failover-এ quorum আর fencing আছে, আর পরীক্ষামূলক পরিবেশে primary বন্ধ করে ও নেটওয়ার্ক কেটে মহড়া দিয়েছি