Recovery — log, WAL, checkpoint আর ARIES

১ · কী ভাঙতে পারে — ব্যর্থতা আর স্টোরেজের ধরন

পর্ব ৪৪-এ ACID-এর দুটি প্রতিশ্রুতি দেখেছেন: atomicity (হয় পুরো কাজ, নয় কিছুই না) আর durability (commit হলে আর হারাবে না)। এই দুই প্রতিশ্রুতি রাখার দায়িত্ব DBMS-এর recovery manager-এর। আর সে কাজটি করে এমন সময়ে, যখন সবকিছু ভেঙে পড়েছে।

এখান থেকেই স্টোরেজের তিন ধারণা। Volatile storage (RAM, CPU cache) বিদ্যুৎ গেলে মুছে যায়। Non-volatile storage (SSD, HDD) crash-এ টেকে, কিন্তু ডিস্ক নিজেও মরতে পারে। Stable storage একটি আদর্শ: যা কখনো হারায় না। বাস্তবে একে কাছাকাছি আনা হয় একাধিক স্বাধীন কপি দিয়ে — RAID-এর mirror, অন্য ভবন বা অন্য শহরে replica. বইয়ের যুক্তিতে ধরা হয়, log থাকে stable storage-এ; তাই log-এর নিরাপত্তাই পুরো recovery-র ভিত্তি।

২ · Buffer pool কেন কাজটা কঠিন করে — steal আর force

পর্ব ৩৯-এ দেখেছেন, DBMS page বদলায় মেমোরির buffer pool-এ, আর dirty page পরে সুবিধামতো ডিস্কে লেখে। সমস্যা এখানেই: crash-এর মুহূর্তে ডিস্কে কিছু page নতুন, কিছু পুরোনো, আর কোনটি কোন transaction-এর, ডিস্ক নিজে জানে না। buffer manager-এর দুটি সিদ্ধান্ত ঠিক করে recovery-কে কী কী পারতে হবে। এই দুটি নাম দেন Theo Härder আর Andreas Reuter, ১৯৮৩ সালের প্রবন্ধে — যেখানে ACID শব্দটিও প্রথম আসে:

• Steal: commit হয়নি এমন transaction-এর dirty page কি ডিস্কে লেখা যায় (frame “চুরি” করে অন্য page-কে দিতে)? হ্যাঁ হলে steal, না হলে no-steal.
• Force: commit-এর আগে কি transaction-এর সব বদলানো page ডিস্কে লিখতেই হবে? হ্যাঁ হলে force, না হলে no-force.

৩ · Shadow paging আর SQLite-এর rollback journal

log ছাড়াও একটি পথ আছে: shadow paging. ডেটাবেসের সব page-এর ঠিকানা থাকে একটি page table-এ। transaction কোনো page বদলালে পুরোনোটি ছোঁয় না, নতুন জায়গায় কপি লিখে নিজের page table-এর কপিতে ঠিকানা বদলায়। commit মানে একটিমাত্র পারমাণবিক কাজ: ডিস্কের “বর্তমান page table কোনটি” লেখা ছোট pointer-টি নতুন table-এ ঘোরানো। crash হলে পুরোনো pointer পুরোনো table-কেই দেখায় — undo বা redo কিছুই লাগে না।

শুনতে চমৎকার, কিন্তু IBM-এর System R (১৯৭০-এর দশক) এটি ব্যবহার করে সমস্যাগুলো টের পায়: page ডিস্কে এলোমেলো ছড়িয়ে পড়ে, পাশাপাশি থাকা ডেটা আর পাশাপাশি থাকে না; প্রতিটি commit-এ বদলানো page আর page table লিখতে হয় (মূলত force); পুরোনো page ফেরত তোলার কাজ লাগে; আর একসাথে অনেক transaction চালানো কঠিন। তাই বড় DBMS-গুলো log-এর দিকে চলে যায়। তবে ধারণাটি মরেনি — LMDB, আর ZFS ও Btrfs-এর মতো copy-on-write ফাইল সিস্টেম এর আত্মীয়।

