mongodb - 具有AWS云形成和自动扩展功能的Mongodb集群

Question

我一直在研究在AWS中创建自己的mongodb集群。 Aws mongodb template提供了一些很好的起点。但是，它不涉及自动缩放或节点发生故障时。例如，如果我有1个主节点和2个辅助节点。然后主数据库关闭，自动伸缩开始。如何将新启动的mongodb实例添加到副本集？

如果查看模板，它将使用init.sh脚本来检查正在启动的节点是否是主节点，并等待所有其他节点存在，并在主节点上创建具有其ip地址的副本集。当副本集配置为initailly时，所有节点已经存在。

不仅如此，我的节点应用程序还使用猫鼬。数据库连接的一部分允许您指定多个节点。我将如何跟踪当前正在运行的内容（我想我可以使用DynamoDB，但不确定）。

如果实例发生故障，通常的流程是什么？如果发生这种情况，人们通常会手动重新配置集群吗？

有什么想法吗？谢谢。

Answer 1

这是一个很好的问题，最近我本人经历了这一非常痛苦的旅程。我在这里写一个相当广泛的答案，希望通过CloudFormation运行MongoDB集群的一些想法对其他人有用。

我假设您正在按以下方式创建MongoDB生产集群：-


3个配置服务器（微型/小型实例可以在这里工作）
至少1个由例如2个（主要和辅助）分片实例（最小或大型），其中大型磁盘配置为数据/日志/日志磁盘。
仲裁机进行表决（微机可能还可以）。


即https://docs.mongodb.org/manual/core/sharded-cluster-architectures-production/

像您自己一样，我最初尝试了您在链接（https://s3.amazonaws.com/quickstart-reference/mongodb/latest/templates/MongoDB-VPC.template）中发布的AWS MongoDB CloudFormation模板，但是老实说，它太过复杂了，即长达9,300行，并设置了多个服务器（例如，副本分片，配置，仲裁人等）。运行CloudFormation模板需要花费很长时间，并且一直失败（例如15分钟后），这意味着服务器全部再次终止，我不得不再次尝试，这确实令人沮丧/耗时。

我最终寻求的解决方案（我非常满意）是为集群中每种类型的MongoDB服务器创建单独的模板，例如


MongoDbConfigServer.template（用于创建配置服务器的模板-运行3次）
MongoDbShardedReplicaServer.template（创建副本的模板-每个分片运行2次）
MongoDbArbiterServer.template（创建仲裁器的模板-每个分片运行一次）


注意：https://github.com/adoreboard/aws-cloudformation-templates上可用的模板

然后，想法是分别启动群集中的每个服务器，即3个配置服务器，2个分片副本服务器（用于1个分片）和arbitor。然后，您可以将自定义参数添加到每个模板中，例如副本服务器的参数可以包括：-


InstanceType例如t2.micro
ReplicaSetName例如s1r（分片1副本）
ReplicaSetNumber例如2（与ReplicaSetName一起使用来创建名称，例如，名称变为s1r2）
VpcId例如vpc-e4ad2b25（显然不是真正的VPC！）
SubnetId例如subnet-2d39a157（显然不是真正的子网！）
GroupId（现有MongoDB组ID的名称）
Route53（布尔值，将记录添加到内部DNS-最佳做法）
Route53HostedZone（如果布尔值为true，则使用Route53内部DNS的ID）


CloudFormation的真正酷处在于，这些自定义参数可以具有（a）对运行它的人员的有用描述，（b）特殊类型（例如，在运行时创建预过滤的组合框，因此更容易出错）和（c）默认值。举个例子：-

    "Route53HostedZone": {
        "Description": "Route 53 hosted zone for updating internal DNS (Only applicable if the parameter [ UpdateRoute53 ] = \"true\"",
        "Type": "AWS::Route53::HostedZone::Id",
        "Default": "YA3VWJWIX3FDC"
    },

这使CloudFormation模板的运行变得轻而易举，因为很多时候我们可以依靠默认值，并且仅根据要创建（或替换）的服务器实例进行一些调整。

