Mongodb 笔记06 副本集的组成、从应用程序连接副本集、管理

时间:2022-10-11 14:51:44

副本集的组成

1. 同步:MongoDB的复制功能是使用操作日志oplog实现的,操作日志包含了主节点的每一次写操作。oplog是主节点的local数据库中的一个固定集合。备份节点通过查询整个集合就可以知道要进行

复制的操作了。每个备份节点都维护者自己的oplog,记录每一次从主节点复制数据的操作。这样,每个成员都可以作为同步源提供给其他成员使用。

2. 将oplog中的同一个操作执行多次,与只执行一次的效果是一样的。如果单个操作会影响多个文档,那么每个受影响的文档都会对应oplog中的一条日志。例如db.remove()删除了10个文档,那就对应十条日志记录。

3. oplog是主节点的local数据库中的一个固定集合。先从数据库同步数据,然后从日志里同步以后的数据。

4. 为了避免陈旧备份节点的出现,让主节点使用比较大的operlog保存足够多的操作日志是很重要的。大的operlog会占用更多的磁盘空间,通常来说,这是一个比较好的折衷方案,因为磁盘会越来越便宜。

而且实际中使用的oplog只有一小部分,因此oplog不会占用太多RAM。

5. 心跳:为了维护最新的视图,每个成员每隔两秒就会向其他成员发送一个心跳请求。心跳请求的信息量非常小,用于检查每个成员的状态。心跳最重要的功能之一就是让主节点知道自己是否满足集合"大多数"

的条件。如果主节点不再得到"大多数"服务器的支持,它就会退位,变成备份节点。

6. 成员状态:主节点,备份节点,STARTUP(成员刚启动),STARTUP2(初始化同步过程),RECOVERING(正常,但暂不能处理读请求),ARBITER(仲裁者状态)

7. 系统出问题时会处于一下状态:DOWN(不可达),UNKNOW(),REMOVED(成员被移除时),ROLLBACK(回滚中),FATAL(错误)

8. 回滚:有些情况下,回滚可能会导致数据丢失,这些丢失的数据被保存到一个.bson文件中,可以手动恢复。

9. 某些情况下,如果要回滚的内容太多,MongoDB可能承受不了。如果要回滚的数量大于300M,或者要回滚30分钟以上的操作,回滚就会失败。对于回滚失败的节点,必须要重新同步。

从应用程序连接副本集

1. 默认情况下,驱动程序会连接到主节点,并且将所有请求都路由到主节点。应用程序可以像使用单台服务器一样进行读和写,副本集会在后台默默处理热备份。

2. 之前,我们使用getLastError命令检查写入是否成功。也可以使用这个命令确保写入操作被复制到备份节点。参数"w"会强制要求getLastError等待,一直到给定数量的成员都执行完了最后的写入操作。

    MongoDB有一个特殊的关键字可以传递给"w",就是"majority"。  db.runCommand({"getLastError":1,"w":"majority"}) 输出字段中wirttenTo表示操作被复制到了哪些服务器上。

3. db.runCommand({"getLastError":1,"w":"majority","wtimeout":1000})    设置等待超时时间。

4. 通常将"w"用于控制写入速度读。MongoDB的写入速度太快,主节点上执行完写入操作后,备份节点还来不及跟上。阻止这种行为的一种常用方式是定期调用getLastError,将"w"参数指定为大于1的值。

    这样会强制这个连接上的写操作一直等待知道复制成功。注意:这只会阻塞这个连接上的写操作,其他连接上的写操作仍然会被立即执行完成并返回。

5. 如果希望应用程序的行为更自然更健壮,应该定期调用getLastError,同时指定majority和一个合理的超时时间。如果这个命令超时了,需要找出出错原因。

6. "w"的值也可以为一个整数(N),表示当操作成复制到N-1(主节点减一)个从节点后,返回成功的结果。

7. 自定义复制保证规则:

1). 保证复制到每个数据中心的一台服务器上

2). 保证写操作被复制到可见节点的"大多数"

3). 创建其他规则。可以无限制的创建各种规则。记住,创建自定义规则的两个步骤(上面两条也使用):

a. 使用键值对设置成员的"tags"字段。

b. 基于刚刚创建的分组创建规则。

规则是一种非常强大的副本集配置方式,虽然它理解和设置起来都有些复杂。除非有非常特殊的复制要求,否则使用"w":"majority"就已经非常安全了。

