Databases
StackOverflow2013
Postsdbo
PO
 

Note that there are some explanatory texts on larger screens.

plurals
  1. PO
    primarykey
    data
    text
    <p>Your desired replication strategy is not formally supported by MongoDB.</p> <p>A <a href="http://docs.mongodb.org/manual/replication/" rel="noreferrer">MongoDB replica set</a> consists of a single primary with asynchronous replication to one or more secondary servers in the same replica set. You cannot configure a replica set with multiple primaries or replication to a different replica set.</p> <p>However, there are a few possible approaches for your use case depending on how actively you want to keep your central server up to date and the volume of data/updates you need to manage.</p> <h3>Some general caveats:</h3> <ul> <li><p>Merging data from multiple standalone servers can create unexpected conflicts. For example, unique indexes would not know about documents created on other servers.</p></li> <li><p>Ideally the data you are consolidating will still be separated by a unique database name per origin server so you don't have strange crosstalk between disparate documents that happen to have the same namespace and <code>_id</code> shared by different origin servers.</p></li> </ul> <h2>Approach #1: use <code>mongodump</code> and <code>mongorestore</code></h2> <p>If you just need to periodically sync content to your central server, one way to do so is using <a href="http://docs.mongodb.org/manual/administration/backups/#using-binary-database-dumps-for-backups" rel="noreferrer"><code>mongodump</code> and <code>mongorestore</code></a>. You can schedule a periodic <code>mongodump</code> from each of your standalone instances and use <code>mongorestore</code> to import them into the central server.</p> <h3>Caveats:</h3> <ul> <li><p>There is a <a href="http://docs.mongodb.org/manual/reference/mongorestore/#cmdoption-mongorestore--db" rel="noreferrer"><code>--db</code> parameter</a> for <code>mongorestore</code> that allows you to restore into a different database from the original name (if needed)</p></li> <li><p><code>mongorestore</code> only performs inserts into the existing database (i.e. does <strong>not</strong> perform updates or upserts). If existing data with the same <code>_id</code> already exists on the target database, mongorestore will not replace it.</p></li> <li><p>You can use <code>mongodump</code> options such as <a href="http://docs.mongodb.org/manual/reference/mongodump/#cmdoption-mongodump--query" rel="noreferrer"><code>--query</code></a> to be more selective on data to export (for example, only select recent data rather than all)</p></li> <li><p>If you want to limit the amount of data to dump &amp; restore on each run (for example, only exporting "changed" data), you will need to work out how to handle updates and deletions on the central server.</p></li> </ul> <p>Given the caveats, the simplest use of this approach would be to do a full dump &amp; restore (i.e. using <a href="http://docs.mongodb.org/manual/reference/mongorestore/#cmdoption-mongorestore--drop" rel="noreferrer"><code>mongorestore --drop</code></a>) to ensure all changes are copied.</p> <h2>Approach #2: use a tailable cursor with the MongoDB <code>oplog</code>.</h2> <p>If you need more realtime or incremental replication, a possible approach is <a href="http://docs.mongodb.org/manual/tutorial/create-tailable-cursor/" rel="noreferrer">creating tailable cursors</a> on the MongoDB replication <a href="http://docs.mongodb.org/manual/core/replication/#replica-set-oplog-sizing" rel="noreferrer"><code>oplog</code></a>.</p> <p>This approach is basically "roll your own replication". You would have to write an application which tails the oplog on each of your MongoDB instances and looks for changes of interest to save to your central server. For example, you may only want to replicate changes for selective namespaces (databases or collections).</p> <p>A related tool that may be of interest is the experimental <a href="http://blog.mongodb.org/post/29127828146/introducing-mongo-connector" rel="noreferrer">Mongo Connector</a> from 10gen labs. This is a Python module that provides an interface for tailing the replication <code>oplog</code>.</p> <h3>Caveats:</h3> <ul> <li><p>You have to implement your own code for this, and learn/understand how to work with the <code>oplog</code> documents</p></li> <li><p>There may be an alternative product which better supports your desired replication model "out of the box".</p></li> </ul>
    singulars
    1. This table or related slice is empty.
    1. POMongoDB one way replication
      singulars
      1. PTQuestion
    1. PTAnswer
    1. This table or related slice is empty.
    1. USStennie
    plurals
    1. This table or related slice is empty.
    1. This table or related slice is empty.
    1. This table or related slice is empty.
    1. This table or related slice is empty.
    1. VO
      singulars
      1. PO
      1. This table or related slice is empty.
      1. VTUpMod
    2. VO
      singulars
      1. PO
      1. This table or related slice is empty.
      1. VTUpMod
    3. VO
      singulars
      1. PO
      1. This table or related slice is empty.
      1. VTUpMod
    1. COThanks for the info about tailable cursors, this is nearly exactly what I was looking for. Cheers!
      singulars
      1. PO
      1. USmatt
 

Querying!

 
Guidance
A row detail

Detail views are divided into sections. All the information in the data section comes from columns in the selected row. The other sections display data from other, related rows.

Related data can be related in a to-one or a to-many fashion. Captions of data related in a to-many fashion link to a list view showing a filtered view of the table.

Try moving around until you find a non-empty to-many entry and click on the label to get to one. You can move back to the root by clicking on the database name in the header.

SQuiL has stopped working due to an internal error.

If you are curious you may find further information in the browser console, which is accessible through the devtools (F12).

Reload