DeletionPolicy: нельзя указать моментальный снимок для экземпляра кластера, вместо этого используйте политику удаления в кластере.

Я пытаюсь создать кластер RDS и экземпляр aurora, используя шаблон облачного формирования ниже:

{
      "AWSTemplateFormatVersion" : "2010-09-09",

  "Description" : "example setup",

  "Parameters" : {
    "DBInstanceIdentifier" : {
      "Type": "String",
      "Description": "Name for the DB instance."
    },
    "DBUser" : {
      "Type": "String",
      "Description": "Master user"
    },
    "DBPassword" : {
      "Type": "String",
      "Description": "Pass"
    },
    "DBModel" : {
      "Type": "String",
      "Description": "Instance model to be used for the DB."
    }
  },


  "Resources": {
    "RDSCluster": {
      "Type": "AWS::RDS::DBCluster",
      "Properties": {
        "MasterUsername": { "Ref" : "DBUser" },
        "MasterUserPassword": { "Ref" : "DBPassword" },
        "Engine": "aurora",
        "DBClusterParameterGroupName": "default.aurora5.6",
        "VpcSecurityGroupIds": [{"Fn::GetAtt" : [ "DBFromSiteSecurityGroup" , "GroupId" ]}]
      }
    },
    "AuroraInstance": {
      "Type": "AWS::RDS::DBInstance",
      "Properties": {
        "DBInstanceIdentifier": { "Ref" : "DBInstanceIdentifier" },
        "DBParameterGroupName": "default.aurora5.6",
        "Engine": "aurora",
        "DBClusterIdentifier": {
          "Ref": "RDSCluster"
        },
        "PubliclyAccessible": "true",
        "DBInstanceClass": { "Ref" : "DBModel" }
      }
    },

    "DBFromSiteSecurityGroup" : {
       "Type" : "AWS::EC2::SecurityGroup",
       "Properties" : {
          "GroupDescription" : "Enable MySQL",
          "SecurityGroupIngress" : [
             {"IpProtocol" : "tcp", "FromPort" : "3306", "ToPort" : "3306", "CidrIp" : "195.171.102.98/32"}
          ]
       }
    },
     "DBFromSiteSecurityGroupIngress1" : {
         "Type" : "AWS::EC2::SecurityGroupIngress",
         "Properties" : {
             "GroupName" : { "Ref" : "DBFromSiteSecurityGroup" },
             "IpProtocol" : "tcp",
             "ToPort" : "3306",
             "FromPort" : "3306",
             "SourceSecurityGroupName" : { "Ref" : "DBFromSiteSecurityGroup" }
         }
     }
  }
}

Я передаю параметр db_model "db.t2.medium". Кластер успешно создается в консоли облачной информации, однако создание AWS :: RDS :: DBInstance не удается из-за следующей ошибки

"DeletionPolicy:Snapshot cannot be specified for a cluster instance, use deletion policy on the cluster instead." 

Что еще более странно, когда я пытаюсь запустить тот же шаблон CF, скажем, в лондонском регионе ЕС, он работает нормально !!! Что-то не так с регионом ЕС ирландия и полярным сиянием?


person george    schedule 15.07.2017    source источник
comment
Похоже на проблему с AWS. Я обновляю наш производственный стек CFN сегодня утром без проблем, но теперь он дает мне ту же ошибку, когда я обновляю стек - забавно то, что я даже не обновляю экземпляр Aurora DB. Оба стека находятся в Ирландии.   -  person MojoJojo    schedule 15.07.2017
comment
так как же решить проблему? Есть ли какое-нибудь средство отслеживания проблем, которое нам нужно отправить?   -  person george    schedule 15.07.2017
comment
Я столкнулся с этой же проблемой, начиная со вчерашнего дня. Похоже, что нет способа определить эту политику в кластере, поэтому я согласен с тем, что это ошибка AWS в требованиях, и я сам еще не нашел решения.   -  person hsteckylf    schedule 15.07.2017
comment
Я также упомяну, что я пытался развернуть это на us-west-2. Пока не нашли способа решить эту проблему, но отправили заявку в службу технической поддержки.   -  person hsteckylf    schedule 15.07.2017
comment
У меня то же самое, несмотря на то, что в моем стеке не указана политика удаления. Должно быть недавнее изменение   -  person e_m0ney    schedule 16.07.2017
comment
У меня также возникает эта проблема при попытке удалить стек. Процесс удаления завершается неудачно, и экземпляры остаются. Любые советы о том, как успешно удалить стек?   -  person Marc    schedule 16.07.2017
comment
В настоящее время они тестируют исправление и обновят его, когда проблема с рекомендациями службы поддержки будет решена на глобальном уровне.   -  person Brent    schedule 19.07.2017


Ответы (2)


Из службы поддержки AWS

Это известная проблема, о которой также сообщили другие клиенты. Сервисная группа в настоящее время работает над исправлением этого, но неизвестно ETA, когда это будет продвинуто.

Тем временем временным решением будет указать DeletionPolicy внутри определения ресурса экземпляра БД, который не удается создать, со значением «Удалить». [1]

Пример ниже:

"Resources": { 
    "Database1": { 
        "DeletionPolicy": "Delete", 
        "Properties": {...}, 
        "Type": "AWS::RDS::DBInstance" 
    } 
}

Ссылки: [1] DeletionPolicy - http://docs.aws.amazon.com/AWSCloudFormation/latest/UserGuide/aws-attribute-deletionpolicy.html#w2ab2c19c23c11c17

person hsteckylf    schedule 16.07.2017
comment
У меня тоже сработало! Застрял в этом на 2 дня! - person MojoJojo; 16.07.2017

Обновление от AWS Support:

При создании Amazon Aurora DBInstance в кластере БД с помощью AWS CloudFormation CloudFormation применяет политику удаления по умолчанию «Удалить», если политика удаления не указана. Если для Amazon Aurora DBInstance задана политика удаления «Снимок», CloudFormation возвращает ошибку, поскольку экземпляры в кластере БД не могут быть созданы по отдельности; Моментальные снимки должны выполняться на уровне кластера БД.

В рамках недавнего развертывания мы непреднамеренно изменили политику удаления по умолчанию для Amazon Aurora DBInstance на «Снимок». Это привело к сбою проверки нашего шаблона. Чтобы исправить это, CloudFormation возвращает значение DeletionPolicy по умолчанию для Amazon Aurora DBInstances на «Удалить». Это исправление будет завершено к 21 июля 2017 года. Пока это исправление не будет полностью развернуто, клиенты могут явно переопределить наши неправильные значения по умолчанию, указав политику удаления «Удалить» для Amazon Aurora DBInstances.

Мы исправили пробел в нашем тестировании, который привел к этой ситуации, и продолжим улучшать наше тестирование, чтобы предотвратить повторение. Мы осознаем, насколько важно для нас сохранить существующее поведение для наших клиентов, и приносим извинения за неудобства.

person MojoJojo    schedule 24.07.2017