#amazon-s3 #amazon-dynamodb #database-backups #amazon-data-pipeline #disaster-recovery
#amazon-s3 #amazon-dynamodb #резервные копии базы данных #amazon-конвейер данных #аварийное восстановление
Вопрос:
Я планирую использовать конвейеры передачи данных в качестве инструмента резервного копирования и восстановления для нашего DynamoDB. Мы будем использовать готовые конвейеры Amazon для резервного копирования в s3, а также использовать готовый конвейер восстановления для восстановления в новую таблицу в случае сбоя.
Это также будет служить двойной цели архивирования данных по юридическим соображениям и соображениям соблюдения требований. Мы исследовали моментальные снимки, но это может обойтись довольно дорого по сравнению с s3. У кого-нибудь есть оценка того, сколько времени требуется для резервного копирования базы данных объемом 1 ТБ? И сколько времени требуется для восстановления базы данных объемом 1 ТБ?
Я читал документы Amazon, и там говорится, что восстановление из моментального снимка может занять до 20 минут, но не упоминается, как долго длится конвейер данных. У кого-нибудь есть какие-либо подсказки?
Ответ №1:
Выполняет ли недавно выпущенная функция экспорта из DynamoDB в S3 то, что вы хотите для вашего варианта использования? Однако для использования этой функции у вас должно быть включено непрерывное резервное копирование. Возможно, это даст вам необходимую кратковременную резервную копию?
Комментарии:
1. Эта функция является «улицей с односторонним движением». Я пытался экспортировать в S3, но вы не можете повторно импортировать обратно в S3. это только для целей анализа, а не для резервного копирования. это наиболее полезно для AWS Athena и Redshift!
Ответ №2:
Было бы интересно узнать, почему вы не планируете использовать встроенный механизм резервного копирования. Он обеспечивает восстановление на определенный момент времени и отличается высокой предсказуемостью с точки зрения стоимости и производительности.
Резервное копирование конвейеров данных непредсказуемо, скорее всего, будет стоить дороже, а в оперативном плане оно намного менее надежно. Кроме того, для получения согласованного моментального снимка (т.Е. На определенный момент времени) Требуется остановка мира. Исходя из опыта, я не рекомендую использовать конвейеры данных для резервного копирования таблиц DynamoDB!
Что касается времени, необходимого для создания резервной копии, это зависит от ряда факторов, но в основном от размера таблицы и выделенной емкости, которую вы готовы использовать для нее, а также от размера кластера EMR, с которым вы готовы работать. Таким образом, это может занять от минуты до нескольких часов.
Время восстановления также зависит практически от тех же переменных: выделенной емкости и общего размера. И это также может занять от минуты до многих часов.
Моментальное резервное копирование обеспечивает стабильную, предсказуемую и, что наиболее важно, надежную производительность независимо от размера таблицы: используйте это!
И если вы просто заинтересованы в выгрузке данных из таблицы (т.Е. Не Обязательно части восстановления), используйте новый экспорт в S3.
Комментарии:
1. Спасибо вам за ответ. Есть несколько причин, по которым я использую ОБА. 1. Восстановление на определенный момент времени (PITR) небезопасно для программ-вымогателей. Он использует то же шифрование, что и базовая база данных 2. Отключение PITR приведет к удалению резервной копии, что сделает ее уязвимой для случайного удаления или злонамеренного удаления всей таблицы 3. Это не защищает от захвата учетной записи, когда наличие резервной копии S3 означает, что я могу очень быстро запустить другой экземпляр в другой учетной записи, поэтому я использую резервное копирование S3 для архивирования, а BCDR и PITR для последовательного / быстрого восстановления! Мы используем оба для учета всех угроз.
2. Имеет смысл. В этом случае вы определенно можете использовать конвейер данных или аналогичную стратегию, но вам придется проверить себя, чтобы выяснить, сколько времени это займет в вашем конкретном случае. Самой большой проблемой, безусловно, является тот факт, что вам нужно прекратить запись в таблицу перед выполнением операции копирования данных
3. Простоев не будет. Вы все еще можете получить доступ к данным для чтения, но если вы продолжите запись, резервное копирование может быть несовместимым. Является ли это проблемой, зависит от вашего варианта использования. Вы также можете захотеть изучить потоковую передачу активности таблицы с использованием потоков DynamoDB.. таким образом, все записи могут быть вручную реплицированы в другую «резервную» таблицу в другой учетной записи. Гораздо лучшее решение IMO, если вы обеспокоены тем, что учетная запись может быть скомпрометирована.
4. @SKhurana выбрал AWS backup для кросс-аккаунта-кросс-региона, но для использования конвейеров данных для DynamoDB вместо глобальных таблиц
5. @VineethSai Спасибо за ваш ответ. Я полагаю, что конвейер данных для dynamodb вместо резервного копирования AWS, потому что резервное копирование между учетными записями в настоящее время не поддерживает таблицы Amazon DynamoDB, правильно? Какова была ваша причина использовать конвейер данных для dynamo вместо потоков ddb с использованием lambda, как утверждает AWS, здесь дешевле и быстрее aws.amazon.com/blogs/database /…