差别
这里会显示出您选择的修订版和当前版本之间的差别。
| 两侧同时换到之前的修订记录前一修订版后一修订版 | 前一修订版 | ||
| it:database:mongodbreplication [2021-12-20 02:13] – [实际执行] goldentianya | it:database:mongodbreplication [2022-08-12 05:20] (当前版本) – [MongoDB 副本集] goldentianya | ||
|---|---|---|---|
| 行 6: | 行 6: | ||
| 单版本的数据库连接通常为 <color # | 单版本的数据库连接通常为 <color # | ||
| %%''</ | %%''</ | ||
| + | |||
| + | mongodb:// | ||
| 创建三个目录用来安装不同的MongoDB | 创建三个目录用来安装不同的MongoDB | ||
| 行 29: | 行 31: | ||
| 第一个副本还没有用户的时候可以用管理员 <color # | 第一个副本还没有用户的时候可以用管理员 <color # | ||
| - | 允许在副本集中读取数据 <color # | + | 允许在副本集中读取数据 <color # |
| ====== 实际执行 ====== | ====== 实际执行 ====== | ||
| 行 35: | 行 37: | ||
| 准备三个服务器： | 准备三个服务器： | ||
| * 主服务器：88.153.172.7: | * 主服务器：88.153.172.7: | ||
| - | * 副本集：143.47.185.127:33720 (finsever) | + | * 副本集：141.144.205.48: |
| - | * 仲裁集：217.160.61.19: | + | * 仲裁集：143.47.185.127: |
| 编辑 /etc/hosts 文件，让所有的机器互相知道。否则会一直卡住联不通 | 编辑 /etc/hosts 文件，让所有的机器互相知道。否则会一直卡住联不通 | ||
| < | < | ||
| 88.153.172.7 | 88.153.172.7 | ||
| - | 217.160.61.19 | + | 141.144.205.48 serverfin |
| 143.47.185.127 | 143.47.185.127 | ||
| </ | </ | ||
| - | 第一步：修改 / | + | 第一步：修改 |
| < | < | ||
| replication: | replication: | ||
| 行 76: | 行 78: | ||
| security: | security: | ||
| authorization: | authorization: | ||
| - | clusterAuthMode: | ||
| keyFile: / | keyFile: / | ||
| </ | </ | ||
| 行 90: | 行 91: | ||
| </ | </ | ||
| - | **注意事项** | + | :!: <color #ed1c24>注意事项</ |
| - | 当副本集的数据量比较大的时候，我们添加新的节点的时候，如果使用初始化同步的话，会给主节点造成比较大的压力。我们有以下选择： | + | * CPU还算好，但服务器的内存不能太小。至少要4G以上。否则只适合作为「仲裁」。 |
| + | * 必须要单数子集。一主两副，或者一主一副一仲裁。 | ||
| + | * security 和 replSet 可以在未接入 replication 前就开启的。 | ||
| + | * keyfile 需设成 chmod 600 ，否则无法启动 mongod 服务 | ||
| + | * 各个主机必须互相认识（设置 / | ||
| + | * 如果长时间停留在状态 <color # | ||
| - | * 暂停当前副本集中的一个次节点，然后将 次节点的数据(data)复制到要新添加的节点的数据目录。然后再将两个节点启动。(建议先测试) | + | 添加仲裁节点时要修改写策略 |
| - | + | ||
| - | 如果要复制数据文件，请确保您的副本包含local数据库的内容。 | + | |
| - | + | ||
| - | * 指定同步节点 rs.syncFrom(hostportstr)，指定同步节点为次节点，默认的是同步节点 是主节点。 | + | |
| - | + | ||
| - | 但是该设置在重新启动节点，或者同步指定的新节点的连接被关闭了，是会失效的。(建议先测试) | + | |
| - | + | ||
| - | 添加仲裁节点时要修改写策略 ((a> | + | |
| <code > | <code > | ||
| db.adminCommand({ | db.adminCommand({ | ||
| 行 111: | 行 109: | ||
| }) | }) | ||
| </ | </ | ||
| + | |||
| + | <WRAP center round tip 60%> | ||
| + | 当节点数目为奇数时，可以不需要仲裁节点。 | ||
| + | 当节点数目为偶数个时，需要部署一个仲裁节点，否则偶数个节点，当主节点挂了后，其他节点会变为只读。 | ||
| + | </ | ||
| + | |||
| + | Oracle Cloud 的1核1G内存实例作为副节点会经常宕机。原因是内存不足，一次更新就会占用掉1G的内存。因此微小实例只能用作「仲裁」角色。而仲裁角色也非常重要，否则无论副集还是主集宕机，都会导致数据库不能用。 | ||
| + | |||
| ====== 其它命令 ====== | ====== 其它命令 ====== | ||
| 行 146: | 行 152: | ||
| use admin | use admin | ||
| db.shutdownServer() | db.shutdownServer() | ||
| + | </ | ||
| + | |||
| + | 连接命令 | ||
| + | < | ||
| + | var url = format(" | ||
| + | , " | ||
| + | , " | ||
| + | , " | ||
| + | , " | ||
| </ | </ | ||
