@@ -1347,44 +1347,77 @@ Administration
1347
1347
1348
1348
.. dbcommand:: fsync
1349
1349
1350
- :dbcommand:`fsync` is an *administrative command* that forces the
1351
- :program:`mongod` process to flush all pending writes to the data
1352
- files. :program:`mongod` is always writing data to disk, and
1353
- guarantees that it will write all data to disk within the
1354
- :setting:`syncdelay` interval, which is 60 seconds by default. You
1355
- do not need to run :dbcommand:`fsync` in the course of normal
1356
- operations. The primary use of :dbcommand:`fsync` is to flush and
1357
- lock the database for backups.
1350
+ The :dbcommand:`fsync` command forces the :program:`mongod` process
1351
+ to flush all pending writes to the storage layer. :program:`mongod`
1352
+ is always writing data to the storage layer within the
1353
+ :setting:`syncdelay` interval, which is 60 seconds by default.
1358
1354
1359
- The :dbcommand:`fsync` operation blocks all other write operations
1360
- for a while it runs. To toggle a write-lock using
1361
- :dbcommand:`fsync`, add a lock argument, as follows:
1355
+ .. code-block:: javascript
1356
+
1357
+ { fsync: 1 }
1358
+
1359
+ The :dbcommand:`fsync` operation is synchronous by default, to run
1360
+ :dbcommand:`fsync` asynchronously, the command is:
1361
+
1362
+ .. code-block:: javascript
1363
+
1364
+ { fsync: 1, async: true }
1365
+
1366
+ Database backups can be performed using :dbcommand:`fsync` with the
1367
+ ``lock`` operator, know as fsync lock. This will flush all data to
1368
+ the data storage layer and block all write operations until the
1369
+ database is unlocked. To set fsync lock for a database, use the
1370
+ following command:
1362
1371
1363
1372
.. code-block:: javascript
1364
1373
1365
1374
{ fsync: 1, lock: true }
1366
1375
1367
- This will sync the data files and lock the database against writes. Later,
1368
- you must run the following query to unlock the database:
1376
+ .. note::
1377
+
1378
+ Read operations are allowed on a database that is fsync locked
1379
+ until the next write operation, which will cause read operations
1380
+ to be blocked. The database will then be locked until it is
1381
+ unlocked.
1382
+
1383
+ To check on the current state of the fsync lock, use
1384
+ :func:`db.currentOp()`.
1385
+
1386
+ To unlock the database, make a request for an unlock using the
1387
+ following command:
1369
1388
1370
1389
.. code-block:: javascript
1371
1390
1372
1391
db.getSiblingDB("admin").$cmd.sys.unlock.findOne();
1373
1392
1374
- In the shell, you may use the following helpers to simplify
1375
- the process:
1393
+ .. versionadded:: 1.9.0
1394
+ The :func:`db.fsyncLock()` and :func:`db.fsyncUnlock()`
1395
+ helpers in the shell.
1396
+
1397
+ In the shell, you may use the following shell helpers to simplify the
1398
+ :dbcommand:`fsync` lock and unlock process:
1376
1399
1377
1400
.. code-block:: javascript
1378
1401
1379
1402
db.fsyncLock();
1380
1403
db.fsyncUnlock();
1381
1404
1382
- .. versionadded:: 1.9.0
1383
- The :func:`db.fsyncLock()` and :func:`db.fsyncUnlock()`
1384
- helpers in the shell.
1405
+ .. note::
1406
+
1407
+ :dbcommand:`fsync` lock is only possible on individual shards of
1408
+ a shard cluster, not on the entire shard cluster. To backup an
1409
+ entire shard cluster, please read: :ref:`Shard cluster
1410
+ considerations for backups
1411
+ <backups-with-sharding-and-replication>`
1412
+
1413
+ .. note::
1414
+
1415
+ With :term:`journaling <journal>` enabled, there are :ref:`other
1416
+ methods<backup-with-journaling>` to create a backup.
1385
1417
1386
1418
.. include:: /includes/note-disable-profiling-fsynclock.rst
1387
1419
1420
+
1388
1421
.. dbcommand:: dropDatabase
1389
1422
1390
1423
The :dbcommand:`dropDatabase` command drops a database, deleting
0 commit comments