ANNOUNCEMENT: Voyage AI joins MongoDB to power more accurate and trustworthy AI applications on Atlas.
Learn more
Docs Menu

FAQ: 복제 및 복제 세트

This document answers common questions about replication in MongoDB. See also the 복제 section in the manual, which provides an overview of replication including details on:

MongoDB supports Replica sets, which can have up to 50 nodes.

Yes.

For example, a deployment may maintain a primary and secondary in an East-coast data center along with a secondary member for disaster recovery in a West-coast data center.

다음도 참조하세요.

Yes, but not without connection failures and the obvious latency.

Members of the set will attempt to reconnect to the other members of the set in response to networking flaps. This does not require administrator intervention. However, if the network connections among the nodes in the replica set are very slow, it might not be possible for the members of the node to keep up with the replication.

다음도 참조하세요.

저널링 facilitates faster crash recovery.

Journaling is particularly useful for protection against power failures, especially if your replica set resides in a single data center or power circuit.

When a replica set runs with journaling, you can safely restart mongod instances without additional intervention.

참고

Journaling requires some resource overhead for write operations. Journaling has no effect on read performance, however.

Journaling is enabled by default on all 64-bit builds of MongoDB v2.0 and greater.

Arbiters never receive the contents of a collection but do exchange the following data with the rest of the replica set:

  • Credentials used to authenticate the arbiter with the replica set. These exchanges are encrypted.

  • Replica set configuration data and voting data. This information is not encrypted. Only credential exchanges are encrypted.

If your MongoDB deployment uses TLS/SSL, then all communications between arbiters and the other members of the replica set are secure.

See the documentation for TLS/SSL에 mongodmongos 를 구성하세요. for more information. As with all MongoDB components, run arbiters on secure networks.

Yes.

Factors including: different oplog sizes, different levels of storage fragmentation, and MongoDB's data file pre-allocation can lead to some variation in storage utilization between nodes. Storage use disparities will be most pronounced when you add members at different times.

Yes, unsharded replica sets can be renamed. This procedure requires downtime.

To learn how to rename your replica set, see 자체 관리 복제본 세트 이름 바꾸기.

복제본 세트의 이름을 변경하기 전에 MongoDB deployment 전체 백업을 수행하세요.