0

Если у меня есть база данных MonetDB, работающая на RHEL, которая находится в области сотен миллионов строк (сотни ГБ) с десятками (но не сотнями) таблиц, и я заинтересован в реализации достойной стратегии резервного копирования для нее, в частности в отношении механики этого.MonetDB Backups - методология?

До сих пор я использую Баш скрипт для вызова msqldump итеративно, один раз в таблицу в базе данных и обжигающе данные в файл, как:

msqldump -u [username] -t [tablename] -d [dbname] > /path/[tablename].sql.gz 

У меня есть. файл monetdb настроен, поэтому мне не предлагается пароль для выполнения каждого вызова msqldump, поэтому этот скрипт можно вызывать и разрешать завершать без присмотра.

Это похоже на то, что я получаю набор файлов, которые содержат все данные и схему, необходимые для восстановления этих таблиц в базе данных MonetDB, но это кажется очень грубым (и отнимающим много времени для выполнения), поэтому мне интересно, есть ли «лучший» способ?

Должен ли я беспокоиться о том, что произойдет, если содержимое базы данных изменяется во время операции msqldump, например? Есть ли более чистый и/или более быстрый способ получить полную резервную копию базы данных MonetDB, возможно, остановив db/farm и просто сделав копии самих файлов данных, и если да, то какая именно методология для этого? Существуют ли люди/организации, использующие MonetDB в любом крупном или корпоративном стиле, и как они реализуют такую ​​же стратегию резервного копирования, которая может быть реализована для базы данных MSSQL или аналогичной?

Я искал вокруг довольно много онлайн и здесь, на StackOverflow, и не смог найти много способов руководства по этому вопросу, поэтому я надеюсь, что кто-то здесь сможет помочь.

Заранее спасибо.

ответ

1

msqldump - предпочтительный способ сделать чистые снимки баз данных в сериализованные SQL-скрипты. Возможно, однако, вы бы предпочли называть его только один раз для всей базы данных, а не один раз за таблицу. Это будет быстрее, но, что более важно, более последовательным, если ваша схема базы данных изменится с течением времени.

Вы также можете сделать физическую копию базы данных в ее двоичном формате, как вы намекали. Каждая база данных хранится в папке с тем же именем, в <dbfarm location>/<dbname>. Для этого требуется, чтобы база данных была остановлена ​​(monetdb stop) и заблокирована (monetdb lock), чтобы пользователи не запускали ее автоматически. Чтобы восстановить базу данных, просто скопируйте ее обратно в <dbfarm location> и откройте ее (monetdb release). Никакой дальнейшей регистрации/настройки базы данных не требуется. Если вы хотите восстановить его с другим именем, просто измените имя его папки.

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

  • Serialized является более надежным в разных версиях. Двоичные БД обычно преобразуются автоматически в требуемую версию, но только если сохраненная версия не слишком стар.
  • Сериализованный более безопасный, поскольку он может быть отредактирован, если необходимо
  • Сериализованный не требует простоев. О вашем конкретном вопросе: не беспокойтесь о обновлениях во время дампа. Свалка происходит на изолированном снимке.Напротив, двоичная резервное копирование требует базы данных должна быть остановлена ​​и заблокирована
  • Binary, как правило, быстрее
  • Не может выполнить добавочное резервное копирование

Мой предпочтительный подход, с предположением о производственной базы данных используется довольно часто , то же самое вы предлагаете, но и для всей базы данных сразу (и обжигающе его gzip, что вы забыли в вашем примере):

msqldump -u [username] -d [dbname] | gzip > /path/[databasename].sql.gz 

Полезные ссылки:

+0

Большое спасибо за этот полный ответ - он заполнил много пробелов для меня, и было очень приятно, что мой первый вопрос здесь ответил так хорошо. :) – 3N1GM4

+0

Рад, что это помогло. Пожалуйста, рассмотрите [принятие] (http://stackoverflow.com/help/someone-answers) ответы, которые отвечают вашим вопросам. – cornuz

+0

Спасибо, я сделал. Извините, но я не понимал изначально, что принятие ответа было отличным от того, чтобы его перенести (чего у меня пока нет). – 3N1GM4

Смежные вопросы