SQLite-এর default rollback journal আরেকটি ঘনিষ্ঠ আত্মীয়। কোনো page প্রথমবার বদলানোর আগে SQLite তার মূল কপি -journal ফাইলে লেখে আর fsync করে; তারপর ডেটাবেস ফাইলেই বদলায়। commit-এ ডেটাবেস ফাইল fsync করে journal মুছে দেয় — journal মোছাই commit-এর মুহূর্ত। crash-এর পর ডেটাবেস খুললে SQLite একটি “hot journal” পায় আর মূল page-গুলো ফিরিয়ে লেখে। অর্থাৎ এটি undo-only, force নীতি। নিচের এডিটর দোকানের নমুনা ডেটাবেসে (db-shop) চলে: customers, categories, products (product_id, name, category_id, price, stock — ১০টি পণ্য), orders আর order_items. এই পাতার SQLite-ও (sql.js) ব্রাউজারের মেমোরিতে একটি ফাইল বানিয়ে এই journal ব্যবহার করে। দেখুন undo কীভাবে কাজ করে — পুরো transaction, আর savepoint পর্যন্ত আংশিকও:

PRAGMA journal_mode;
BEGIN;
UPDATE products SET stock = stock - 5 WHERE product_id = 101;
SAVEPOINT second_item;
UPDATE products SET stock = stock - 10 WHERE product_id = 102;
ROLLBACK TO second_item;
COMMIT;
SELECT product_id, stock FROM products WHERE product_id IN (101, 102);
BEGIN;
UPDATE products SET stock = 0;
ROLLBACK;
SELECT SUM(stock) AS total_stock FROM products;

এই ব্রাউজারের ফাইলে WAL মোডও চালু করা যায়। স্বয়ংক্রিয় checkpoint বন্ধ করে ১,০০০ সারি ঢুকিয়ে দেখি WAL-এ কতগুলো page (frame) জমল:

PRAGMA journal_mode = WAL;
PRAGMA synchronous;
PRAGMA wal_autocheckpoint = 0;
CREATE TABLE sales (id INTEGER PRIMARY KEY, amount INTEGER);
WITH RECURSIVE s(x) AS (SELECT 1 UNION ALL SELECT x + 1 FROM s WHERE x < 1000)
INSERT INTO sales SELECT x, x * 10 FROM s;
PRAGMA wal_checkpoint;
INSERT INTO sales VALUES (1001, 50);
PRAGMA wal_checkpoint;
PRAGMA wal_checkpoint(TRUNCATE);

৪ · Write-ahead logging — নিয়ম, log record আর LSN

Write-ahead log (WAL) একটি শুধু-শেষে-যোগ-করা ফাইল। প্রতিটি পরিবর্তনের একটি বিবরণ — log record — আগে এখানে লেখা হয়, তারপর আসল page বদলায়। ব্যাংকের ক্যাশিয়ারের খাতার মতো: টাকা গোনার আগে খাতায় লেখা, আর খাতার কোনো লাইন কখনো মোছা হয় না। log record-এর প্রধান ধরন:

প্রতিটি record-এর একটি ক্রমবর্ধমান নম্বর: LSN (log sequence number) — বাস্তবে প্রায়ই log ফাইলের ভেতরের বাইট-অফসেট। একই transaction-এর আগের record-এর LSN থাকে prevLSN-এ, ফলে প্রতিটি transaction-এর record-গুলো পেছনের দিকে একটি শিকল। আর প্রতিটি data page-এর হেডারে লেখা থাকে সেই page-কে শেষবার বদলানো record-এর LSN: pageLSN. DBMS মেমোরিতে মনে রাখে log কতদূর ডিস্কে পৌঁছেছে: flushedLSN. এবার দুই নিয়ম:

Group commit — একটি fsync, অনেক commit

