Этот баннер — требование Роскомнадзора для исполнения 152 ФЗ.
«На сайте осуществляется обработка файлов cookie, необходимых для работы сайта, а также для анализа использования сайта и улучшения предоставляемых сервисов с использованием метрической программы Яндекс.Метрика. Продолжая использовать сайт, вы даёте согласие с использованием данных технологий».
Политика конфиденциальности
|
|
|
Восстановление из логов.
|
|||
|---|---|---|---|
|
#18+
Доброго дня всем! Имеется основной сервер и тестовый, на основном сервере в воск. делается онлайн бэкап и ежедневно архивируются логи. Вопрос в том можно ли вести восстановление на тестовый сервер из логов не восстанавливая каждый раз бд. Т.е. раз в неделю раскатываю бэкап, а потом подкидываю логи и накатываю. Можно ли при таком способе затирать то, что на тестовом сервере делали за день? ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 08.02.2016, 14:59 |
|
||
|
Восстановление из логов.
|
|||
|---|---|---|---|
|
#18+
Guzya, Я бы порекомендовал смотреть на возможности это делать на уровне виртуальной машины (если тестовый сервер у вас виртуальный). После сделанного снапшота (после разворачивания бэкапа + накатывания логов на заданный день) изменения на дисках накапливаются инкрементальнои (так, по крайней мере у продуктов VMWare, если не ошибаюсь). Откат к снапшоту - быстрая и недорогая операция (к моменту, когда БД ещё в rollforward pending). Затем накат логов на следующий день, создание очередного снапшота и _после_ - вывод из rollforward. Но вообще желание странное. Обычно достаточно вести "версионность" структуры базы ("помнить номер текущей ревизии"). Как от этого номера получить следующую версию структуры разработчики (те, кто за релиз менеджмент отвечает) должны знать. Сами данные держать актуальными для теста приложения не надо. Если нужны именно игры с данными, то HADR в супер-асинхронном режиме и включённом Read Only доступе. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 08.02.2016, 15:30 |
|
||
|
Восстановление из логов.
|
|||
|---|---|---|---|
|
#18+
Восстановление нужно именно для работы(экспериментов) пользователей. Т.е. народ поигрался, а на следующее утро получил чистую бд с новыми данными. В принципе, не очень большая проблема и бд+логи каждый день раскатывать. Просто интересно имеется такая возможность или нет. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 08.02.2016, 15:44 |
|
||
|
Восстановление из логов.
|
|||
|---|---|---|---|
|
#18+
Guzya, Есть такая фича как IBM DB2 Recovery Expert for LUW, входящая в DB2 Advanced Recovery Feature ( http://www-03.ibm.com/software/products/ru/db2-advanced-recovery-feature). "Оно" умеет вычитывать транзакции по логам, представлять их в удобоваримом виде и генерировать "обратные". У Марка можете поинтересоваться деталями (был интерес, обращались к IBM в лице Марка). Но это немного другое. Приведя БД в исходное состояние на начало дня, вы всё же не получите полность идентичного состояния БД как таковой. Т.е. перевести БД в состояние Roll Forward pending и донакатиться у вас не получится - это уже будет "другая" БД, пусть и с теми же данными. Вместо rollforward'а для поплуляции свежих данных с продуктива можно будет использовать репликатор. Сколько примерно пользовательских транзакций на тесте у вас за день набегает? (т.е. их тысячи/миллионы или десятки?) Насколько велики транзакции? Насколько возможны конфликты между ними? (насколько они серианизуемы?) В принципе, можно настроить SQL репликатор и самим производить откат по информации из CD таблиц. Успешность зависит от объёма. Если времени за ночь хватает для переподнятия всей БД, то не морочьтесь. Смотрите на это как на дополнительную (и необходимую) проверку корректности бэкапа. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 08.02.2016, 16:36 |
|
||
|
Восстановление из логов.
|
|||
|---|---|---|---|
|
#18+
Спасибо за развернутый ответ. Думаю буду раскатывать бд+логи. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 08.02.2016, 18:37 |
|
||
|
|

start [/forum/topic.php?fid=43&gotonew=1&tid=1600658]: |
0ms |
get settings: |
11ms |
get forum list: |
13ms |
check forum access: |
4ms |
check topic access: |
4ms |
track hit: |
66ms |
get topic data: |
11ms |
get first new msg: |
8ms |
get forum data: |
3ms |
get page messages: |
46ms |
get tp. blocked users: |
1ms |
| others: | 291ms |
| total: | 458ms |

| 0 / 0 |
