Metadata in RAM, changelogs, and dumps
The Master Server answers every metadata request from RAM: one process holds the whole metadata of the instance in its memory. What metadata holds covers what that set contains and what it costs. Every change to the set is appended to a changelog as one text line, at the moment the operation happens. On a schedule, the Master Server also writes a dump, a complete copy of everything in RAM at one moment. The mechanics of both files are described in changelogs, dumps, and the recovery point.
Two kinds of file are held by three modules
The disk never holds the working copy. The disk holds the record that the working copy can be rebuilt from, in two artifacts:
| Artifact | Who writes it | Who else holds a copy |
|---|---|---|
Dump: metadata.mfs.back, renamed to metadata.mfs by a clean stop | The Master Server, in a separate save process | A Follower Master Server PRO (PRO Edition only) saves dumps of its own, under the same names. A Metalogger downloads the dump into metadata_ml.mfs.back |
Changelog: changelog.N.mfs, one file per hour | The Master Server, through its data writer process | A Follower writes the stream into changelog files of its own. A Metalogger appends each incoming line to changelog_ml.N.mfs |
The page of each module lists all of its files: the Master Server and the Metalogger. The ways that a save can be made, and how a server reports the way that it last used, are described in the metadata save states.
Each changelog line also goes over the network
The Master Server does not only store each line. When the line is written, the Master Server also sends it to every synchronized Follower PRO (PRO Edition only) and Metalogger. The two consumers do different things with the same stream. A Follower holds the whole metadata in RAM like the Leader and applies every line to that copy, so the Follower can take the Leader's place. Leader-Follower synchronization describes that path. A Metalogger holds only files and applies nothing. The Metalogger stream describes the Metalogger's path.
The pair rebuilds the state anywhere
A dump plus every changelog written since that dump is the complete state. A Master Server started with its automatic-restore option loads the newest usable dump that it finds and replays the changelogs over that dump. A Master Server started without that option loads metadata.mfs alone and refuses to start when that file is missing. The replay works the same way on the machine that wrote the files, on a machine that holds a Metalogger's copies, or on a new machine that the files were copied to. Changelogs, dumps, and the recovery point describes how the replay verifies itself and how much work a sudden failure can cost.
Every copy of the metadata, in RAM or on disk, has the numbers that make copies comparable. The version orders dumps and changelog lines into one history. The metadata ID tells two unrelated histories apart. Metadata ID, version, delay, and checksum covers all four readings.