নিয়ম ২-এর দাম একটি fsync, যা SSD-তে কয়েক দশ µs থেকে ms, আর HDD-তে কয়েক ms. প্রতিটি commit যদি নিজের fsync-এর জন্য লাইনে দাঁড়ায়, তবে HDD-তে সেকেন্ডে কয়েকশো commit-এর বেশি সম্ভব নয়। সমাধান group commit: একই মুহূর্তে অপেক্ষারত অনেক transaction-এর COMMIT record একসাথে log-এ লিখে একটিমাত্র fsync. বাসস্ট্যান্ডে প্রতিটি যাত্রীর জন্য আলাদা বাস না ছেড়ে, ভরলে একটি বাস ছাড়ার মতো। প্রত্যেকের latency সামান্য বাড়তে পারে, কিন্তু throughput বহু গুণ বাড়ে। PostgreSQL, InnoDB — সবাই এটি করে।

এবার আমাদের উদাহরণের পুরো log দেখুন। এটি একটি সাধারণ টেবিল log: lsn, prev_lsn, txn, type, page, item (কোন মান), before_val, after_val আর CLR-এর জন্য undo_next. তিনটি transaction — T1, T2, T3 — চারটি page-এ ছয়টি মান (A–F) বদলেছে; LSN ১২০-এর পর crash. পাশে আরও তিনটি টেবিল আছে, যা অংশ ৭-এ লাগবে: ckpt_att, ckpt_dpt আর disk.

SELECT lsn, prev_lsn, txn, type, page, item,
       before_val, after_val, undo_next
FROM log ORDER BY lsn;

৫ · Deferred বনাম immediate update — কে redo, কে undo

বইয়ে দুটি সরল recovery কৌশল আগে শেখানো হয়, ARIES-এর ভিত্তি হিসেবে:

যাদের COMMIT log-এ আছে তারা বিজয়ী (winner); যাদের নেই তারা পরাজিত — loser. log টেবিল থেকে এই ভাগ একটি GROUP BY-তেই:

SELECT txn,
       group_concat(type, ' → ') AS records,
       CASE WHEN SUM(type = 'COMMIT') > 0 THEN 'winner: REDO'
            ELSE 'loser: UNDO' END AS fate
FROM log
WHERE txn IS NOT NULL
GROUP BY txn;

এবার immediate update-এর দুই তালিকা: undo পেছন থেকে (বড় LSN আগে), redo সামনে থেকে:

SELECT lsn, txn, item, after_val AS now_val, before_val AS restore_to
FROM log
WHERE type = 'UPDATE'
  AND txn NOT IN (SELECT txn FROM log WHERE type = 'COMMIT')
ORDER BY lsn DESC;
SELECT lsn, txn, item, after_val
FROM log
WHERE type = 'UPDATE'
  AND txn IN (SELECT txn FROM log WHERE type = 'COMMIT')
ORDER BY lsn;

কেন এটি কাজ করে — একটি ছোট প্রমাণ

দাবি: WAL-এর দুই নিয়ম মানলে crash-এর পর redo (বিজয়ীদের) আর undo (পরাজিতদের, উল্টো ক্রমে) শেষে ডেটাবেসে ঠিক বিজয়ীদের কাজ থাকে, পরাজিতদের কিছুই না।

1. পরাজিতের কোনো পরিবর্তন ডিস্কে থাকলে তার before image log-এ আছে। পরিবর্তনটি ডিস্কে গেছে page লেখার মাধ্যমে, আর নিয়ম ১ বলে তার আগে সেই record ডিস্কে গেছে। তাই undo সম্ভব।
2. বিজয়ীর সব পরিবর্তনের after image log-এ আছে। নিয়ম ২ অনুযায়ী COMMIT record ডিস্কে, আর log ক্রম মেনে লেখা হয় বলে তার আগের সব record-ও। page না লেখা হলেও redo সম্ভব।
3. বারবার করলেও ফল একই। redo-তে LSN ≤ pageLSN হলে record বাদ যায়, তাই কোনো record একটি page-এ দুবার বসে না। recovery-র মাঝে আবার crash হলে আবার শুরু করলেই চলে — এই গুণকে বলে idempotency.