8. 默认情况下,驱动程序会将所有的请求都路由到主节点。可以通过设置驱动程序的读取首选项配置其他选项。可以在读选项中设置需要将查询路由到的服务器的类型。

9. 不建议将请求发送到备份节点的原因:

1). 出于一致性考虑:备份节点有时可能因为加载问题、配置错误、网络故障等原因,备份节点可能会落后主节点几分钟,几小时,甚至几天。

2). 出于负载的考虑:这种扩展方式非常危险,很容易导致系统意外过载,一旦出现这种问题,很难恢复。导致恶性循环。

10. 何时可以从备份节点读取数据:主节点挂掉时,仍然能执行读操作,并且你并不在意读到数据是否为最新。

如果要从一个落后的备份节点读取数据,就要牺牲一致性。另一方面,如果希望写操作返回之前被复制到所有副本集成员,就要牺牲写入速度。

可以使用Secodary (只访问备份节点)和 Secondary preferred(备份节点挂了,可以访问主节点) 端选项设置,修改访问到备份节点。

11. 如果某些请求必须从主节点读取数据,那就对这些请求使用Primary选项。如果另一些读请求并不要求数据是最新的,那么可以对这些读请求使用Primary preferred选项。如果某些请求对

      低迟延的要求大过一致性要求,那么可以使用Nearest选项。

12. 可以考虑在备份节点建立一个单独索引,然后客户单直接连接到这个备份节点上。

管理

1. 以单机模式启动成员:是指要重启成员服务器,让它成为一个单击运行的服务器,而不再是一个副本集成员(这只是临时的)。

如果要对一台服务器进行维护,可以重启服务器,重启时不使用replSet选项。这样它就会成为一个单击的mongod,可以对其进行读和写。我们不希望副本集中的其他服务器联系到这台服务器,

所以可以让它监听不同的端口(这样副本集的其他成员就找不到它了)。最后,保持dbpath的值不变,因为重启后要对这台服务器的数据做一些操作。举例:mongod --port 3000 --dbpath /var/lib/db

2. 副本集配置总是以一个文档的形式保持在local.system.replSet集合中。

3. 创建副本集:首先启动所有成员服务器,然后使用rs.initiate命令将配置问答经传递给其中一个成员。

var config = { "_id":"spock", "members":[{"_id":0,"host":"server-1:27017"},{"_id":0,"host":"server-2:27017"},{"_id":0,"host":"server-3:27017"}]}

rs.initiate(config)

只需要对副本集中的一个成员调用rs.initiate就可以了。收到initiate命令的成员会自动将配置和传递给副本集中的其他成员。

4. 修改副本集成员。可以查看 创建副本集 模块

5. 创建比较大的副本集:副本集最多只能拥有12个成员,其中只有7个成员拥有投票权。这是为了减少心跳请求的网络流量和选举花费的时间。如果要创建7个以上成员副本集,只有7个成员可以拥有投票权,

需要将其他成员的投票数量设置为0:rs.add({"_id":7,"host":"server-7:27017","votes":0})。如果希望某个成员可以优先被选举为主节点,应该使用优先级。

6. 强制重新配置:如果副本集无法再达到"大多数"要求的话,那么它就无法选举出新的主节点,这是你可能会希望重新配置副本集。这种情况下,可以在备份节点上调用rs.reconfig强制重新配置副本集。在

shell中连接到一个备份节点,使用"force"选项执行rs.reconfig命令。

7. 修改成员状态:

1). 把主节点变为备份节点:rs.stepDown() 默认维持60秒,如果这期间没有新的主节点产生。这个节点可以要求重新进行选举。也可以添加参数:rs.stepDown(600)  降为主节点10分钟。

2). 阻止选举:如果需要对主节点进行一些维护,但是不希望这段时间内将其他成员选举为主节点,那么可以在备份节点上执行freeze命令,以强制他们始终处于备份节点状态:

rs.freeze(1000) 这个命令以秒为单位,表示多长时间内保持备份状态。调用rs.freeze(0) 恢复备份节点被选举的权力。

也可以在主节点上执行rs.freeze(0),这样可以将退位的主节点重新变为主节点。

3). 维护模式:当在副本集成员上执行某个非常耗时的操作时,这个成员就进入了维护模式:强制成员进入RECOVERING状态。有时,成员会自动进入维护模式,比如在成员上做压缩时。

可以通过repletMaintenanceMode命令强制一个成员进入维护模式。维护模式下的备份节点不再处理读请求。可以一次提高服务器性能,更快的从主节点复制数据。

8. 监控复制:

