Dave Broome Ответов: 1

Ищете стратегии перемещения базы данных приложений

Сценарий:
У нас есть несколько серверов баз данных с несколькими базами данных на каждом.
У меня есть более 50 приложений (настольных и веб -), которые используют одну или несколько таких баз данных с одного или нескольких серверов.
Существуют различные способы доступа приложений к базам данных (типизированный набор данных, жестко закодированная строка подключения и т. д.).
Итак, теперь срок службы сервера SvrDb1 подходит к концу, поэтому создается сервер SvrDb5.
Некоторые базы данных на SvrDb1 будут перемещены на SvrDb5, но некоторые могут переместиться на другой существующий сервер баз данных. Мы не можем отключить SvrDb1, пока все базы данных не будут перемещены из него, поэтому сохранение одного и того же имени сервера исключено.
В настоящее время я сталкиваюсь с изменением строк подключения в каждой программе при перемещении связанной базы данных и, возможно, несколько раз для программы, использующей несколько баз данных.
Мне просто интересно, как другие избежали этой ситуации.

Что я уже пробовал:

Моя текущая мысль заключается в том, чтобы:
Создайте псевдоним в DNS для SvrDb5 под названием AliasDb
Создайте базу данных & таблицу на SvrDb5/AliasDb, чтобы хранить запись для текущего местоположения (или строки подключения, или ??) для каждой из баз данных.
Например, запись может содержать: база данных:клиенты, местоположение:SvrDb1
Затем в каждом приложении я изменяю его, чтобы посмотреть таблицу базы данных на AliasDb, получить текущее местоположение базы данных, требуемой программой, соответствующим образом изменить строку подключения во время выполнения.
В будущем, когда SvrDb5 достигнет конца срока службы, я перемещаю базу данных местоположений на новый сервер и изменяю DNS-запись AliasDb, чтобы она указывала на новый сервер.
Когда база данных приложения перемещается на новый сервер, я изменяю только запись для этой базы данных в таблице базы данных местоположений, чтобы отразить новый сервер, и все программы, использующие эту базу данных приложения, немедленно начнут использовать новый сервер в своих строках подключения.

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

Кто-нибудь использует гораздо лучшие/более простые стратегии, которыми они хотели бы поделиться?

1 Ответов

Рейтинг:
8

Dave Kreskowiak

Что я сделал, так это создал псевдоним в DNS. Псевдоним указывает на IP-адрес сервера базы данных.

Строки подключения в приложении указывают на имя сервера базы данных псевдонимов, а не на фактическое имя сервера или его IP-адрес.

Теперь, когда приходит время переключать серверы баз данных, вы просто изменяете псевдоним, чтобы указать на новый сервер. Нет необходимости менять строки подключения в любом месте.

Dave Broome

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

Dave Kreskowiak

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

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

Итак, ответ на этот вопрос заключается в создании псевдонима для каждой базы данных. В этом нет никакого смысла, не так ли?

Конечно, это так. Псевдоним (запись DNS CNAME) указывает на другую запись DNS A. Что запись преобразует имя хоста в IP-адрес. Ничто не говорит о том, что у вас не может быть более одной записи CNAME, указывающей на одну и ту же запись A.

Таким образом, если у вас есть несколько баз данных на нескольких серверах, называемых OLDSQLSERVER и NEWSQLSERVER, вы можете создать несколько записей CNAME базы данных, которые все указывают на один и тот же SQL server:

RecordType    HostName          Target
    A         OLDSQLSERVER      192.168.0.1
    A         NEWSQLSERVER      192.168.0.2
  CNAME       MyDatabase1       OLDSQLSERVER
  CNAME       MyDatabase2       OLDSQLSERVER
  CNAME       MyDatabase3       NEWSQLSERVER
  CNAME       MyDatabase4       NEWSQLSERVER

Когда вы перемещаете базу данных из OLDSQLSERVER в NEWSQLSERVER, вы просто обновляете запись CNAME для этой базы данных, чтобы указать на запись A для сервера, на котором она размещена.

Ваши строки подключения должны быть обновлены, чтобы "войти" в эту схему. В зависимости от используемого поставщика свойство DataSource или Server будет являться записью CNAME для базы данных, а свойство Database или Initial Catalog все равно будет указывать на имя базы данных на сервере. Но после установки вам больше никогда не придется менять строку подключения.

Для хорошего погружения в это, прочитайте Порт1433: использование псевдонимов DNS для управления подключениями к базе данных[^]

Dave Broome

Именно так. Я знал, что должен быть более легкий путь, чем направление, в котором я двигался. Кроме того, Спасибо за ссылку, так как в ней была хорошая информация о TTL и именовании/группировке, которую я бы не рассматривал.