strict 2PL (পর্ব ৪৬) ধরে নেওয়া হয়েছে: পরাজিতের লেখা কোনো মান বিজয়ী পড়েনি বা ওপরে লেখেনি। নইলে পরাজিতকে উল্টালে বিজয়ীর কাজও নষ্ট হতো।

৬ · Checkpoint — recovery কতক্ষণ লাগবে, তার সীমা

checkpoint ছাড়া recovery-কে log-এর একেবারে শুরু থেকে পড়তে হতো — এক বছর চলা সার্ভারে এক বছরের log! Checkpoint মাঝে মাঝে log-এ একটি চিহ্ন বসায়: “এর আগের কাজ নিয়ে আর ভাবতে হবে না” বা অন্তত “ঠিক কোথা থেকে ভাবতে হবে”।

Dirty page table-এ প্রতিটি dirty page-এর পাশে থাকে recLSN: যে record প্রথম page-টিকে dirty করেছিল তার LSN — অর্থাৎ ডিস্কের কপিতে এর আগের সব কিছু আছে, এর পর থেকে হয়তো নেই। তাই redo শুরু হয় সব recLSN-এর ক্ষুদ্রতমটি থেকে, যা checkpoint-এর আগেও হতে পারে। আমাদের উদাহরণে checkpoint ৩০-এ, কিন্তু P1 ১০ থেকে dirty, তাই redo শুরু ১০ থেকে।

recovery-র সময় তাহলে বাঁধা থাকে দুটি জিনিসে: শেষ checkpoint থেকে কত log (analysis), আর সবচেয়ে পুরোনো dirty page কত আগের (redo). এজন্যই সিস্টেমগুলো পেছনে ক্রমাগত dirty page লেখে — পুরোনো recLSN বিদায় নেয়, redo-র শুরু সামনে আসে। PostgreSQL-এ checkpoint_timeout-এর default ৫ মিনিট আর max_wal_size ১ GB; দুটির যেটি আগে আসে। ঘন checkpoint মানে দ্রুত recovery, কিন্তু বেশি লেখা (আর PostgreSQL-এ full page write বেশি, অংশ ৮); বিরল checkpoint উল্টো।

৭ · ARIES — analysis, redo আর undo

ARIES (Algorithms for Recovery and Isolation Exploiting Semantics) প্রকাশ করেন IBM-এর C. Mohan, Don Haderle, Bruce Lindsay, Hamid Pirahesh আর Peter Schwarz, ১৯৯২ সালে ACM TODS জার্নালে। steal + no-force, fine-grained (সারি-স্তরের) lock আর আংশিক rollback — সবকিছু একসাথে সামলানো এর লক্ষ্য। IBM DB2 আর Microsoft SQL Server-এর recovery ARIES-এর ধারণায় দাঁড়ানো বলে ব্যাপকভাবে পরিচিত, আর প্রায় সব পাঠ্যবই এটিকেই আদর্শ ধরে। তিনটি মূলনীতি: WAL; repeating history — redo-তে crash-এর মুহূর্তের অবস্থা হুবহু আবার গড়া, পরাজিতদের কাজসহ; আর undo-কেও log করা CLR দিয়ে।

restart():
  ATT, DPT ← END_CKPT থেকে (master record দেখিয়ে দেয়)
  ANALYSIS: checkpoint থেকে log-এর শেষ পর্যন্ত, সামনে
     update/CLR: ATT[T].lastLSN ← lsn; page DPT-তে না থাকলে DPT[page] ← lsn
     COMMIT: ATT[T].status ← C        END: ATT থেকে T বাদ
  REDO: min(DPT.recLSN) থেকে, সামনে, প্রতিটি update/CLR r:
     if r.page ∈ DPT and r.lsn ≥ DPT[r.page].recLSN and pageLSN(r.page) < r.lsn:
        r প্রয়োগ; pageLSN ← r.lsn
  UNDO: ToUndo ← {ATT-এর বাকি (loser) সবার lastLSN}
     while ToUndo খালি নয়: r ← সবচেয়ে বড় LSN
        CLR হলে: ToUndo += r.undoNextLSN
        update হলে: CLR লেখো (undoNextLSN = r.prevLSN), উল্টাও; ToUndo += r.prevLSN
        পরেরটি NULL হলে: সেই transaction-এর END লেখো

