![]() |
#1 |
Участник
|
Экземпляр "Минус день" в дополнение к DEV, TEST и PROD
Написал статью, как организовать "Минус день с подхватом логов".
Что это даёт?
http://yaroslavbat.blogspot.com/2014/10/blog-post.html У кого есть замечания\пожелания\дополнения ? |
|
|
За это сообщение автора поблагодарили: mazzy (2), AlGol (2), Kabardian (5). |
![]() |
#2 |
Участник
|
Не знаю даже как назвать. Замечания, что ли...
Замечание 1 FULL Backup базы данных необходимо делать регулярно вне зависимости от его дальнейшего использования. Минимум, раз в неделю. Описанная технология не может заменить создание FULL Backup. При этом Backup логов начинает "отсчет" от момента создания последнего FULL Backup. Это значит, что после выполнения FULL Backup все ранее созданные Backup логов можно смело выбрасывать. Они больше не нужны. А созданный FULL Backup необходимо будет скопировать на машину с базой "минус день". В момент создания FULL Backup описанная технология не имеет никаких преимуществ Замечание 2 Использование Backup логов предполагает, что они создаются друг за другом без разрывов. Это значит, что если в какой-то момент создание Backup-лога "сбойнуло" и был "пропущен" кусок за очередные 15 минут, то процесс восстановления из Backup станет невозможен. Точнее, восстановление остановится на "пропущенном" участке. А запустить повторное создание "пропущенного" куска - невозможно. Необходимо будет сделать полный или дифференциальный Backup базы данных. В случае сбоя создания очередного "фрагмента" Backup-лога описанная технология перестает работать.
__________________
- Может, я как-то неправильно живу?! - Отчего же? Правильно. Только зря... |
|
![]() |
#3 |
Участник
|
Владимир, спасибо за замечания. Вот мои ответы
Цитата:
Эта технология имеет иные цели: для сотрудников -- снизить количество сторно, для консультантов -- дать бОльшую оперативность решения проблем Цитата:
Сообщение от Владимир Максимов
![]() При этом Backup логов начинает "отсчет" от момента создания последнего FULL Backup. Это значит, что после выполнения FULL Backup все ранее созданные Backup логов можно смело выбрасывать. Они больше не нужны. А созданный FULL Backup необходимо будет скопировать на машину с базой "минус день".
Transaction Log'и содержат записи об изменениях. Каждое изменение имеет LSN -- Log Sequence Number. Они должны быть без промежутков. При выполнении FULL BACKUP "дырок" в LSN не образуется. Я проверил это ещё раз -- сделал в середине цикла FULL BACKUP -- база "Минус день" проигнорировала факт создания большого бэкапа и продолжила накатывать логи по цепочке. В том, что "дырок" в LSN не образуется, Вы можете убедиться выполнив запрос Код: select a.BACKUP_SET_ID, a.NAME, a.USER_NAME , FIRST_LSN, LAST_LSN, CHECKPOINT_LSN , DATABASE_BACKUP_LSN, TYPE, b.PHYSICAL_DEVICE_NAME from msdb..BACKUPSET a, msdb..BACKUPMEDIAFAMILY b where a.MEDIA_SET_ID = b.MEDIA_SET_ID Вы можете увидеть, что между зелёными клетками нет промежутка в LSN, хотя между ними был FULL BACKUP Цитата:
Сообщение от Владимир Максимов
![]() Использование Backup логов предполагает, что они создаются друг за другом без разрывов. Это значит, что если в какой-то момент создание Backup-лога "сбойнуло" и был "пропущен" кусок за очередные 15 минут, то процесс восстановления из Backup станет невозможен. Точнее, восстановление остановится на "пропущенном" участке. А запустить повторное создание "пропущенного" куска - невозможно. Необходимо будет сделать полный или дифференциальный Backup базы данных.
Механизм TLS очень похож на ARCHIVELOG в Oracle. Там та-же ситуация и такое-же решение. Обычно этого не происходит |
|
![]() |
#4 |
Талантливый разгвоздяй
|
Наверняка подразумевалось, но добавил бы что организации таких "минус один день" приложений важно и скрипты по отключению настроек интеграции с внешними системами предусмотреть (банк-клиент, ftp-сервер 3PL-оператора, кассовые сервера, EDI и т. п.).
Иначе тестирование может задеть данные приложение PROD. |
|
|
За это сообщение автора поблагодарили: S.Kuskov (2). |
![]() |
#5 |
Участник
|
Цитата:
Кстати, не подскажите, насколько описанная Вами технология требовательна к дисковому пространству? Если за единицу отсчета брать размер рабочей базы данных, то сколько дискового пространства требуется для виртуальных дисков? Ну, например, если рабочая база 2ТБ, то сколько потребуется на виртуальную машину?
__________________
- Может, я как-то неправильно живу?! - Отчего же? Правильно. Только зря... |
|
![]() |
#6 |
Участник
|
|
|
![]() |
#7 |
Участник
|
Цитата:
Сообщение от Владимир Максимов
![]() Кстати, не подскажите, насколько описанная Вами технология требовательна к дисковому пространству? Если за единицу отсчета брать размер рабочей базы данных, то сколько дискового пространства требуется для виртуальных дисков? Ну, например, если рабочая база 2ТБ, то сколько потребуется на виртуальную машину?
RAM: + 1 ГБ для внутреннего гипервизора Диски -- объём складывается из трёх компонентов: 1) Сама база 2) Transaction Logs (хранятся за 72 часа или как настроите) -- мне оценить сложно, поскольку это зависит от того, сколько операций у Вас выполняется 3) Дифференциальный диск -- я бы принял объём диффдиска в 20...25% от базового диска Таким образом, для базы в 2ТБ Вам будет комфортно, если выделить 4...5 ТБ, при этом такую большую БД ставить надо по сети, не копируя на внутреннюю машину |
|
![]() |
#8 |
Участник
|
Уважаемые коллеги !
Подскажите, сделал ли кто ни-будь себе такую базу ? Есть первопроходцы ? |
|
![]() |
#9 |
Участник
|
|
|
![]() |
#10 |
Участник
|
Здравствуйте, Ярослав!
Первая версия Hyper-V была включена в состав Windows Server 2008. Windows Server 2008 была выпущена 27 февраля 2008 года. 7 лет с этого момента наступит лишь через 2 недели. Поэтому методика, описанная в статье, не может использоваться "более 7 лет". Могу предположить, что у Вас используется экземпляр "Минус день" (он может существовать указанное Вами время). Но я задал вопрос относительно экземпляра "Минус день с подхватом логов" Ярослав, Ваш сарказм неуместен |
|
![]() |
#11 |
Участник
|
Цитата:
![]() Цитата:
Я просмотрел Вашу статью, и мне непонятно, почему "Когда размер БД приближается к сотне гигабайт, подход Backup\Restore уже не работает". Вот у нас размер БД около 500 гигабайт, и полный Backup (Restore) выполняется меньше часа. IMHO, полные Backup-ы всё равно должны быть, а ежедневное восстановление их в виде экземпляра "минус день" заодно проверяет их на корректность. |
|
![]() |
#12 |
Участник
|
Цитата:
Но это вопрос предпочтений системного администратора -- на месте виднее А мой вопрос касался следующего: автоматизация того алгоритма (МДПЛ) -- непроста, вот в голове у меня крутятся какие-то мысли, как это сделать, но я этого не реализовал. Интересовался, сделал ли кто ни-будь ? Надо ведь снаружи заслать команды внутрь виртуалки |
|
![]() |
#13 |
Участник
|
В разделе "Похожие темы" внизу форума мне показало сслыку на интересную статью, как отключать TEST от PROD
Это имеет отношение к этой статье dynamics-ax-dev: Copying a Production Environment into a Development/Test Environment |
|
![]() |
#14 |
Модератор
|
Цитата:
Сообщение от Kasper
![]() В разделе "Похожие темы" внизу форума мне показало сслыку на интересную статью, как отключать TEST от PROD
Это имеет отношение к этой статье dynamics-ax-dev: Copying a Production Environment into a Development/Test Environment - AIF забыт совсем. Запускаем скрипт, а на выходе - TEST среда смотрящая всеми исходящими портами на продуктивы внешних систем. - Пароли SMTP перебиваются некорректно - там содержимое BLOB-а с паролем зависит от имени хоста для которого генерится, так что просто его (имя хоста) поменять явно недостаточно >А мой вопрос касался следующего: автоматизация того алгоритма (МДПЛ) -- непроста, вот в голове у меня крутятся какие-то мысли, как это сделать, но я этого не реализовал Давно хотел решить подобную задачу для AX 2012 "наоборот" - сначала выгрузить все настройки специфичные для инстанса, а после восстановления БД - залить их обратно. Но руки все никак не доходят
__________________
-ТСЯ или -ТЬСЯ ? |
|
Теги |
полезное |
|
|