У нас есть Java-приложение, интенсивно использующее базы данных. Мы используем БД SQL Server 2008.
Мы думаем о переводе нашего Java-приложения в кластер с балансировкой нагрузки на 2-3 узла. У нас есть частые дополнения к функциям приложений / исправления ошибок (и, следовательно, новые выпуски). Всякий раз, когда какое-либо изменение базы данных не связано с выпуском, мы, вероятно, могли бы обновить приложение Java, беря по одному узлу из кластера для обслуживания и развертывая на нем более новое приложение.
Однако иногда мы выпускаем релизы, которые предполагают обновление БД. (Мы запускаем сценарии и хранимые процедуры, которые добавляют, удаляют или обновляют данные в БД.) На эти операции иногда требуется около часа. Есть ли способ как-то справиться с этим, чтобы нам не приходилось отключать приложение в течение этого периода обновления БД?
Может ли в этой ситуации помочь любой тип / конфигурация кластеризации? Возможно ли какое-либо решение, где у нас есть БД на 2 серверах (с зеркалированием или что-то в этом роде), и мы переводим один сервер в автономный режим для нашего процесса обновления, и когда обновление завершено, мы возвращаем сервер в оперативный режим, и он обновляется с изменениями что произошло после того, как он был отключен с другого сервера?
Я новичок в кластеризации (и тем более в кластеризации SQL). Так что извините, если приведенный выше абзац вас развлекает или звучит неловко.
Спасибо за ответы.
Короче говоря, вы не можете запустить базу данных SQL Server на двух серверах и разделить их мозг при выполнении обновлений. Если бы вы это сделали, у SQL Server не было бы возможности восстановить синхронизацию двух систем. После того, как вы разделите их, вы можете изменить одну и ту же строку с обеих сторон или изменить схему и т.д., что сделало бы невозможным собрать все вместе.
Выполняя обновления, отключите питание. Поместите флаг в свой файл конфигурации, чтобы вы могли быстро и легко отключить сайт во время внесения изменений в базу данных. Или напишите приложение и изменения таким образом, чтобы изменения не приводили к остановке сайта, позволяя сайту продолжать работать, пока вносятся изменения, а затем поместите новый сайт поверх изменений.
Если все сделано правильно, большинство изменений в базе данных можно будет внести без отключения пользовательского интерфейса.
Настоящий вопрос заключается в том, нужна ли вам возможность записи в базу данных из вашего приложения во время выполнения обновлений? Если вы можете иметь дело только для чтения, вы можете сделать снимок базы данных, запустить приложение в режиме только для чтения вне снимка, применить обновления к фактической базе данных, а затем переключить приложение на использование реальной базы данных, когда все будет законченный.
Я думаю, что здесь есть фундаментальная проблема с «кластеризацией», потому что то, о чем вы говорите, на самом деле не кластеризация, вы действительно говорите о чем-то, что больше похоже на репликацию транзакций (чтобы иметь возможность получить «балансировку нагрузки»). говорим о). При кластеризации у вас есть только один активный узел, если только у вас нет нескольких экземпляров SQL в одном кластере, но это потребует перепрограммирования вашего приложения для обработки отдельных экземпляров, и на самом деле это не приведет к тому, что вы хотите.
Упоминание TomTom об атомарности является реальной проблемой, когда речь идет о том виде управления изменениями, о котором вы говорите. Если вы сохраните один из экземпляров в режиме с возможностью записи при обновлении других, у вас могут быть несогласованные данные между экземплярами, когда они все обновлены, поскольку ваши сценарии изменяют код на пути к новому выпуску.
Вы нам скажите. Можете ли вы справиться с приложением, обновляющим базу данных на одном сервере, в то время как другой обновляется? Вы столкнетесь с серьезной проблемой, если просто потеряете много гарантированного поведения SQL (атомарность). Это можно решить ТОЛЬКО с помощью программирования, а не с помощью автоматизированных технологий.
Итак, вы не можете спросить, хороша ли кластеризация (подсказка: это не так). если вы запускаете несколько копий базы данных и снимаете одну, как вы обрабатываете промежуточные обновления и повторно синхронизируете их?