SlideShare a Scribd company logo

MongoDB World 2018: Transactions and Durability: Putting the “D” in ACID

MongoDB, profile picture
MongoDB

This document discusses durability in WiredTiger and MongoDB. It explains that WiredTiger provides durability through checkpoints and write-ahead logging. Checkpoints write all modified data to stable storage, while write-ahead logging provides fine-grained durability by writing each operation to the log before writing data to cache or disk. The document also discusses how different layers, from users to hardware, establish trust that data will survive failures through mechanisms like write concerns and disk flushes.

Technology
1 of 104
Downloaded 18 times
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46
47
48
49
50
51
52
53
54
55
56
57
58
59
60
61
62
63
64
65
66
67
68
69
70
71
72
73
74
75
76
77
78
79
80
81
82
83
84
85
86
87
88
89
90
91
92
93
94
95
96
97
98
99
100
101
102
103
104
Transactions and Durability: Putting the “D” in ACID Sue LoVerso - Senior Staff Engineer, Storage Team MongoDB, Inc sue@mongodb.com
Sue LoVerso Senior Staff Engineer, MongoDB Kernel Storage Team
Transaction Concepts
ACID - Atomicity • “All or nothing” • Set of operations are an indivisible unit • Example: Bank transfer: • Withdraw from Account A • Deposit into Account B
ACID - Consistency • Database constraints aren’t violated (“constraints” individually defined) • Most common in Relational Databases: constraints, triggers or cascades • Example: • [EndDate] >= [StartDate] • [Value] < 100
ACID - Isolation • Data visibility (or not) by other concurrently running transactions • Isolation levels: what data can a transaction read or write and when • WiredTiger offers visibility choices with tradeoffs
ACID - Durability • Provides guarantee that committed transactions survive permanently • Common implementation is write-ahead log (aka journal) • WiredTiger gives durability-related choices • This is not the replication oplog. This is per-node in a cluster • These are not user-level transactions
ACID - Durability Modes In-memory mode WT memory
ACID - Durability Modes In-memory mode write-no-sync mode WT memory WT memory write(2) file system buffer cache
ACID - Durability Modes Disk In-memory mode write-no-sync mode full-sync mode WT memory write(2) file system buffer cache WT memory WT memory write(2) file system buffer cache
ACID - Durability Durability Guarantee Performance Full Sync In-memory Write-no-Sync
ACID - Durability Synchronization Level Process Crash System Crash in-memory (“sync=disabled”) Potential data loss Potential data loss write-no-sync (“sync=off”) Data always recoverable Potential data loss full sync (“sync=on”) Data always recoverable Data always recoverable
Why Do We Care?
What keeps me up at night?
What keeps me up at night?
What keeps me up at night? • For storage engineers - “Losing people’s data”
How I sleep better • Durability - keep data stable and consistent
How I sleep better • Durability - keep data stable and consistent • If we say it’s stable, it really is written and synced
How I sleep better • Durability - keep data stable and consistent • If we say it’s stable, it really is written and synced • Crash: we can recover your durably written data
How I sleep better • Round the clock testing 24/7 • Randomized • Kill process • Power cycle • Both WiredTiger only and via MongoDB • Any failure is top priority work (and I mean absolute, top priority)
How I sleep better • Constant testing gives confidence in code • We think long and hard about durability guarantees • We pay close attention to OS and system call issues • We think long and hard about feature impacts on durability • We take the responsibility of keeping your data seriously
Durability All The Way Down
Layers All The Way Down Content Repo IoT Sensor Backend Ad Service Customer Analytics Archive Example Future State
Layers All The Way Down Content Repo IoT Sensor Backend Ad Service Customer Analytics Archive MongoDB Query Language (MQL) + Native Drivers Example Future State
Layers All The Way Down Content Repo IoT Sensor Backend Ad Service Customer Analytics Archive MongoDB Query Language (MQL) + Native Drivers MongoDB Document Data Model Management Security Example Future State
Layers All The Way Down Content Repo IoT Sensor Backend Ad Service Customer Analytics Archive MongoDB Query Language (MQL) + Native Drivers MongoDB Document Data Model MMAP V1 WiredTiger RocksDB Mobile Management Security Example Future State In-memory
WiredTiger Architecture Database Files Log Files WiredTiger C API Schema & Cursors Transactions Row Storage Column Storage Snapshots Cache Page read/write Block Manager Logging MongoDB Storage Engine Layer
WiredTiger Architecture Database Files Log Files WiredTiger C API Schema & Cursors Transactions Row Storage Column Storage Snapshots Cache Page read/write Block Manager Logging
Layers of Trust
Layers of Trust - User • User wants assured stability of some data User
Layers of Trust - User • User wants assured stability of some data • User gives write concern: { j : true } j:true turtles User
Layers of Trust • User gives write concern: { j : true } • https://docs.mongodb.com/manual/reference/write-concern/: • Write concern describes the level of acknowledgement requested from MongoDB for write operations … • If j: true, [the user] requests acknowledgement that the mongod instances ... have written to the on-disk journal.
Layers of Trust - MongoDB src/mongo/db/write_concern.cpp: Status waitForWriteConcern(...) { ... case WriteConcernOptions::SyncMode::JOURNAL: opCtx->recoveryUnit()->waitUntilDurable(); ... } j:true turtles User MDB
Layers of Trust - MongoDB void WiredTigerSessionCache::waitUntilDurable(...) { ... // Use the journal when available, or a checkpoint otherwise. if (_engine->isDurable()) { invariantWTOK(_Session->log_flush(_Session, "sync=on")); ... } else { invariantWTOK(_Session->checkpoint(_Session, NULL)); ... } } j:true turtles User MDB
Layers of Trust - MongoDB • MongoDB calls WT: _Session->log_flush(_Session, “sync=on”)
Layers of Trust - MongoDB • MongoDB calls: _Session->log_flush(_Session, “sync=on”) • http://source.wiredtiger.com/3.0.0/struct_w_t___s_e_s_s_i_o_n.html: log_flush: • forcibly flush the log and wait for it to achieve the synchronization level specified. The on setting forces log records to be written to the storage device.
Layers of Trust - WiredTiger int __session_log_flush(...) { ... if (WT_STRING_MATCH("on", cval.str, cval.len)) flags = WT_LOG_FSYNC; ret = __wt_log_flush(session, flags); ... } int __wt_log_flush(...) { ... if (FLAG_ISSET(WT_LOG_FSYNC)) return (__wt_log_force_sync(...)); } j:true turtles User MDB WT
Layers of Trust - WiredTiger int __wt_log_force_sync() { ... ret = __wt_fsync(session, log_fh, true)); } int __posix_sync() { ... #ifdef … WT_SYSCALL(fdatasync(fd), ret); #else WT_SYSCALL(fsync(fd), ret); #endif ... } j:true turtles User MDB WT
Layers of Trust - WiredTiger • WiredTiger calls: fsync(fd) or fdatasync(fd) • http://man7.org/linux/man-pages/man2/fdatasync.2.html • fsync() transfers ("flushes") all modified ... data of the file to the disk device ... so that all changed information can be retrieved even if the system crashes or is rebooted. ... The call blocks until the device reports that the transfer has completed.
Layers of Trust - Operating System https://elixir.bootlin.com/linux/v4.17-rc4/source/ fs/sync.c: SYSCALL_DEFINE1(fsync, unsigned int, fd) { ... ret = vfs_fsync_range(...); int vfs_fsync_range(...) ... return (file->f_op->fsync(...)); fs/xfs/xfs_file.c: int xfs_file_sync(...) ... blkdev_issue_flush(...); j:true turtles User MDB WT OS
Layers of Trust - Operating System block/blk-flush.c int blkdev_issue_flush(...) { ... bio_set_dev(...); bio->bi_opf = REQ_OP_WRITE | REQ_PREFLUSH; ret = submit_bio_wait(...); }
Layers of Trust - Device driver • Device driver sends some kind of flush operation. • Code is device specific. • Hardware is the recipient. j:true turtles User MDB WT OS Dev
Layers of Trust - Hardware • Device driver is trusting the hardware. • If the hardware lies, data could be lost in a crash. • May need to disable device write-caching: • sudo hdparm -i /dev/sda • /etc/hdparm.conf • #write-cache=off j:true turtles User MDB WT OS Dev HW
Layers of Trust - Summary
Layers of Trust - Summary • User wants assured stability of some data User
Layers of Trust - Summary • User wants assured stability of some data • User trusts MongoDB using { j : true } User MDB
Layers of Trust - Summary • User wants assured stability of some data • User trusts MongoDB using { j : true } • MongoDB trusts WiredTiger log_flush(“sync=on”) User MDB WT
Layers of Trust - Summary • User wants assured stability of some data • User trusts MongoDB using { j : true } • MongoDB trusts WiredTiger log_flush(“sync=on”) • WiredTiger trusts the OS using fsync(fd) User MDB WT OS
Layers of Trust - Summary • User wants assured stability of some data • User trusts MongoDB using { j : true } • MongoDB trusts WiredTiger log_flush(“sync=on”) • WiredTiger trusts the OS using fsync(fd) • Operating System trusts device driver User MDB WT OS Dev
Layers of Trust - Summary • User wants assured stability of some data • User trusts MongoDB using { j : true } • MongoDB trusts WiredTiger log_flush(“sync=on”) • WiredTiger trusts the OS using fsync(fd) • Operating System trusts device driver • The device driver trusts the hardware User MDB WT OS Dev HW
WiredTiger Durability
What Does Durability Mean? • Writing any data to stable storage for later retrieval • In WiredTiger: ○ Checkpoints - coarse-grained durability ○ Write-ahead logging - fine-grained durability
WiredTiger Architecture Database Files Log Files WiredTiger C API Schema & Cursors Transactions Row Storage Column Storage Snapshots Cache Page read/write Block Manager Logging
Checkpoints • Who: • Called via WT_SESSION::checkpoint() API (MongoDB) • What: • Writes all modified collections, all visible dirty data • When: • API call, internal thread period, on close • How: • Checkpoint opens a snapshot transaction, writes data
Checkpoints • Create Table:Collection
Checkpoints • Create Table:Collection Collection.wt (Disk)WT Cache (Memory)
Checkpoints • Insert some data Collection.wt (Disk)WT Cache (Memory) Apple
Checkpoints • Insert some data Collection.wt (Disk)WT Cache (Memory) Apple Banana
Checkpoints • Insert some data Collection.wt (Disk)WT Cache (Memory) Apple Banana Cherry
Checkpoints • Call WT_SESSION::checkpoint() Collection.wt (Disk)WT Cache (Memory) Apple Banana Cherry
Checkpoints • WT_SESSION::checkpoint() Collection.wt (Disk)WT Cache (Memory) Apple Banana Cherry
Checkpoints • Insert more data Collection.wt (Disk)WT Cache (Memory) Apple Banana Cherry Orange Pineapple
Crash
Crashing and Recovery • Open collection from most recent checkpoint • Any data after checkpoint is lost
Checkpoints • Restart Collection.wt (Disk)WT Cache (Memory) Apple Banana Cherry
WiredTiger Architecture Database Files Log Files WiredTiger C API Schema & Cursors Transactions Row Storage Column Storage Snapshots Cache Page read/write Block Manager Logging
Write-ahead log (aka journal) • Who: • Enabled/disabled when first creating the database • What: • Logical recording of all transaction modifications • When: • Every time a transaction commits
Write-ahead log (aka journal) • Create Table:Collection Collection.wt (Disk)WT Cache (Memory) WT Log (Disk)
Write-ahead log (aka journal) • Insert some data Collection.wt (Disk)WT Cache (Memory) WT Log (Disk) Apple Commit(Apple)
Write-ahead log (aka journal) • Insert some data Collection.wt (Disk)WT Cache (Memory) WT Log (Disk) Apple Banana Commit(Apple) Commit(Banana)
Write-ahead log (aka journal) • Insert some data Collection.wt (Disk)WT Cache (Memory) WT Log (Disk) Apple Banana Commit(Apple) Commit(Banana) Cherry Commit(Cherry)
Write-ahead log (aka journal) • Insert some more data Collection.wt (Disk)WT Cache (Memory) WT Log (Disk) Apple Banana Commit(Apple) Commit(Banana) Cherry Commit(Cherry) Orange Commit(Orange)
Write-ahead log (aka journal) • Insert some more data Collection.wt (Disk)WT Cache (Memory) WT Log (Disk) Apple Banana Commit(Apple) Commit(Banana) Cherry Commit(Cherry) Orange Commit(Orange) Pineapple Commit(Pineapple)
Crash
Crashing and Recovery • First table open: if it exists, most recent checkpoint taken • Recovery replays the entire applicable write-ahead log
Write-ahead log (aka journal) • Restart and recovery Collection.wt (Disk)WT Cache (Memory) WT Log (Disk) Commit(Apple) Commit(Banana) Commit(Cherry) Commit(Orange) Commit(Pineapple)
Write-ahead log (aka journal) • Recovery replays the operations Collection.wt (Disk)WT Cache (Memory) WT Log (Disk) Apple Banana Commit(Apple) Commit(Banana) Cherry Commit(Cherry) Orange Commit(Orange) Pineapple Commit(Pineapple)
Write-ahead log (aka journal) • Recovery checkpoints on completion Collection.wt (Disk)WT Cache (Memory) WT Log (Disk) Apple Banana Commit(Apple) Commit(Banana) CherryCommit(Cherry) OrangeCommit(Orange) PineappleCommit(Pineapple)
Checkpoints + Logging = • Faster Recovery • Less disk usage • Best of both worlds
Checkpoint + Logging • Create Table:Collection Collection.wt (Disk)WT Cache (Memory) WT Log (Disk)
Checkpoint + Logging • Insert some data Collection.wt (Disk)WT Cache (Memory) WT Log (Disk) Apple Commit(Apple)
Checkpoint + Logging • Insert some data Collection.wt (Disk)WT Cache (Memory) WT Log (Disk) Apple Banana Commit(Apple) Commit(Banana)
Checkpoint + Logging • Insert some data Collection.wt (Disk)WT Cache (Memory) WT Log (Disk) Apple Banana Commit(Apple) Commit(Banana) Cherry Commit(Cherry)
Checkpoint + Logging • WT_SESSION::checkpoint() Collection.wt (Disk)WT Cache (Memory) WT Log (Disk) Apple Banana Commit(Apple) Commit(Banana) CherryCommit(Cherry) Checkpoint
Checkpoint + Logging • Insert some more data Collection.wt (Disk)WT Cache (Memory) WT Log (Disk) Apple Banana Commit(Apple) Commit(Banana) CherryCommit(Cherry) Orange Commit(Orange) Checkpoint
Checkpoint + Logging • Insert some more data Collection.wt (Disk)WT Cache (Memory) WT Log (Disk) Apple Banana Commit(Apple) Commit(Banana) CherryCommit(Cherry) Orange Commit(Orange) Pineapple Commit(Pineapple) Checkpoint
Crash
Checkpoint + Logging • Restart and Recovery Collection.wt (Disk)WT Cache (Memory) WT Log (Disk) Apple Banana Commit(Apple) Commit(Banana) CherryCommit(Cherry) Commit(Orange) Commit(Pineapple) Checkpoint
Checkpoint + Logging • Restart and Recovery Collection.wt (Disk)WT Cache (Memory) WT Log (Disk) Apple Banana Commit(Apple) Commit(Banana) CherryCommit(Cherry) Commit(Orange) Commit(Pineapple) Checkpoint Recovery starts here
Checkpoint + Logging • Recovery replays the operations Collection.wt (Disk)WT Cache (Memory) WT Log (Disk) Apple Banana Commit(Apple) Commit(Banana) CherryCommit(Cherry) Orange Commit(Orange) Pineapple Commit(Pineapple) Checkpoint
Checkpoint + Logging • Recovery checkpoints on completion Collection.wt (Disk)WT Cache (Memory) WT Log (Disk) Apple Banana Commit(Apple) Commit(Banana) CherryCommit(Cherry) Orange Commit(Orange) Pineapple Commit(Pineapple) Checkpoint Checkpoint
Checkpoints + Logging = • Faster Recovery • Checkpoints bound recovery time. Recovery starts at previous checkpoint • Less disk usage • Checkpoints allow archival of earlier write-ahead log files • Archiving happens on whole-file basis • Fine-grained durability • Logging allows recovery of intermediary data
Transactions and Logging
Transactions + Logging • Who: • WT_SESSION::commit_transaction() • WT_SESSION::checkpoint() • Internal operations • What: • Logical recording of all transaction modifications • When: • Every time a transaction commits, before making visible
Write-Ahead Modes WT Log (Disk) Commit(Apple) Checkpoint Commit(Banana) Commit(Cherry) Commit(Orange) Commit(Pineapple) Checkpoint
Write-Ahead Modes Diskfull-sync mode WT memory write(2) file system buffer cache WT memory WT memory write-no-sync mode in-memory mode write(2) file system buffer cache WT Log (Disk) Commit(Apple) Checkpoint Commit(Banana) Commit(Cherry) Commit(Orange) Commit(Pineapple) Checkpoint
Write-Ahead Modes • Guarantees on return from commit transaction: • in-memory durability (default/MongoDB): none • write-no-sync: recoverable after process crash • full-sync: recoverable from process crash or system crash Synchronization Level Process Crash System Crash in-memory Potential data loss Potential data loss write-no-sync Data always recoverable Potential data loss full sync Data always recoverable Data always recoverable
Write-ahead In-memory Mode • Why have it? Why use it? • When does it become durable?
Write-ahead In-memory Mode • Why have it? Why use it? • When does it become durable? • Filling the memory buffer. • Any later log record requiring greater durability. • Changing to a new log file. • Idle system write log memory buffer every 50 msecs.
WT Transactions + Logging + MongoDB • MongoDB uses least persistent sync mode (in-memory). • Most performant (by a lot). • MongoDB can generate multiple transactions at a time. • WT_SESSION::log_flush() API available. • MongoDB calls just before returning guarantee to user.
Conclusion
Conclusions • This is cool stuff • I hope you enjoyed learning about it • We take the responsibility of keeping your data seriously
How do you sleep at night? Z Z Z Z Z Z Z Z Z
Transactions and Durability: Putting the “D” in ACID Sue LoVerso - Senior Staff Engineer, Storage Team MongoDB, Inc sue@mongodb.com

More Related Content

PDF
MongoDB World 2018: Building a New Transactional Model
MongoDB
 
PPTX
MongoDB World 2018: MongoDB for High Volume Time Series Data Streams
MongoDB
 
PPT
MongoDB World 2018: From Disruption to Transformation: Document Databases, Do...
MongoDB
 
PDF
MongoDB .local Bengaluru 2019: New Encryption Capabilities in MongoDB 4.2: A ...
MongoDB
 
PDF
Engineering an Encrypted Storage Engine
MongoDB
 
PPTX
Managing Cloud Security Design and Implementation in a Ransomware World
MongoDB
 
PPTX
Securing Your Enterprise Web Apps with MongoDB Enterprise
MongoDB
 
PDF
MongoDB .local Bengaluru 2019: Using MongoDB Services in Kubernetes: Any Plat...
MongoDB
 
MongoDB World 2018: Building a New Transactional Model
MongoDB
 
MongoDB World 2018: MongoDB for High Volume Time Series Data Streams
MongoDB
 
MongoDB World 2018: From Disruption to Transformation: Document Databases, Do...
MongoDB
 
MongoDB .local Bengaluru 2019: New Encryption Capabilities in MongoDB 4.2: A ...
MongoDB
 
Engineering an Encrypted Storage Engine
MongoDB
 
Managing Cloud Security Design and Implementation in a Ransomware World
MongoDB
 
Securing Your Enterprise Web Apps with MongoDB Enterprise
MongoDB
 
MongoDB .local Bengaluru 2019: Using MongoDB Services in Kubernetes: Any Plat...
MongoDB
 

What's hot (20)

PPTX
It's a Dangerous World
MongoDB
 
PPTX
Introducing Stitch
MongoDB
 
PPTX
Webinar: Compliance and Data Protection in the Big Data Age: MongoDB Security...
MongoDB
 
PPTX
Managing Multi-Tenant SaaS Applications at Scale
MongoDB
 
PPTX
A New Transactional Model - Keith Bostic
MongoDB
 
PPTX
Webinar: Enabling Microservices with Containers, Orchestration, and MongoDB
MongoDB
 
PPTX
Securing MongoDB to Serve an AWS-Based, Multi-Tenant, Security-Fanatic SaaS A...
MongoDB
 
PDF
MongoDB .local Toronto 2019: Keep your Business Safe and Scaling Holistically...
MongoDB
 
PDF
Webinar: Schema Patterns and Your Storage Engine
MongoDB
 
PPTX
Performance Tipping Points - Hitting Hardware Bottlenecks
MongoDB
 
PDF
Containerizing MongoDB with kubernetes
Brian McNamara
 
PPTX
Directory Write Leases in MagFS
Maginatics
 
PPTX
Cloud Backup Overview
MongoDB
 
PDF
Maginatics Cloud Storage Platform - MCSP 3.0 Technical Highlights
Maginatics
 
PDF
Maginatics @ SDC 2013: Architecting An Enterprise Storage Platform Using Obje...
Maginatics
 
PPTX
Webinar: Choosing the Right Shard Key for High Performance and Scale
MongoDB
 
PPTX
Meetup Microservices Commandments
Bill Zajac
 
PPTX
KubeCon EU 2019 "Securing Cloud Native Communication: From End User to Service"
Daniel Bryant
 
PPTX
Sizing MongoDB Clusters
MongoDB
 
DOCX
Secure auditing and deduplicating data in cloud
Pvrtechnologies Nellore
 
It's a Dangerous World
MongoDB
 
Introducing Stitch
MongoDB
 
Webinar: Compliance and Data Protection in the Big Data Age: MongoDB Security...
MongoDB
 
Managing Multi-Tenant SaaS Applications at Scale
MongoDB
 
A New Transactional Model - Keith Bostic
MongoDB
 
Webinar: Enabling Microservices with Containers, Orchestration, and MongoDB
MongoDB
 
Securing MongoDB to Serve an AWS-Based, Multi-Tenant, Security-Fanatic SaaS A...
MongoDB
 
MongoDB .local Toronto 2019: Keep your Business Safe and Scaling Holistically...
MongoDB
 
Webinar: Schema Patterns and Your Storage Engine
MongoDB
 
Performance Tipping Points - Hitting Hardware Bottlenecks
MongoDB
 
Containerizing MongoDB with kubernetes
Brian McNamara
 
Directory Write Leases in MagFS
Maginatics
 
Cloud Backup Overview
MongoDB
 
Maginatics Cloud Storage Platform - MCSP 3.0 Technical Highlights
Maginatics
 
Maginatics @ SDC 2013: Architecting An Enterprise Storage Platform Using Obje...
Maginatics
 
Webinar: Choosing the Right Shard Key for High Performance and Scale
MongoDB
 
Meetup Microservices Commandments
Bill Zajac
 
KubeCon EU 2019 "Securing Cloud Native Communication: From End User to Service"
Daniel Bryant
 
Sizing MongoDB Clusters
MongoDB
 
Secure auditing and deduplicating data in cloud
Pvrtechnologies Nellore
 
Ad

Similar to MongoDB World 2018: Transactions and Durability: Putting the “D” in ACID (20)

PPTX
Securing Your MongoDB Deployment
MongoDB
 
PPTX
Webinar: Deploying MongoDB to Production in Data Centers and the Cloud
MongoDB
 
PPTX
Production deployment
MongoDB
 
ODP
Groovy In the Cloud
Jim Driscoll
 
PPTX
Neue Features in MongoDB 3.6
MongoDB
 
PPTX
MongoDB: Comparing WiredTiger In-Memory Engine to Redis
Jason Terpko
 
PDF
MongoDB World 2019: Why NBCUniversal Migrated to MongoDB Atlas
MongoDB
 
PPTX
MongoDB.local Atlanta: Introduction to Serverless MongoDB
MongoDB
 
PPTX
Percona Live 2021 - MongoDB Security Features
Jean Da Silva
 
PDF
MongoDB SoCal 2020: Migrate Anything* to MongoDB Atlas
MongoDB
 
PPTX
Securing Your Deployment with MongoDB Enterprise
MongoDB
 
PPTX
MongoDB Days UK: Securing Your Deployment with MongoDB Enterprise
MongoDB
 
PPTX
Why NBC Universal Migrated to MongoDB Atlas
Datavail
 
PDF
MongoDB Europe 2016 - Who’s Helping Themselves To Your Data? Demystifying Mon...
MongoDB
 
PDF
Effectively Deploying MongoDB on AEM
Norberto Leite
 
PDF
Elements for an iOS Backend
Laurent Cerveau
 
PDF
Node.js for enterprise - JS Conference
Timur Shemsedinov
 
PPTX
Webinar: Securing your data - Mitigating the risks with MongoDB
MongoDB
 
PPTX
MongoDB Best Practices
Lewis Lin 🦊
 
PPTX
Webinar: Best Practices for Getting Started with MongoDB
MongoDB
 
Securing Your MongoDB Deployment
MongoDB
 
Webinar: Deploying MongoDB to Production in Data Centers and the Cloud
MongoDB
 
Production deployment
MongoDB
 
Groovy In the Cloud
Jim Driscoll
 
Neue Features in MongoDB 3.6
MongoDB
 
MongoDB: Comparing WiredTiger In-Memory Engine to Redis
Jason Terpko
 
MongoDB World 2019: Why NBCUniversal Migrated to MongoDB Atlas
MongoDB
 
MongoDB.local Atlanta: Introduction to Serverless MongoDB
MongoDB
 
Percona Live 2021 - MongoDB Security Features
Jean Da Silva
 
MongoDB SoCal 2020: Migrate Anything* to MongoDB Atlas
MongoDB
 
Securing Your Deployment with MongoDB Enterprise
MongoDB
 
MongoDB Days UK: Securing Your Deployment with MongoDB Enterprise
MongoDB
 
Why NBC Universal Migrated to MongoDB Atlas
Datavail
 
MongoDB Europe 2016 - Who’s Helping Themselves To Your Data? Demystifying Mon...
MongoDB
 
Effectively Deploying MongoDB on AEM
Norberto Leite
 
Elements for an iOS Backend
Laurent Cerveau
 
Node.js for enterprise - JS Conference
Timur Shemsedinov
 
Webinar: Securing your data - Mitigating the risks with MongoDB
MongoDB
 
MongoDB Best Practices
Lewis Lin 🦊
 
Webinar: Best Practices for Getting Started with MongoDB
MongoDB
 
Ad

More from MongoDB (20)

PDF
MongoDB SoCal 2020: Go on a Data Safari with MongoDB Charts!
MongoDB
 
PDF
MongoDB SoCal 2020: Using MongoDB Services in Kubernetes: Any Platform, Devel...
MongoDB
 
PDF
MongoDB SoCal 2020: A Complete Methodology of Data Modeling for MongoDB
MongoDB
 
PDF
MongoDB SoCal 2020: From Pharmacist to Analyst: Leveraging MongoDB for Real-T...
MongoDB
 
PDF
MongoDB SoCal 2020: Best Practices for Working with IoT and Time-series Data
MongoDB
 
PDF
MongoDB SoCal 2020: MongoDB Atlas Jump Start
MongoDB
 
PDF
MongoDB .local San Francisco 2020: Powering the new age data demands [Infosys]
MongoDB
 
PDF
MongoDB .local San Francisco 2020: Using Client Side Encryption in MongoDB 4.2
MongoDB
 
PDF
MongoDB .local San Francisco 2020: Using MongoDB Services in Kubernetes: any ...
MongoDB
 
PDF
MongoDB .local San Francisco 2020: Go on a Data Safari with MongoDB Charts!
MongoDB
 
PDF
MongoDB .local San Francisco 2020: From SQL to NoSQL -- Changing Your Mindset
MongoDB
 
PDF
MongoDB .local San Francisco 2020: MongoDB Atlas Jumpstart
MongoDB
 
PDF
MongoDB .local San Francisco 2020: Tips and Tricks++ for Querying and Indexin...
MongoDB
 
PDF
MongoDB .local San Francisco 2020: Aggregation Pipeline Power++
MongoDB
 
PDF
MongoDB .local San Francisco 2020: A Complete Methodology of Data Modeling fo...
MongoDB
 
PDF
MongoDB .local San Francisco 2020: MongoDB Atlas Data Lake Technical Deep Dive
MongoDB
 
PDF
MongoDB .local San Francisco 2020: Developing Alexa Skills with MongoDB & Golang
MongoDB
 
PDF
MongoDB .local Paris 2020: Realm : l'ingrédient secret pour de meilleures app...
MongoDB
 
PDF
MongoDB .local Paris 2020: Upply @MongoDB : Upply : Quand le Machine Learning...
MongoDB
 
PDF
MongoDB .local Paris 2020: Les bonnes pratiques pour sécuriser MongoDB
MongoDB
 
MongoDB SoCal 2020: Go on a Data Safari with MongoDB Charts!
MongoDB
 
MongoDB SoCal 2020: Using MongoDB Services in Kubernetes: Any Platform, Devel...
MongoDB
 
MongoDB SoCal 2020: A Complete Methodology of Data Modeling for MongoDB
MongoDB
 
MongoDB SoCal 2020: From Pharmacist to Analyst: Leveraging MongoDB for Real-T...
MongoDB
 
MongoDB SoCal 2020: Best Practices for Working with IoT and Time-series Data
MongoDB
 
MongoDB SoCal 2020: MongoDB Atlas Jump Start
MongoDB
 
MongoDB .local San Francisco 2020: Powering the new age data demands [Infosys]
MongoDB
 
MongoDB .local San Francisco 2020: Using Client Side Encryption in MongoDB 4.2
MongoDB
 
MongoDB .local San Francisco 2020: Using MongoDB Services in Kubernetes: any ...
MongoDB
 
MongoDB .local San Francisco 2020: Go on a Data Safari with MongoDB Charts!
MongoDB
 
MongoDB .local San Francisco 2020: From SQL to NoSQL -- Changing Your Mindset
MongoDB
 
MongoDB .local San Francisco 2020: MongoDB Atlas Jumpstart
MongoDB
 
MongoDB .local San Francisco 2020: Tips and Tricks++ for Querying and Indexin...
MongoDB
 
MongoDB .local San Francisco 2020: Aggregation Pipeline Power++
MongoDB
 
MongoDB .local San Francisco 2020: A Complete Methodology of Data Modeling fo...
MongoDB
 
MongoDB .local San Francisco 2020: MongoDB Atlas Data Lake Technical Deep Dive
MongoDB
 
MongoDB .local San Francisco 2020: Developing Alexa Skills with MongoDB & Golang
MongoDB
 
MongoDB .local Paris 2020: Realm : l'ingrédient secret pour de meilleures app...
MongoDB
 
MongoDB .local Paris 2020: Upply @MongoDB : Upply : Quand le Machine Learning...
MongoDB
 
MongoDB .local Paris 2020: Les bonnes pratiques pour sécuriser MongoDB
MongoDB
 

Recently uploaded (20)

PDF
Microsoft Solutions Partner Drive Digital Transformation with D365.pdf
Microsoft Dynamics
 
PPTX
SOPHOS-XG Firewall Administrator PPT.pptx
AgnesMunisi
 
PPTX
Chapter 5: Probability Theory and Statistics
RandyFin
 
PDF
NewMind AI Weekly Chronicles - August'25-Week II
NewMind AI
 
PPTX
Digital-Transformation-Roadmap-for-Companies.pptx
David Malick Dieng
 
PPTX
Programs and apps: productivity, graphics, security and other tools
4mqw9zch22
 
PDF
Encapsulation_ Review paper, used for researhc scholars
gurumoop
 
PPTX
Tartificialntelligence_presentation.pptx
ry7r52mzb4
 
PDF
Profit Center Accounting in SAP S/4HANA, S4F28 Col11
Libreria ERP
 
PDF
ENT215_Completing-a-large-scale-migration-and-modernization-with-AWS.pdf
ssuser28425f
 
PDF
Transform Your ITIL® 4 & ITSM Strategy with AI in 2025.pdf
PDCA Consulting
 
PPTX
1. Introduction to Computer Programming.pptx
bonakiduza1024
 
PDF
Unlocking AI with Model Context Protocol (MCP)
Brian McKeiver
 
PDF
August Patch Tuesday
Ivanti
 
PPTX
KOM of Painting work and Equipment Insulation REV00 update 25-dec.pptx
muhammadmuneebnaeem7
 
PPTX
A Presentation on Touch Screen Technology
memembruh336
 
PDF
Zenith AI: Advanced Artificial Intelligence
Biz Preneurs
 
PPTX
OMC Textile Division Presentation 2021.pptx
JahangirAlam816069
 
PDF
Enhancing emotion recognition model for a student engagement use case through...
IAESIJAI
 
PDF
DP Operators-handbook-extract for the Mautical Institute
LeonelMejiaLarios
 
Microsoft Solutions Partner Drive Digital Transformation with D365.pdf
Microsoft Dynamics
 
SOPHOS-XG Firewall Administrator PPT.pptx
AgnesMunisi
 
Chapter 5: Probability Theory and Statistics
RandyFin
 
NewMind AI Weekly Chronicles - August'25-Week II
NewMind AI
 
Digital-Transformation-Roadmap-for-Companies.pptx
David Malick Dieng
 
Programs and apps: productivity, graphics, security and other tools
4mqw9zch22
 
Encapsulation_ Review paper, used for researhc scholars
gurumoop
 
Tartificialntelligence_presentation.pptx
ry7r52mzb4
 
Profit Center Accounting in SAP S/4HANA, S4F28 Col11
Libreria ERP
 
ENT215_Completing-a-large-scale-migration-and-modernization-with-AWS.pdf
ssuser28425f
 
Transform Your ITIL® 4 & ITSM Strategy with AI in 2025.pdf
PDCA Consulting
 
1. Introduction to Computer Programming.pptx
bonakiduza1024
 
Unlocking AI with Model Context Protocol (MCP)
Brian McKeiver
 
August Patch Tuesday
Ivanti
 
KOM of Painting work and Equipment Insulation REV00 update 25-dec.pptx
muhammadmuneebnaeem7
 
A Presentation on Touch Screen Technology
memembruh336
 
Zenith AI: Advanced Artificial Intelligence
Biz Preneurs
 
OMC Textile Division Presentation 2021.pptx
JahangirAlam816069
 
Enhancing emotion recognition model for a student engagement use case through...
IAESIJAI
 
DP Operators-handbook-extract for the Mautical Institute
LeonelMejiaLarios
 

MongoDB World 2018: Transactions and Durability: Putting the “D” in ACID

  • 1. Transactions and Durability: Putting the “D” in ACID Sue LoVerso - Senior Staff Engineer, Storage Team MongoDB, Inc sue@mongodb.com
  • 2. Sue LoVerso Senior Staff Engineer, MongoDB Kernel Storage Team
  • 4. ACID - Atomicity • “All or nothing” • Set of operations are an indivisible unit • Example: Bank transfer: • Withdraw from Account A • Deposit into Account B
  • 5. ACID - Consistency • Database constraints aren’t violated (“constraints” individually defined) • Most common in Relational Databases: constraints, triggers or cascades • Example: • [EndDate] >= [StartDate] • [Value] < 100
  • 6. ACID - Isolation • Data visibility (or not) by other concurrently running transactions • Isolation levels: what data can a transaction read or write and when • WiredTiger offers visibility choices with tradeoffs
  • 7. ACID - Durability • Provides guarantee that committed transactions survive permanently • Common implementation is write-ahead log (aka journal) • WiredTiger gives durability-related choices • This is not the replication oplog. This is per-node in a cluster • These are not user-level transactions
  • 8. ACID - Durability Modes In-memory mode WT memory
  • 9. ACID - Durability Modes In-memory mode write-no-sync mode WT memory WT memory write(2) file system buffer cache
  • 10. ACID - Durability Modes Disk In-memory mode write-no-sync mode full-sync mode WT memory write(2) file system buffer cache WT memory WT memory write(2) file system buffer cache
  • 11. ACID - Durability Durability Guarantee Performance Full Sync In-memory Write-no-Sync
  • 12. ACID - Durability Synchronization Level Process Crash System Crash in-memory (“sync=disabled”) Potential data loss Potential data loss write-no-sync (“sync=off”) Data always recoverable Potential data loss full sync (“sync=on”) Data always recoverable Data always recoverable
  • 13. Why Do We Care?
  • 14. What keeps me up at night?
  • 15. What keeps me up at night?
  • 16. What keeps me up at night? • For storage engineers - “Losing people’s data”
  • 17. How I sleep better • Durability - keep data stable and consistent
  • 18. How I sleep better • Durability - keep data stable and consistent • If we say it’s stable, it really is written and synced
  • 19. How I sleep better • Durability - keep data stable and consistent • If we say it’s stable, it really is written and synced • Crash: we can recover your durably written data
  • 20. How I sleep better • Round the clock testing 24/7 • Randomized • Kill process • Power cycle • Both WiredTiger only and via MongoDB • Any failure is top priority work (and I mean absolute, top priority)
  • 21. How I sleep better • Constant testing gives confidence in code • We think long and hard about durability guarantees • We pay close attention to OS and system call issues • We think long and hard about feature impacts on durability • We take the responsibility of keeping your data seriously
  • 23. Layers All The Way Down Content Repo IoT Sensor Backend Ad Service Customer Analytics Archive Example Future State
  • 24. Layers All The Way Down Content Repo IoT Sensor Backend Ad Service Customer Analytics Archive MongoDB Query Language (MQL) + Native Drivers Example Future State
  • 25. Layers All The Way Down Content Repo IoT Sensor Backend Ad Service Customer Analytics Archive MongoDB Query Language (MQL) + Native Drivers MongoDB Document Data Model Management Security Example Future State
  • 26. Layers All The Way Down Content Repo IoT Sensor Backend Ad Service Customer Analytics Archive MongoDB Query Language (MQL) + Native Drivers MongoDB Document Data Model MMAP V1 WiredTiger RocksDB Mobile Management Security Example Future State In-memory
  • 27. WiredTiger Architecture Database Files Log Files WiredTiger C API Schema & Cursors Transactions Row Storage Column Storage Snapshots Cache Page read/write Block Manager Logging MongoDB Storage Engine Layer
  • 28. WiredTiger Architecture Database Files Log Files WiredTiger C API Schema & Cursors Transactions Row Storage Column Storage Snapshots Cache Page read/write Block Manager Logging
  • 30. Layers of Trust - User • User wants assured stability of some data User
  • 31. Layers of Trust - User • User wants assured stability of some data • User gives write concern: { j : true } j:true turtles User
  • 32. Layers of Trust • User gives write concern: { j : true } • https://docs.mongodb.com/manual/reference/write-concern/: • Write concern describes the level of acknowledgement requested from MongoDB for write operations … • If j: true, [the user] requests acknowledgement that the mongod instances ... have written to the on-disk journal.
  • 33. Layers of Trust - MongoDB src/mongo/db/write_concern.cpp: Status waitForWriteConcern(...) { ... case WriteConcernOptions::SyncMode::JOURNAL: opCtx->recoveryUnit()->waitUntilDurable(); ... } j:true turtles User MDB
  • 34. Layers of Trust - MongoDB void WiredTigerSessionCache::waitUntilDurable(...) { ... // Use the journal when available, or a checkpoint otherwise. if (_engine->isDurable()) { invariantWTOK(_Session->log_flush(_Session, "sync=on")); ... } else { invariantWTOK(_Session->checkpoint(_Session, NULL)); ... } } j:true turtles User MDB
  • 35. Layers of Trust - MongoDB • MongoDB calls WT: _Session->log_flush(_Session, “sync=on”)
  • 36. Layers of Trust - MongoDB • MongoDB calls: _Session->log_flush(_Session, “sync=on”) • http://source.wiredtiger.com/3.0.0/struct_w_t___s_e_s_s_i_o_n.html: log_flush: • forcibly flush the log and wait for it to achieve the synchronization level specified. The on setting forces log records to be written to the storage device.
  • 37. Layers of Trust - WiredTiger int __session_log_flush(...) { ... if (WT_STRING_MATCH("on", cval.str, cval.len)) flags = WT_LOG_FSYNC; ret = __wt_log_flush(session, flags); ... } int __wt_log_flush(...) { ... if (FLAG_ISSET(WT_LOG_FSYNC)) return (__wt_log_force_sync(...)); } j:true turtles User MDB WT
  • 38. Layers of Trust - WiredTiger int __wt_log_force_sync() { ... ret = __wt_fsync(session, log_fh, true)); } int __posix_sync() { ... #ifdef … WT_SYSCALL(fdatasync(fd), ret); #else WT_SYSCALL(fsync(fd), ret); #endif ... } j:true turtles User MDB WT
  • 39. Layers of Trust - WiredTiger • WiredTiger calls: fsync(fd) or fdatasync(fd) • http://man7.org/linux/man-pages/man2/fdatasync.2.html • fsync() transfers ("flushes") all modified ... data of the file to the disk device ... so that all changed information can be retrieved even if the system crashes or is rebooted. ... The call blocks until the device reports that the transfer has completed.
  • 40. Layers of Trust - Operating System https://elixir.bootlin.com/linux/v4.17-rc4/source/ fs/sync.c: SYSCALL_DEFINE1(fsync, unsigned int, fd) { ... ret = vfs_fsync_range(...); int vfs_fsync_range(...) ... return (file->f_op->fsync(...)); fs/xfs/xfs_file.c: int xfs_file_sync(...) ... blkdev_issue_flush(...); j:true turtles User MDB WT OS
  • 41. Layers of Trust - Operating System block/blk-flush.c int blkdev_issue_flush(...) { ... bio_set_dev(...); bio->bi_opf = REQ_OP_WRITE | REQ_PREFLUSH; ret = submit_bio_wait(...); }
  • 42. Layers of Trust - Device driver • Device driver sends some kind of flush operation. • Code is device specific. • Hardware is the recipient. j:true turtles User MDB WT OS Dev
  • 43. Layers of Trust - Hardware • Device driver is trusting the hardware. • If the hardware lies, data could be lost in a crash. • May need to disable device write-caching: • sudo hdparm -i /dev/sda • /etc/hdparm.conf • #write-cache=off j:true turtles User MDB WT OS Dev HW
  • 44. Layers of Trust - Summary
  • 45. Layers of Trust - Summary • User wants assured stability of some data User
  • 46. Layers of Trust - Summary • User wants assured stability of some data • User trusts MongoDB using { j : true } User MDB
  • 47. Layers of Trust - Summary • User wants assured stability of some data • User trusts MongoDB using { j : true } • MongoDB trusts WiredTiger log_flush(“sync=on”) User MDB WT
  • 48. Layers of Trust - Summary • User wants assured stability of some data • User trusts MongoDB using { j : true } • MongoDB trusts WiredTiger log_flush(“sync=on”) • WiredTiger trusts the OS using fsync(fd) User MDB WT OS
  • 49. Layers of Trust - Summary • User wants assured stability of some data • User trusts MongoDB using { j : true } • MongoDB trusts WiredTiger log_flush(“sync=on”) • WiredTiger trusts the OS using fsync(fd) • Operating System trusts device driver User MDB WT OS Dev
  • 50. Layers of Trust - Summary • User wants assured stability of some data • User trusts MongoDB using { j : true } • MongoDB trusts WiredTiger log_flush(“sync=on”) • WiredTiger trusts the OS using fsync(fd) • Operating System trusts device driver • The device driver trusts the hardware User MDB WT OS Dev HW
  • 52. What Does Durability Mean? • Writing any data to stable storage for later retrieval • In WiredTiger: ○ Checkpoints - coarse-grained durability ○ Write-ahead logging - fine-grained durability
  • 53. WiredTiger Architecture Database Files Log Files WiredTiger C API Schema & Cursors Transactions Row Storage Column Storage Snapshots Cache Page read/write Block Manager Logging
  • 54. Checkpoints • Who: • Called via WT_SESSION::checkpoint() API (MongoDB) • What: • Writes all modified collections, all visible dirty data • When: • API call, internal thread period, on close • How: • Checkpoint opens a snapshot transaction, writes data
  • 57. Checkpoints • Insert some data Collection.wt (Disk)WT Cache (Memory) Apple
  • 58. Checkpoints • Insert some data Collection.wt (Disk)WT Cache (Memory) Apple Banana
  • 59. Checkpoints • Insert some data Collection.wt (Disk)WT Cache (Memory) Apple Banana Cherry
  • 60. Checkpoints • Call WT_SESSION::checkpoint() Collection.wt (Disk)WT Cache (Memory) Apple Banana Cherry
  • 62. Checkpoints • Insert more data Collection.wt (Disk)WT Cache (Memory) Apple Banana Cherry Orange Pineapple
  • 63. Crash
  • 64. Crashing and Recovery • Open collection from most recent checkpoint • Any data after checkpoint is lost
  • 65. Checkpoints • Restart Collection.wt (Disk)WT Cache (Memory) Apple Banana Cherry
  • 66. WiredTiger Architecture Database Files Log Files WiredTiger C API Schema & Cursors Transactions Row Storage Column Storage Snapshots Cache Page read/write Block Manager Logging
  • 67. Write-ahead log (aka journal) • Who: • Enabled/disabled when first creating the database • What: • Logical recording of all transaction modifications • When: • Every time a transaction commits
  • 68. Write-ahead log (aka journal) • Create Table:Collection Collection.wt (Disk)WT Cache (Memory) WT Log (Disk)
  • 69. Write-ahead log (aka journal) • Insert some data Collection.wt (Disk)WT Cache (Memory) WT Log (Disk) Apple Commit(Apple)
  • 70. Write-ahead log (aka journal) • Insert some data Collection.wt (Disk)WT Cache (Memory) WT Log (Disk) Apple Banana Commit(Apple) Commit(Banana)
  • 71. Write-ahead log (aka journal) • Insert some data Collection.wt (Disk)WT Cache (Memory) WT Log (Disk) Apple Banana Commit(Apple) Commit(Banana) Cherry Commit(Cherry)
  • 72. Write-ahead log (aka journal) • Insert some more data Collection.wt (Disk)WT Cache (Memory) WT Log (Disk) Apple Banana Commit(Apple) Commit(Banana) Cherry Commit(Cherry) Orange Commit(Orange)
  • 73. Write-ahead log (aka journal) • Insert some more data Collection.wt (Disk)WT Cache (Memory) WT Log (Disk) Apple Banana Commit(Apple) Commit(Banana) Cherry Commit(Cherry) Orange Commit(Orange) Pineapple Commit(Pineapple)
  • 74. Crash
  • 75. Crashing and Recovery • First table open: if it exists, most recent checkpoint taken • Recovery replays the entire applicable write-ahead log
  • 76. Write-ahead log (aka journal) • Restart and recovery Collection.wt (Disk)WT Cache (Memory) WT Log (Disk) Commit(Apple) Commit(Banana) Commit(Cherry) Commit(Orange) Commit(Pineapple)
  • 77. Write-ahead log (aka journal) • Recovery replays the operations Collection.wt (Disk)WT Cache (Memory) WT Log (Disk) Apple Banana Commit(Apple) Commit(Banana) Cherry Commit(Cherry) Orange Commit(Orange) Pineapple Commit(Pineapple)
  • 78. Write-ahead log (aka journal) • Recovery checkpoints on completion Collection.wt (Disk)WT Cache (Memory) WT Log (Disk) Apple Banana Commit(Apple) Commit(Banana) CherryCommit(Cherry) OrangeCommit(Orange) PineappleCommit(Pineapple)
  • 79. Checkpoints + Logging = • Faster Recovery • Less disk usage • Best of both worlds
  • 80. Checkpoint + Logging • Create Table:Collection Collection.wt (Disk)WT Cache (Memory) WT Log (Disk)
  • 81. Checkpoint + Logging • Insert some data Collection.wt (Disk)WT Cache (Memory) WT Log (Disk) Apple Commit(Apple)
  • 82. Checkpoint + Logging • Insert some data Collection.wt (Disk)WT Cache (Memory) WT Log (Disk) Apple Banana Commit(Apple) Commit(Banana)
  • 83. Checkpoint + Logging • Insert some data Collection.wt (Disk)WT Cache (Memory) WT Log (Disk) Apple Banana Commit(Apple) Commit(Banana) Cherry Commit(Cherry)
  • 84. Checkpoint + Logging • WT_SESSION::checkpoint() Collection.wt (Disk)WT Cache (Memory) WT Log (Disk) Apple Banana Commit(Apple) Commit(Banana) CherryCommit(Cherry) Checkpoint
  • 85. Checkpoint + Logging • Insert some more data Collection.wt (Disk)WT Cache (Memory) WT Log (Disk) Apple Banana Commit(Apple) Commit(Banana) CherryCommit(Cherry) Orange Commit(Orange) Checkpoint
  • 86. Checkpoint + Logging • Insert some more data Collection.wt (Disk)WT Cache (Memory) WT Log (Disk) Apple Banana Commit(Apple) Commit(Banana) CherryCommit(Cherry) Orange Commit(Orange) Pineapple Commit(Pineapple) Checkpoint
  • 87. Crash
  • 88. Checkpoint + Logging • Restart and Recovery Collection.wt (Disk)WT Cache (Memory) WT Log (Disk) Apple Banana Commit(Apple) Commit(Banana) CherryCommit(Cherry) Commit(Orange) Commit(Pineapple) Checkpoint
  • 89. Checkpoint + Logging • Restart and Recovery Collection.wt (Disk)WT Cache (Memory) WT Log (Disk) Apple Banana Commit(Apple) Commit(Banana) CherryCommit(Cherry) Commit(Orange) Commit(Pineapple) Checkpoint Recovery starts here
  • 90. Checkpoint + Logging • Recovery replays the operations Collection.wt (Disk)WT Cache (Memory) WT Log (Disk) Apple Banana Commit(Apple) Commit(Banana) CherryCommit(Cherry) Orange Commit(Orange) Pineapple Commit(Pineapple) Checkpoint
  • 91. Checkpoint + Logging • Recovery checkpoints on completion Collection.wt (Disk)WT Cache (Memory) WT Log (Disk) Apple Banana Commit(Apple) Commit(Banana) CherryCommit(Cherry) Orange Commit(Orange) Pineapple Commit(Pineapple) Checkpoint Checkpoint
  • 92. Checkpoints + Logging = • Faster Recovery • Checkpoints bound recovery time. Recovery starts at previous checkpoint • Less disk usage • Checkpoints allow archival of earlier write-ahead log files • Archiving happens on whole-file basis • Fine-grained durability • Logging allows recovery of intermediary data
  • 94. Transactions + Logging • Who: • WT_SESSION::commit_transaction() • WT_SESSION::checkpoint() • Internal operations • What: • Logical recording of all transaction modifications • When: • Every time a transaction commits, before making visible
  • 95. Write-Ahead Modes WT Log (Disk) Commit(Apple) Checkpoint Commit(Banana) Commit(Cherry) Commit(Orange) Commit(Pineapple) Checkpoint
  • 96. Write-Ahead Modes Diskfull-sync mode WT memory write(2) file system buffer cache WT memory WT memory write-no-sync mode in-memory mode write(2) file system buffer cache WT Log (Disk) Commit(Apple) Checkpoint Commit(Banana) Commit(Cherry) Commit(Orange) Commit(Pineapple) Checkpoint
  • 97. Write-Ahead Modes • Guarantees on return from commit transaction: • in-memory durability (default/MongoDB): none • write-no-sync: recoverable after process crash • full-sync: recoverable from process crash or system crash Synchronization Level Process Crash System Crash in-memory Potential data loss Potential data loss write-no-sync Data always recoverable Potential data loss full sync Data always recoverable Data always recoverable
  • 98. Write-ahead In-memory Mode • Why have it? Why use it? • When does it become durable?
  • 99. Write-ahead In-memory Mode • Why have it? Why use it? • When does it become durable? • Filling the memory buffer. • Any later log record requiring greater durability. • Changing to a new log file. • Idle system write log memory buffer every 50 msecs.
  • 100. WT Transactions + Logging + MongoDB • MongoDB uses least persistent sync mode (in-memory). • Most performant (by a lot). • MongoDB can generate multiple transactions at a time. • WT_SESSION::log_flush() API available. • MongoDB calls just before returning guarantee to user.
  • 102. Conclusions • This is cool stuff • I hope you enjoyed learning about it • We take the responsibility of keeping your data seriously
  • 103. How do you sleep at night? Z Z Z Z Z Z Z Z Z
  • 104. Transactions and Durability: Putting the “D” in ACID Sue LoVerso - Senior Staff Engineer, Storage Team MongoDB, Inc sue@mongodb.com