The four long-lived processes

• cub_master — per-host supervisor. Listens on TCP, hands the file descriptor to the right cub_server. UDP heartbeat between peers. Does not own DB state.
• cub_server — database engine. One per database. Owns volumes, page buffer, log, lock table, catalog, optimizer, MVCC, vacuum.
• cub_pl — PL JVM. One per cub_server. Java SPs + PL/CSQL; calls back over per-session UDS.
• cub_broker + cub_cas — broker tier. Pre-forked CAS pool; rendezvous-passes sockets via SCM_RIGHTS.

Plus utility processes (loaddb, backupdb, …) that dlopen libcubridsa.so directly.

Process model — diagram

• TCP listener on cub_master, not cub_server. Master routes by DB name, hands over the file descriptor.
• Broker is a separate tier with its own TCP hop. cub_pl is a sibling JVM to cub_server.

Layered storage stack — diagram

Rule: every record layer talks to the page buffer, never to the disk manager. That is what lets the buffer enforce WAL ordering.

Each storage layer in one sentence

Pipeline stages in one sentence

Concurrency, logging, recovery — diagram

• Three timelines co-exist — transactional (MVCCIDs + locks), physical (WAL + LSAs), page (dirty BCBs).
• WAL is split via a per-tx prior list; group commit emerges from queue batching.

Each subsystem in one sentence

Distribution — diagram

• cub_master is the gossip endpoint — heartbeat is independent per node; witness hosts guard split-brain.
• The WAL is CUBRID's single event log — recovery, vacuum, replication, CDC, flashback, backup all read the same stream; they differ only in which record types and which direction.

Cross-cutting infrastructure

The three SA / CS / utility build variants

• Why this exists. Admin ops (backupdb, loaddb, compactdb) need to touch disk with no running cub_server — SA mode dlopens the entire engine in-process.
• csql is both. --CS-mode links libcubridcs.so; offline, links libcubridsa.so. A single flag flips the dispatch.
• Detail: cubrid-sa-cs-runtime.md, cubrid-csql.md.

Subcategory map — where to start

Reading paths — three guided routes

Three vertical slices across subcategories. Pick the one that matches what you're debugging.

(a) Single query — "SELECT from broker to heap and back"

cubrid-rpath-select.md → parser → semantic-check → rewrite → optimizer → xasl-generator → query-executor → scan-manager → list-file → cursor

(b) Transaction commit — "what makes COMMIT durable"

cubrid-rpath-write.md → locator → heap-manager → mvcc → lock-manager → prior-list → log-manager → DWB → page-buffer → checkpoint → recovery-manager

(c) HA failover — "cub_master declares a new primary"

cubrid-heartbeat.md → master-process → ha-replication → cdc → 2pc → flashback → backup-restore