1). 查看日志

2). replSetGetStatus 命令,可以返回副本集中每个成员的当前信息。这个命令还有一个对对应的辅助函数:rs.status() 。可以返回成员的状态,更新时间,最后一次心跳时间等。

这份报告是由rs.status()命令的成员角度得出的:由于网络故障,这份报告可能不准确或过时。

9. 复制图谱:如果在备份节点上运行rs.status(),输出信息中会有一个名为syncingTo的*字段,用于表示当前成员正从哪个成员处复制。如果在每个成员上运行该命令,就可以弄清楚复制图谱。

副本集成员要么从主节点复制,要么从数据比它新的成员处复制。自动复制链越长,经写操作复制到所有服务器所花费的时间就越长。

可以通过replSetSyncFrom(或者辅助函数rs.syncFrom())命令修改成员的复制源来进行修改。

10. 复制循环:正常情况下不会产生,除非强制修改了复制源。

11. 禁用复制链:将allowChaing设置为false之后,所有成员都会从主节点复制数据。如果主节点变得不可用,那么各个成员就从其他备份节点复制数据。

12. 计算延迟:在备份节点上运行db.printSlaveReplicationInfo() ,可以得到当前成员的复制源,以及当前成员相对复制源落后的程度等信息。延迟并不表示需要多长时间才能更新到最新数据。也可能

是写操作比较少,造成延迟过大的幻觉。很快就会更新到最新数据。

13. 调整oplog大小:每一个可能成为主节点的服务器都应该拥有足够大的oplog,以预留足够的时间窗用于进行维护。

增加oplog大小的步骤:如果当前服务器是主节点,让它退位,以便让其他成员的数据能够尽快更新到与它一直;关闭当前服务器;将当前服务器以单机模式启动;临时将oplog中最后一条insert操作

保存到其他集合;删除当前oplog;创建一个新的oplog;将最后一条操作记录写会oplog;将当前服务器作为副本集成员重新启动。

14. 从延迟节点中恢复: 

第一种方法:关闭所有其他成员;删除其他成员数据目录中的所有数据;重启所有成员

第二种方法:关闭所有成员,包括延迟备份节点;删除其他成员的数据目录;将延迟节点的数据文件复制到其他服务器;重启所有成员

15. 创建索引

1). 如果向从节点发送创建索引的命令,主节点会正常创建索引,然后备份节点在复制"创建所有"操作时也会创建索引。这是最简单创建索引的方式,但创建索引是一个需要消耗大量资源的操作,

可能会导致成员不可用。如果所有备份节点都在同一时间开始创建索引,那么几乎所有成员都会不可用,一直到索引创建完成。

2). 只在一个成员上创建索引,以降低对应用程序的影响:

关闭一个备份节点服务器;将这个服务器以单机模式启动;在单机模式下创建索引;索引创建完成之后,将服务器作为副本集成员重新启动;对副本集中的每个备份节点重复前面的步骤。

3). 副本集从节点都创建完索引后,主节点创建索引的选择:

a. 在主节点上创建索引。在系统"空闲期"创建索引,是一个不错的选择。或者修改读取首选项,在主节点创建索引期间,将读操作发送到备份节点上。备份节点上已有索引,不会再复制索引。

b. 主节点退化为备份节点。执行上面备份节点创建索引的步骤。

4). 可以为备份节点创建与其他成员不同的索引。这种方式在做离线数据处理时会非常有用,但是,如果某个备份节点的索引与其他成员不同,那么它永远不能成为主节点:应该将它的优先级设为0

16. 在预算有限的情况下进行复制

17. 主节点如何跟踪延迟:作为其他成员同步源的成员会维护一个名为local.slaves的集合,这个集合中保存着所有正从前成员进行数据同步的成员,以及每个成员的数据新旧程度。

可以通过:db.slaves.find() 方法查看延迟。local.slaves集合实际上是内存中数据结构的"回声",所以其中的数据可能会有几秒的延迟。

网络故障可能会导致slaves中出现"_id" 相同的记录,需要登录到每台mongod,删除local.me集合,重启mongod。

"影同步" 保证复制链中的复制信息也会发送到主节点。

如果服务器地址发生了变化,可能会在本地数据库中看到异常。遇到这种情况,删除local.slaves集合即可。

mongod不会自动清理slaves集合。

18. 主从模式:有两种模式应该使用主从模式而不是副本集:需要多于11个备份节点 ,或者需要复制单个数据库。否则,除非不得已,都应该使用副本集。