এবার আমাদের log-এ পুরো হিসাব। শুরুর মান ছিল A=100, B=50, C=30, D=5, E=1, F=7. crash-এর মুহূর্তে ডিস্কের অবস্থা (disk টেবিল): P1 একবার লেখা হয়েছিল LSN ৭০-এর পর (pageLSN ৭০, A=80, D=9); P3 লেখা হয়েছিল ৫০-এর পর (pageLSN ৫০, C=35); P2 আর P4 কখনো লেখা হয়নি (pageLSN ০)। লক্ষ করুন, P1 আর P3-এ অসমাপ্ত কাজ ডিস্কে — steal.

LSN prev txn type    page  বিবরণ
10   –   T1  UPDATE  P1    A 100→80
20   –   T2  UPDATE  P2    B 50→70
30           BEGIN_CKPT
40           END_CKPT  ATT{T1:10,T2:20}
                       DPT{P1:10,P2:20}
50   10  T1  UPDATE  P3    C 30→35
60   20  T2  COMMIT
70   –   T3  UPDATE  P1    D 5→9
80   60  T2  END
90   50  T1  UPDATE  P4    E 1→2
100  70  T3  UPDATE  P2    F 7→8
110  90  T1  ABORT
120  110 T1  CLR     P4    E→1, undoNext 50
     ✗ crash

ধাপ ১ — Analysis

analysis-এর দুই টেবিল SQL দিয়েও বানানো যায়: checkpoint-এর কপি নিয়ে তার পরের record-গুলো জুড়ে দেওয়া।

WITH after_ckpt AS (
  SELECT * FROM log WHERE lsn > (SELECT lsn FROM log WHERE type = 'BEGIN_CKPT'))
SELECT txn, MAX(last_lsn) AS last_lsn
FROM (SELECT txn, last_lsn FROM ckpt_att
      UNION ALL SELECT txn, lsn FROM after_ckpt WHERE txn IS NOT NULL)
WHERE txn NOT IN (SELECT txn FROM after_ckpt WHERE type = 'END')
GROUP BY txn;
WITH after_ckpt AS (
  SELECT * FROM log WHERE lsn > (SELECT lsn FROM log WHERE type = 'BEGIN_CKPT'))
SELECT page, MIN(rec_lsn) AS rec_lsn
FROM (SELECT page, rec_lsn FROM ckpt_dpt
      UNION ALL SELECT page, lsn FROM after_ckpt WHERE type IN ('UPDATE', 'CLR'))
GROUP BY page;

ধাপ ২ — Redo: ইতিহাস হুবহু আবার

WITH dpt(page, rec_lsn) AS (VALUES ('P1', 10), ('P2', 20), ('P3', 50), ('P4', 90))
SELECT l.lsn, l.type, l.page, d.rec_lsn, k.page_lsn AS disk_lsn,
       CASE WHEN l.lsn < d.rec_lsn THEN 'skip: recLSN'
            WHEN k.page_lsn >= l.lsn THEN 'skip: pageLSN'
            ELSE 'REDO' END AS action
FROM log l JOIN dpt d USING (page) JOIN disk k USING (page)
WHERE l.type IN ('UPDATE', 'CLR')
  AND l.lsn >= (SELECT MIN(rec_lsn) FROM dpt)
ORDER BY l.lsn;

ধাপ ৩ — Undo: CLR লিখে লিখে উল্টানো

undo-তে loser-দের সব record একসাথে, বড় LSN আগে — একেক transaction আলাদা নয়, কারণ log-এ পেছনে একবার হাঁটাই সবচেয়ে কম I/O. প্রতিটি UPDATE উল্টানোর সময় একটি CLR লেখা হয়, যার undoNextLSN = সেই UPDATE-এর prevLSN — অর্থাৎ “এরপর এখান থেকে উল্টানো শুরু হবে”। আর CLR নিজে কখনো উল্টানো হয় না; তাকে দেখলে শুধু তার undoNextLSN-এ লাফ।

