Ежедневное автоматическое резервное копирование базы данных Postgresql с небольшого SSD на несколько жестких дисков

Относительный новичок в sql и pg здесь, так что это относительно открытый вопрос о резервном копировании ежедневных данных из потока. Конкретные команды/скрипты будут оценены, если это просто, в противном случае я буду рад получить более конкретные статьи/учебники о том, как реализовать то, что нужно сделать.

Ситуация

Я записываю различные потоки данных с некоторых внешних серверов в объеме нескольких ГБ/день каждый день. Я хочу иметь возможность хранить эти данные на больших жестких дисках, которые затем будут использоваться для извлечения информации для последующего анализа.

Оборудование

x1 SSD (128 ГБ) (ОС + приложение)

x2 HDD (4 ТБ каждый) (хранилище, 2-й диск для резервирования)

Что нужно сделать

Текущий план состоит в том, чтобы на SSD хранилась временная база данных, состоящая из ежедневно регистрируемых данных. Когда нагрузка на сервер низкая (рано утром), выгружайте всю временную базу данных на два отдельных экземпляра резервных копий на каждом из двух дисков хранения. Мотивация для хранения временной базы данных состоит в том, чтобы уменьшить нагрузку на жесткие диски. Кроме того, ежедневные данные достаточно малы, чтобы их можно было скопировать на накопители до того, как нагрузка на сервер возрастет.

Вопросы

  1. Это приемлемый метод?
  2. Лучше/безопаснее ли просто передавать данные непосредственно на один из дисков хранения, учитывая, что это основная база данных, и автоматизировать запланированное резервное копирование с этого диска на второй диск хранилища?
  3. Какие конкретные команды потребуются для этого, чтобы обеспечить целостность данных (т. е. пока выполняется резервное копирование, новые данные все равно будут регистрироваться)

Позже, когда позволит бюджет, аппаратное обеспечение будет обновлено, но на данный момент это то, что указано выше.

Спасибо!


person undercurrent    schedule 05.06.2015    source источник
comment
Вы знакомы с архивированием PITR/WAL?   -  person Craig Ringer    schedule 05.06.2015
comment
@CraigRinger Нет; однако сейчас я читаю об этом pg docs   -  person undercurrent    schedule 07.06.2015


Ответы (1)


Первое правило при построении системы резервного копирования — делайте самое простое, что вам подходит.

Запуск pg_dump обеспечит целостность данных. Вы будете обращать внимание на последний сохраненный элемент, чтобы убедиться, что вы не удалили ничего более нового. После удаления данных вы можете запустить CLUSTER или VACUUM FULL для различных таблиц, если вы можете позволить себе ведение журнала.

Другой вариант - иметь пустую базу данных шаблонов и сделать что-то вроде:

  1. Остановить приложение + отключиться
  2. Переименуйте базу данных с «current_db» на «old_db».
  3. СОЗДАТЬ БАЗУ ДАННЫХ current_db ШАБЛОН my_template_db
  4. Скопируйте любые другие биты, которые вам нужны (порядковые номера и т. д.)
  5. Переподключить приложение
  6. Дамп old_db + копирование бэкапов на другие диски.

Если вам на самом деле нужны две отдельные живые базы данных, одна маленькая быстрая и одна большая для длительных запросов, тогда исследуйте табличные пространства. Создайте два табличных пространства — по умолчанию на больших дисках и «маленькое» на вашем SSD. Поместите свою маленькую БД на SSD. Затем вы можете просто скопировать из одной таблицы в другую с помощью внешних оболочек данных (FDW) или дампа/восстановления и т. д.

person Richard Huxton    schedule 05.06.2015
comment
Привет @RichardHuxton, спасибо за ваш ответ. В идеале база данных не должна быть отключена, так как всегда есть возможность поступления данных. Должна быть только одна действующая база данных, но эта база данных должна постоянно создавать резервные копии, по крайней мере, один раз в день. Что вы думаете о хранении небольшой временной базы данных на SSD и использовании ее для дампа на жесткие диски хранилища вместо постоянной записи на жесткие диски хранилища. Не стоит дополнительного уровня сложности? Копирование с SSD по частям уменьшит износ жесткого диска. - person undercurrent; 07.06.2015