Достижение нулевого времени простоя Развертывание затронуло ту же проблему, но мне нужен совет по стратегии, которую я рассматриваю.
контекст
Веб-приложение с Apache / PHP для обработки на стороне сервера и MySQL DB / filesystem для сохранения.
В настоящее время мы строим инфраструктуру. Все сетевое оборудование будет иметь избыточность, а все основные сетевые кабели будут использоваться в соединенных парах для обеспечения отказоустойчивости. Серверы настраиваются как пары высокой доступности для отказоустойчивости оборудования и будут сбалансированы как для отказоустойчивости виртуальной машины, так и для общей производительности.
Я намерен применять обновления к приложению без каких-либо простоев. Я очень старался, когда проектировал инфраструктуру, чтобы обеспечить 100% работоспособность; Было бы очень обидно, если бы после каждого обновления было 10-15 минут простоя. Это особенно важно, так как у нас будет очень быстрый цикл выпуска (иногда он может достигать одного или нескольких выпусков в день).
Топология сети
Это краткое изложение сети:
Load Balancer
|----------------------------|
/ / \ \
/ / \ \
| Web Server | DB Server | Web Server | DB Server |
|-------------------------|-------------------------|
| Host-1 | Host-2 | Host-1 | Host-2 |
|-------------------------|-------------------------|
Node A \ / Node B
| / |
| / \ |
|---------------------| |---------------------|
Switch 1 Switch 2
And onward to VRRP enabled routers and the internet
Примечание: серверы БД используют репликацию мастер-мастер
Предлагаемая стратегия
Чтобы достичь этого, я сейчас подумываю разбить сценарии обновления схемы БД на две части. Обновление будет выглядеть так:
- Веб-сервер на узле A отключен; трафик продолжает обрабатываться веб-сервером на узле B.
- Изменения переходной схемы применяются к серверам БД
- Веб-сервер База кода обновляется, кэши очищаются, и выполняются любые другие действия по обновлению.
- Веб-сервер A подключен к сети, а веб-сервер B отключен.
- Обновлена база кода веб-сервера B, очищены кэши и предприняты любые другие действия по обновлению.
- Веб-сервер B подключен к сети.
- Окончательные изменения схемы применяются к БД
«Переходная схема» будет разработана для создания кросс-версии совместимой БД. В основном это будет использовать представления таблиц, которые имитируют схему старой версии, а сама таблица будет изменена на новую схему. Это позволяет старой версии взаимодействовать с БД в обычном режиме. Имена таблиц будут включать номера версий схемы, чтобы не было путаницы в том, в какую таблицу писать.
«Final Schema» удалит обратную совместимость и приведёт схему в порядок.
Вопрос
Короче, будет ли это работать?
более конкретно:
Будут ли проблемы из-за возможности одновременной записи в конкретный момент изменения схемы перехода? Есть ли способ убедиться, что группа запросов, которые изменяют таблицу и создают обратно-совместимое представление, выполняются последовательно? т.е. с любыми другими запросами, хранящимися в буфере, пока изменения схемы не будут завершены, что обычно составляет всего миллисекунды.
Существуют ли более простые методы, обеспечивающие такую степень стабильности, а также позволяющие выполнять обновления без простоев? Также предпочтительно избегать «эволюционной» стратегии схемы, так как я не хочу быть привязанным к обратной совместимости схемы.
источник
Ваша стратегия здорова. Я бы только предложил рассмотреть вопрос о расширении «переходной схемы» в полный набор «таблиц транзакций».
В случае таблиц транзакций SELECT (запросы) выполняются для нормализованных таблиц, чтобы гарантировать правильность. Но все INSERT, UPDATE и DELETE базы данных всегда записываются в денормализованные таблицы транзакций.
Затем отдельный параллельный процесс применяет эти изменения (возможно, с использованием хранимых процедур) к нормализованным таблицам в соответствии с установленными бизнес-правилами и требованиями схемы.
В большинстве случаев это будет практически мгновенно. Но разделение действий позволяет системе учитывать чрезмерную активность и задержки обновления схемы.
Во время изменений схемы в базе данных (B) обновления данных в активной базе данных (A) попадают в ее таблицы транзакций и немедленно применяются к ее нормализованным таблицам.
При восстановлении базы данных (B) транзакции из (A) будут применены к ней путем записи их в таблицы транзакций (B). Как только эта часть будет выполнена, (A) может быть отключен, и изменения схемы будут применены там. (B) завершит применение транзакций из (A), одновременно обрабатывая свои текущие транзакции, которые будут стоять в очереди точно так же, как (A), и «живые» будут применяться так же, как и при возврате (A).
Строка таблицы транзакций может выглядеть примерно так ...
«Таблицы» транзакций могут фактически быть строками в отдельной базе данных NoSQL или даже последовательными файлами, в зависимости от требований к производительности. Бонус заключается в том, что кодирование приложения (в данном случае веб-сайта) становится немного проще, поскольку оно выполняет запись только в таблицы транзакций.
Идея следует тем же принципам, что и двойная бухгалтерия, и по тем же причинам.
Таблицы транзакций аналогичны бухгалтерскому «журналу». Полностью нормализованные таблицы аналогичны бухгалтерской «бухгалтерской книге», где каждая таблица чем-то напоминает бухгалтерскую «учетную запись».
В бухгалтерском учете каждая транзакция получает две записи в журнале. Один для «списанной» учетной записи, а другой для «зачисленной» учетной записи.
В РСУБД «журнал» (таблица транзакций) получает запись для каждой нормализованной таблицы, которая будет изменена этой транзакцией.
Столбец БД на приведенной выше иллюстрации таблицы указывает, в какой базе данных произошла транзакция, что позволяет отфильтровывать строки в очереди из другой базы данных и не применять их повторно при восстановлении второй базы данных.
источник