Application Engineering Flashcards
What are the components of a database server?
- CPU
- Memory - inserts and updates are written here first
- Persistent Disk
- Journal - log of every database process
Database writes to memory first and then writes to journal and disk. There is a lag between the write to memory and the write to disk.
How could the data be lossed when updating and inserting even though Mongo returns a message saying insert/update success?
The server can crash after the data is written to memory but before it is written to disk. It’s up to the developers to configure Mongo for waiting for a persistance to disk before receiving a successful save message.
What is the default write concern for MongoDB?
w=1 j = false –> Save occurs for a write to the memory in the database and there’s no wait for the journal to sync
How do you set a wait for the write to disk in Mongo?
w = 1 j = true –> This waits for the write to disk when saving which is much slower than w=1 j = false option, but less risky.
Provided you assume that the disk is persistent, what are the w and j settings required to guarantee that an insert or update has been written all the way to disk?
w=1, j=1
What typically happens when you don’t receive a affirmative response?
Network error; this can also give a false positive
What are the reasons why an application may receive an error back even if the write was successful?
Network connection between the server and application and the server was reset after the write was received but before the message was sent
Mongodb can also terminate between receiving the response and writing it to disk
Mongodb can fail between the time of the write and the time the application receives a response.
Inserts instead of updates is the only way to prevent this
How do we get availability and fault tolerance in MongoDB?
Using replication across multiple Mongo instances. Data written to a primary node will asynchronously be replicated to the secondary nodes
What is the minimum original number of nodes needed to assure the election of a new Primary if a node goes down?
3 –> You need two other secondaries when a primary goes down for an election. When the primary goes down, the a new primary is elected and the data is written there. The old primary returns as a secondary.
What are the different types of replica set nodes?
- Regular - has data; can be primary or secondary
- Arbiter - only there for voting purposes in elections
- Delayed/Regular - disaster recovery node (can’t participate in voting - p = 0)
- Hidden - can’t be a primary but can participate in elections
Which types of nodes can participate in elections of a new primary?
Regular
Hidden
Arbitors
Explain Write Consistency
- Writes go to the only primary but reads don’t have to go to the primary
- ## If reads go some where else, you may read stale data
During the time when failover is occurring, can writes successfully complete?
No
What is the oplog?
It is a capped collection on a mongo instance (you can find it using ‘show collections’) that follows the activity of the primary. The activity of the primary is recorded on the primary’s oplog and then these are copied by the secondaries asynchronously
- doesn’t matter which driver you use with these - version doesn’t matter or driver doesn’t matter (WiredTiger)
What does rs.slaveOk() do?
It allows a secondary instance to be queried on; by default they can’t