Одна из наших команд разрабатывает базу данных, которая будет довольно большой (~500 ГБ) и будет расти оттуда (я знаю, что 500 ГБ могут показаться маленькими для многих из вас, но это будет одна из самых больших баз данных в нашем магазине). Одна из проблем, с которой они борются, — это резервное копирование и восстановление базы данных. По сути, база данных будет иметь несколько таблиц «данных» и одну таблицу, используемую для хранения изображений/документов. Нам нужно выполнить следующее:
- Иметь возможность быстро создавать резервные копии и восстанавливать только таблицы данных (без изображений) на нашем тестовом сервере для целей отладки и тестирования.
- В случае катастрофического сбоя базы данных восстановите только таблицы данных, чтобы как можно скорее запустить большую часть приложения. Затем восстановите таблицу изображений, когда это возможно.
- Резервное копирование базы данных в течение выделенного ночного временного окна (несколько часов). У меня есть вопросы:
Можно ли достичь первых двух целей, сохраняя изображения в той же базе данных? Если да, то будем ли мы использовать filegroups, filestream или что-то еще? Как другие магазины делают резервные копии своих баз данных в разумные сроки, сохраняя при этом высокую доступность? Вы делаете репликацию на второй сервер и делаете резервную копию оттуда?
решение1
Все очень просто: НЕ ПЛАНИРУЙТЕ ВОССТАНОВЛЕНИЕ.
В случае катастрофического сбоя базы данных восстановите только таблицы данных, чтобы как можно скорее восстановить работу большей части приложения.
Серьёзно? Ваше определение катастрофы не совпадает с моим и остальным миром.
В случае датастрофии вы хотите восстановиться как можно скорее, но это может потребовать перестройки центра обработки данных из-за пожара. ЭТО катастрофа.
При сбоях сервера и т. п. — не планируйте использовать резервные копии. Используйте репликацию, отправку файлов журналов, чтобы второй сервер (в отдельной SAN) оставался горячим и читался, чтобы взять на себя управление в течение определенного короткого tmieframe. Я знаю компании, отправляющие файлы журналов каждые 10 минут.
По сути, ваш единственный шанс. Поднимите катастрофу до уровня РЕАЛЬНОЙ катастрофы, а не рейда/сан-провала. Что-то, где ваш вопрос не «как быстро я смогу восстановиться», а «как быстро я получу новое оборудование».
Восстановление для разработки и т. д. менее критично по времени.