undo-র ক্রম SQL-এর recursive CTE (পর্ব ২৫) দিয়েও বের করা যায় — প্রতিটি loser-এর শেষ record থেকে শুরু করে CLR হলে undo_next, নইলে prev_lsn ধরে পেছনে:

WITH RECURSIVE todo(lsn) AS (
  SELECT MAX(lsn) FROM log WHERE txn IN ('T1', 'T3') GROUP BY txn
  UNION ALL
  SELECT CASE WHEN l.type = 'CLR' THEN l.undo_next ELSE l.prev_lsn END
  FROM todo JOIN log l ON l.lsn = todo.lsn
  WHERE (CASE WHEN l.type = 'CLR' THEN l.undo_next ELSE l.prev_lsn END) IS NOT NULL)
SELECT l.lsn, l.txn, l.type, l.item, l.before_val AS restore_to,
       CASE WHEN l.type = 'UPDATE' THEN 'CLR + undo' ELSE 'jump' END AS action
FROM todo JOIN log l USING (lsn)
ORDER BY l.lsn DESC;

৮ · Media recovery আর বাস্তব সিস্টেম

ডিস্কই নষ্ট হলে log-ও হয়তো গেছে। তাই media recovery-র ভিত্তি অন্য জায়গায় রাখা দুটি জিনিস: একটি পূর্ণ backup, আর তার পর থেকে জমা সব log-এর কপি — archived log. backup ফিরিয়ে এনে archived log redo করলে ডেটাবেস যেকোনো মুহূর্তে পৌঁছাতে পারে: point-in-time recovery. বিকেল ৩:০৫-এ কেউ ভুল করে DROP TABLE orders চালালে ৩:০৪:৫৯ পর্যন্ত redo করে থামা যায়। পুরো কৌশল — backup-এর ধরন, replication, high availability — পর্ব ৫২-এ।

নিচের Python প্রোগ্রাম একটি আসল ফাইলে SQLite চালায় (Python-এর sqlite3 মডিউল)। প্রথমে rollback journal-এর আয়ু দেখায়, তারপর WAL মোডে তিনটি commit-এ -wal ফাইল বাড়তে দেখায়, শেষে checkpoint. স্বয়ংক্রিয় checkpoint বন্ধ রাখা হয়েছে, যাতে হিসাব পরিষ্কার থাকে:

import os, sqlite3, tempfile
path = os.path.join(tempfile.mkdtemp(), "shop.db")
con = sqlite3.connect(path, isolation_level=None)       # we write BEGIN/COMMIT ourselves
size = lambda ext: os.path.getsize(path + ext) if os.path.exists(path + ext) else "-"
con.execute("CREATE TABLE sales (id INTEGER PRIMARY KEY, amount INTEGER)")
print("mode:", con.execute("PRAGMA journal_mode").fetchone()[0])
con.execute("BEGIN")
con.execute("INSERT INTO sales (amount) VALUES (100)")
print("inside txn, -journal bytes:", size("-journal"))
con.execute("COMMIT")
print("after commit, -journal bytes:", size("-journal"))
print("mode:", con.execute("PRAGMA journal_mode = WAL").fetchone()[0])
con.execute("PRAGMA wal_autocheckpoint = 0")              # no automatic checkpoint
for batch in range(1, 4):
    con.execute("BEGIN")
    con.executemany("INSERT INTO sales (amount) VALUES (?)", [(i,) for i in range(400)])
    con.execute("COMMIT")
    print(f"commit {batch}: db={size('')} wal={size('-wal')}")
print("FULL checkpoint (busy, log, done):", con.execute("PRAGMA wal_checkpoint(FULL)").fetchone())
print(f"after FULL: db={size('')} wal={size('-wal')}")
con.execute("PRAGMA wal_checkpoint(TRUNCATE)")
print(f"after TRUNCATE: db={size('')} wal={size('-wal')}")

