Unbinding in ExistingDatabaseInFailoverGroup plan fails for an earlier deletion of the corresponding SecondaryDatabaseWithFailoverGroup plan instance. Because it fails to delete the user created in binding as the database is no longer existed on Azure.
Normally, an ExistingDatabaseInFailoverGroup instance should be deleted before the SecondaryDatabaseWithFailoverGroup instance. But the mechanism is design for multiple CF clusters scenario. We can't ensure that order inside a broker.
Possible solution: with ExistingDatabaseInFailoverGroup plan, unbinding can give up deleting the user if the database on Azure is no longer existed and return success.
Unbinding in
ExistingDatabaseInFailoverGroup
plan fails for an earlier deletion of the correspondingSecondaryDatabaseWithFailoverGroup
plan instance. Because it fails to delete the user created in binding as the database is no longer existed on Azure. Normally, anExistingDatabaseInFailoverGroup
instance should be deleted before theSecondaryDatabaseWithFailoverGroup
instance. But the mechanism is design for multiple CF clusters scenario. We can't ensure that order inside a broker. Possible solution: withExistingDatabaseInFailoverGroup
plan, unbinding can give up deleting the user if the database on Azure is no longer existed and return success.