除参数外，前面提到的3个模板中的每一个都有一个 "Resources"部分，用于创建实例。我们也可以通过 "AWS::CloudFormation::Init"部分来完成一些很酷的事情。例如

"Resources": {

    "MongoDbConfigServer": {
        "Type": "AWS::EC2::Instance",
        "Metadata": {
            "AWS::CloudFormation::Init": {
                "configSets" : {
                    "Install" : [ "Metric-Uploading-Config", "Install-MongoDB", "Update-Route53" ]
                },

上一个示例中的 "configSets"显示创建MongoDB服务器不仅仅是创建一个AWS实例并在其上安装MongoDB的问题，而且我们还可以（a）安装CloudWatch磁盘/内存指标（b）更新Route53 DNS等这个想法是您要尽可能自动化DNS / Monitoring等操作。

IMO为每个服务器创建一个模板，并因此创建一个堆栈，这具有非常好的优势，即可以通过CloudFormation Web控制台非常快速地替换服务器。另外，由于我们有每个模板的服务器，因此很容易一点一点地构建MongoDB集群。

关于创建模板的最后建议是从其他GitHub MongoDB CloudFormation模板中复制适用于您的内容，例如我使用以下内容创建了副本服务器以使用RAID10（而不是昂贵得多的AWS预置IOPS磁盘）。

https://github.com/CaptainCodeman/mongo-aws-vpc/blob/master/src/templates/mongo-master.template

在您的问题中，您提到了自动扩展-我的首选是手动添加分片/替换损坏的实例（自动扩展在Web容器（例如Tomcat / Apache）中是有意义的，但MongoDB集群随着时间的推移应该会缓慢增长）。但是，监视非常重要，特别是分片服务器上的磁盘大小可在磁盘已满时提醒您（因此，您可以添加新的分片以删除数据）。使用AWS CloudWatch指标/警报或使用MongoDB MMS服务可以相当轻松地实现监控。

如果某个节点发生故障（例如某个分片中的一个副本），那么您可以简单地杀死服务器，然后使用CloudFormation模板重新创建它，磁盘将自动同步。如果实例发生故障并且通常不需要重新配置，这就是我的正常流程。过去，我在修复服务器上浪费了太多时间-有时很幸运，有时却没有。现在，我的备份策略是每天通过 mongodump， crontab运行一次 zip数据库的重要集合，然后上传到AWS S3。这意味着如果发生核选项（数据库完全损坏），我们可以在一小时或2个小时内重新创建整个数据库并 mongorestore。

但是，如果您创建新的碎片（因为空间不足），则必须进行配置。例如，如果要添加新的碎片3，则将创建2个副本节点（例如，主节点的名称=> mongo-s3r1 /辅助节点的名称=> mongo-s3r2）和1个树桩（例如名称 mongo-s3r-arb），则您通过MongoDB外壳连接到 mongos（MongoDB路由器）并运行以下命令：-

sh.addShard("s3r/mongo-s3r1.internal.mycompany.com:27017,mongo-s3r2.internal.mycompany.com:27017")

注意：-此命令假定您正在通过Route53使用私有DNS（最佳做法）。您可以在 addShard命令中简单地使用2个副本的私有IP，但是过去我对此非常厌倦（例如，服务器时代过去，所有AWS实例都重新启动，并为所有实例生成了新的私有IP。修复MongoDB集群花了我2天的时间，因为我不得不手动重新配置所有内容-而在Route53中更改IP则需要几秒钟... ;-)

您可能会争辩说我们还应该将 addShard命令添加到另一个CloudFormation模板，但是IMO这会增加不必要的复杂性，因为它必须知道具有MongoDB路由器（ mongos）的服务器并连接到该服务器以运行 addShard命令。因此，我仅在创建新的MongoDB分片中的实例之后运行此操作。

无论如何，那是我对此事的漫不经心的想法。最主要的是，一旦有了模板，您的生活就会变得更加轻松，并且值得付出努力！祝你好运！ :-)