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