git.iko.soy/project-m36
on master help sign in
add replication/locking documentation
commit593df5380a137dfa9b6de106ee5ef11228d3ef8f authorAgentM <agentm@themactionfaction.com> dateMon 12 Jun 2017, 17:42 (9 years ago) parente545b7f
3 files changed+40−2
compare with master
unifiedsplit
Changelog.markdown+8 docs/acid_assessment.markdown+2−2 docs/replication.markdown+30
Changelog.markdown+8
@@ -1,3 +1,11 @@
1+# 2017-06-12
2+
3+## add file locking
4+
5+This [feature](#102) allows Project:M36 database directories to be shared amongst multiple Project:M36 processes. This is similar to how SQLite operates except that the remote server mode supports the feature as well. This could allow, for example, multi-master, file-based replication across Windows shares or NFS.
6+
7+[Documentation](/docs/replication.markdown)
8+
19# 2016-11-30
210
311## add functional dependency macro
docs/acid_assessment.markdown+2−2
@@ -41,6 +41,6 @@ However, Project:M36 allows the user to disable fsync()'ing, for example, for th
4141
4242In addition, Project:M36 relies on the user to use Project:M36 databases on ordered, journaled metadata filesystems only. A future improvement could be to detect scenarios under which Project:M36 is not offering guaranteed durability. Write-ahead-logs do not suffer from this requirement.
4343
44−We feel that these potential pitfalls warrant removing an arbitrary 10% from the compliance scale because there is room for further improvement here. It is, however, possible to use Project:M36 with full durability guarantees.
44+Database directories can be shared across multiple Project:M36 database processes. This operates similarly to SQLite and relies on POSIX advisory locking and Windows file locking to ensure consistency.
4545
46−Compliance: 90%
46+Compliance: 100%
docs/replication.markdownnew file+30
@@ -0,0 +1,30 @@
1+# Project:M36 Multi-Node Replication
2+
3+## Introduction
4+
5+The stored transaction graph feature makes Project:M36 naturally more suitable for replication. Just like with git, having access to historical transactions makes merging transactional data much more logical and unambiguous.
6+
7+## Current Multi-Master Support
8+
9+Project:M36 plans to support logical replication in the future. In the meantime, multi-master replication is supported through shared database directories. Using NFS or SMB shares where file locking is properly supported, one can run multiple ```project-m36-server``` instances on the same database directory. This is a shared-storage form of multi-master operation.
10+
11+Multi-master replication is enabled and reasonably fast due to the intentional design decision to rewrite as few files as possible. Typical databases write and rewrite the same files which back relation variables (or tables) directly which necessitates heavy use of file locking or even locks on file content regions. Project:M36 operates on a write-once, read-many (WORM) principle whereby transaction data can be written without holding locks so only the transaction graph itself needs synchronization.
12+
13+Multi-master support can also be useful for simple databases where one wishes to avoid running and maintaining a ```project-m36-server```. Instead, one can create in-process database instances which share the same database directory. This is similar to the use-case for SQLite. However, Project:M36 seamlessly supports server and in-process modes which makes moving from a small, local database to a larger server installation trivial; the storage format is identical.
14+
15+To use the simple multi-master mode, start two instances of ```project-m36-server``` which point at the same local or remote database directory over NFS or SMB. No further configuration is required.
16+
17+## Caveats
18+
19+Project:M36 does not and cannot detect if the filesystem's implementation of file locking is actually functioning.
20+
21+On Linux and macOS, any recent on-disk filesystems and NFS should support POSIX advisory locking, as required. However, sharing the database over samba (SMB) shares or mixed operating systems may result in database transaction graph corruption. The symptom will be that arbitrary, committed transactions may be missing from the transaction graph.
22+
23+On Windows, locking is implemented using mandatory locking controls which any supported version of Windows offers. Cross-platform use of locking (such as with samba server on Linux) is probably *not* safe.
24+
25+If a commit happens behind the back of another ```project-m36-server``` and one server attempts to commit, two possibilities can occur:
26+
27+1. The commits occurred on two disparate branches, so the transaction graph can be updated without conflict.
28+1. The commits occurred on the same branch, so one transaction commit will be rejected with a ```TransactionIsNotAHead``` error. This means that the head (leaf node) of the transaction graph for that branch has moved on, so the transaction needs to be re-executed and committed.
29+
30+To avoid ```TransactionIsNotAHead``` errors, branch the transaction graph and merge it to the head when ready to commit.