mode: delete
inside txn, -journal bytes: 4616
after commit, -journal bytes: -
mode: wal
commit 1: db=8192 wal=4152
commit 2: db=8192 wal=20632
commit 3: db=8192 wal=37112
FULL checkpoint (busy, log, done): (0, 9, 9)
after FULL: db=20480 wal=37112
after TRUNCATE: db=20480 wal=0

৯ · fsync, ডিস্কের “মিথ্যা” আর synchronous_commit

WAL-এর পুরো প্রমাণ একটি অনুমানের ওপর: fsync “সফল” বললে log সত্যিই টেকসই। কিন্তু মাঝখানে কয়েকটি স্তর: DBMS → OS-এর page cache → ডিস্কের নিজস্ব RAM cache → আসল flash বা চৌম্বক থালা। অনেক ডিস্কে একটি volatile write cache থাকে, যা লেখা নিজের RAM-এ পেয়েই “হয়ে গেছে” বলতে পারে। fsync-এর পর OS ডিস্ককে cache খালি করার নির্দেশ (flush) পাঠায় — যদি ডিস্ক সেটি সত্যিই মানে। কিছু সস্তা ডিস্ক বা ভুল কনফিগার করা RAID controller flush উপেক্ষা করে বলে বহু বছর ধরে অভিযোগ আর পরীক্ষার রিপোর্ট আছে; আবার ভালো server SSD-তে ক্যাপাসিটর থাকে, যা বিদ্যুৎ গেলেও cache-এর ডেটা লিখে ফেলে (power-loss protection).

অন্য দিকে, কিছু অ্যাপ জেনেশুনে একটু durability ছেড়ে গতি নেয়। PostgreSQL-এর synchronous_commit:

লক্ষ করুন “হারানো” আর “নষ্ট হওয়া”-র পার্থক্য। synchronous_commit = off-এ WAL-এর ক্রম আর নিয়ম ১ অক্ষত; শুধু commit record একটু দেরিতে ডিস্কে যায়। তাই crash-এর পর ডেটাবেস একটু আগের একটি সংগত অবস্থায় ফেরে। fsync = off-এ নিয়ম ১-ই ভাঙে — page আগে, log পরে পৌঁছাতে পারে — তাই অসংগত, এমনকি পড়া যায় না এমন ডেটাবেস। একটি ওয়েবসাইটের “page view” গোনা off-এ চলতে পারে; bKash-এর লেনদেন কখনোই নয়। PostgreSQL-এ এটি এক সংযোগ বা এক transaction-এর জন্যও বদলানো যায়:

SHOW synchronous_commit;            -- on
SHOW full_page_writes;              -- on
BEGIN;
SET LOCAL synchronous_commit = off; -- শুধু এই transaction-এ
INSERT INTO page_views (url, seen_at) VALUES ('/home', now());
COMMIT;
CHECKPOINT;                          -- হাতে checkpoint (superuser বা pg_checkpoint ভূমিকা)

১০ · AI-এর যুগে recovery আর durability-র প্রশ্ন

“ডেটাবেসে লেখা ধীর, দ্রুত করো” — AI প্রায়ই এমন সেটিং সুপারিশ করে যা গতি দেয়, কিন্তু নিঃশব্দে durability কেড়ে নেয়। সাধারণ ভুল:

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

• প্রতিটি সেটিং durability কমায় কি না, আর কমালে কতটা (হারানো না নষ্ট হওয়া), লিখে নিয়েছি
• fsync বা doublewrite বন্ধ করার কোনো পরামর্শ আসল ডেটায় মানিনি
• সেটিংয়ের নাম আর default মান নিজের সংস্করণের ডকুমেন্টেশনে মিলিয়েছি (SHOW, SHOW VARIABLES, PRAGMA)
• পরীক্ষামূলক সার্ভারে লেখার মাঝে প্রক্রিয়া মেরে (kill) recovery আর ডেটার সঠিকতা যাচাই করেছি
• backup থেকে অন্য জায়গায় পুরো restore আর point-in-time recovery অন্তত একবার করে দেখেছি