Резервное копирование кластера Cassandra со снимками и загрузка на s3 / vm?

Является ли резервное копирование Cassandra с помощью снимков и их загрузка обычным делом, связанным с кластером?

Я думал о том, чтобы задание cron на каждом узле создавало моментальный снимок, архивировало его и загружало каждые 24 часа, но меня немного беспокоит его влияние на производительность. Разве это не может нанести ему вред, когда объем данных на узле становится большим?

ReactJs | Supabase | Добавление данных в базу данных
ReactJs | Supabase | Добавление данных в базу данных
Это и есть ваш редактор таблиц в supabase.👇
1
0
252
2

Ответы 2

Существует 2 типа стратегии резервного копирования: полное резервное копирование и инкрементное резервное копирование. После того, как вы сделаете полную резервную копию, включите инкрементное резервное копирование на каждом узле. вы можете сделать 1 задание cron для синхронизации всех инкрементных резервных копий с s3. (Полная резервная копия + все инкрементные резервные копии, после чего создается последняя резервная копия).

Таким образом, у вас может быть другое задание cron, которое вы можете запускать только на выходных или раз в месяц, чтобы удалить все предыдущие резервные копии и сделать полную резервную копию.

Резервные копии, созданные nodetool snapshot в Cassandra, являются жесткими ссылками, поэтому фактически не занимают больше места, чем исходный файл. См. Этот пост для объяснения жестких / мягких ссылок:

https://askubuntu.com/questions/108771/what-is-the-difference-between-a-hard-link-and-a-symbolic-link

Однако, если вы не очищаете снимки с помощью nodetool clearsnapshot, ваши данные в кластере со временем будут расти. Документы здесь говорят о очистка снимков

Между прочим, nodetool tablestats (ранее nodetool cfstats) очень полезен для просмотра того, сколько данных моментальных снимков вы используете на данном узле для данной таблицы.

Другие вопросы по теме