Вопрос по sql, database – Как постоянно доставлять приложения на основе SQL?

0

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

Как можно ограничить влияние этой проблемы в соответствии с принципами непрерывной доставки, когда приложение развертывается постепенно в сегментах инфраструктуры?

Есть идеи?

Мой вопрос заключается в том, как ограничить влияние ошибочного запроса, если он прошел все тестирование и проверки до того, как был произведен в производство. SyBer
Я думаю, вам будет невероятно трудно дажеdefine что делает ошибочный запрос. Там нет замены хорошей стратегии обеспечения качества и ~ 100% тестовых случаев покрытия. mellamokb
Сохраняя хорошие резервные копии. :) bhamby
Непрерывное развертывание и восстановление после ошибок - это совершенно разные понятия. Восстановление после ошибок обычно обеспечивается сочетанием полного и инкрементного резервного копирования. В некоторой степени вы можете предотвратить ошибки, наняв хороших разработчиков и администраторов баз данных и имея хорошую команду обеспечения качества. Andomar

Ваш Ответ

3   ответа
1

Ну, во-первых, вы не можете понять, просто посмотрев, что является плохим оператором SQL. Возможно, вы хотели удалить все содержимое таблицы. Поэтому физически невозможно иметь автоматический инструмент, который обнаруживает намерение.

Поэтому, чтобы защитить свою базу данных, сначала убедитесь, что вы находитесь в режиме полного восстановления (не простом) и имеете полное резервное копирование каждую ночь и резервное копирование журнала транзакций каждые 15 минут или около того. Теперь вы не можете потерять много информации, независимо от того, насколько сильно нарушается процесс. Ваш dbas должен быть обучен, чтобы иметь возможность восстановиться до определенного момента времени. Если у вас нет dbas, я предлагаю лучшее, что вы можете сделать для защиты своих данных, это нанять их. Это не подлежит обсуждению в любой нетривиальной среде баз данных, и очень рискованно не иметь обученного, опытного dbas, если ваши данные имеют решающее значение для бизнеса.

Далее вам нужно относиться к SQL как к любому другому коду, он должен находиться в исходном коде в скриптах. Если вас беспокоят случайные удаления, напишите сценарии удаления, чтобы скопировать все удаления в промежуточную таблицу и удалять содержимое промежуточной таблицы один раз в неделю или около того. Примените это соглашение в обзорах кода. Или еще лучше настроить процесс аудита, который запускается через триггеры. После проверки всех записей гораздо проще вернуть 150 случайных удалений без необходимости восстановления базы данных. Я бы никогда не подумал о том, чтобы иметь какое-либо корпоративное приложение без аудита.

Все сценарии SQL без исключения должны проверяться как и любой другой код. Все SQL-скрипты должны быть протестированы на QA и переданы перед переносом на перенос. Это значительно уменьшит вероятность ошибки. Ни один разработчик не должен иметь права на запись для производства, только dbas должен иметь это. Поэтому каждый сценарий должен быть написан так, чтобы его можно было просто запустить, а не запускать по одному куску за раз, когда вы можете случайно забыть выделить предложение where. Научите своих разработчиков правильно использовать транзакции в скриптах.

БД является MySQL от Pecona. Бэк-энд - это J2EE. SyBer
Спасибо за отличный ответ. Просто вопрос - как именно мы можем установить процесс аудита для триггеров? Есть ли инструменты для этого? SyBer
@Syber, это будет отдельная вещь для базы данных, какой бэкэнд вы подаете в суд?
1

Вы обеспокоены тем, что в базу данных поступают плохие данные Решение состоит в том, чтобы использовать полное ведение журнала всех транзакций, чтобы вы могли отказаться от транзакций, которые вы хотите. Это обычно используется в контексте полного резервного копирования / инкрементного резервного копирования / полного ведения журнала.

Например, SQL Server позволяет восстанавливать данные на определенный момент времени (http://msdn.microsoft.com/en-us/library/ms190982(v=sql.105).aspx), предполагая, что у вас есть полная регистрация.

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

Вы можете обнаружить, что полное журналирование слишком дорого для такого приложения. В этом случае вы можете периодически создавать резервные копии (ежедневно, ежечасно) и просто хранить их. Для этой цели я обнаружил, что LightSpeed является хорошим продуктом для быстрого и эффективного резервного копирования.

0

Одна из общепринятых стратегий состоит в том, чтобы регистрировать инкрементные операторы sql, а не генерацию коллективной схемы, чтобы вы могли контролировать изменения на гораздо более детальных уровнях:

ex: 
change 1:
UP:
Add column
DOWN:
Remove column

change 2:
UP:
Add trigger
DOWN:
Remove trigger

После постепенного изменения изменений вы можете получить простой, но эффективный скрипт для обновления (UP) с любой версии до любой версии, не беспокоясь о происходящих изменениях. Когда изменение # связано со сборкой, оно становится еще более эффективным. При развертывании сборки база данных также автоматически обновляется (UP) или понижается (DOWN) до этой конкретной сборки.

У нас есть конвейерное приложение, которое делает это в CloudMunch.

Похожие вопросы