Знімки для зберігання для постійного резервного копіювання postgresql - різні дані та обсяги журналу


11

Ми запускаємо багато віртуальних машин Linux у середовищі зберігання vmware / спільного зберігання, кожен з яких має свій власний екземпляр postgreSQL (поєднання 9.0 та 9.3). В даний час весь VM сидить на одному кореневому розділі / томі, і ми мали великий успіх (~ 8 років), використовуючи на основі сховища знімки базових томів VMFS для процесу резервного копіювання / відновлення (та реплікації на наш сайт DR).

Зважаючи на архітектуру нашого сховища, було б вигідно розділити WAL-файли postgres на не кешований, в основному, об'єм запису, щоб отримати меншу кількість кеш-пам'яті на стороні зберігання. За допомогою нашого сховища (Nimble Storage) ми можемо віднести обидва томи до однієї групи захисту / знімків, але я не зміг донести від нашого постачальника, що знімки будуть відбуватися ТОЧНО в один і той же час у всіх томах групи захисту. - це, мабуть, буде, але завжди є такий шанс, що його мілісекунди розійдуться.

З цією метою ми провели кілька експериментів, і все це записували дані в БД якомога швидше, використовуючи pg_bench. Після експериментів ми відновили свої знімки та розпочали VM + постгреси

  • Знімок як даних, так і обсягів журналу, близьких до одночасно - результату: відновлено БД
  • Спочатку обсяг даних знімка, об'єм журналу ~ 1 хвилину пізніше - результат: відновлено БД
  • Спочатку обсяг журналу знімків, обсяг даних ~ 1 хвилину пізніше - результат: відновлено БД
  • Спочатку обсяг журналу знімків, об'єм даних ~ 3 хвилини пізніше, після того як контрольна точка WAL записала нові дані у файли даних: результат: відновлено БД

Таким чином, тестування, здається, говорить нам, якщо обидва знімки послідовні на рівні гучності, і відносно близько один до одного, ви отримуєте послідовну копію БД, засновану на часі знімка обсягу WAL / Log.

Моє запитання: Це безпечно? Які найважливіші випадки, яких нам не вистачає при тестуванні, і що може піти не так?

Документ Postgres вказує, що це не є безпечним, але тестування, схоже, вказує на його досить надійний: http://www.postgresql.org/docs/9.1/static/backup-file.html

Якщо ваша база даних поширюється на декілька файлових систем, можливо, не існує жодного способу отримання точно одночасних заморожених знімків усіх томів. Наприклад, якщо ваші файли даних та журнал WAL знаходяться на різних дисках, або якщо таблиці в різних файлових системах, можливо, неможливо використовувати резервну копію знімків, оскільки знімки повинні бути одночасними. Прочитайте документацію вашої файлової системи дуже уважно, перш ніж довіряти техніці послідовних знімків у таких ситуаціях.

ПРИМІТКА. Так, ми знаємо про інші параметри, щоб переконатися, що вони є послідовними, як, наприклад, перевести PostgreSQL в гарячий режим резервного копіювання або використовувати інтеграцію VMware нашого сховища для того, щоб вимкнути самі VM, але ми шукаємо рішення для зберігання лише для швидкості, зручності, нульовий вплив на наших клієнтів.


2
Оновлення - наш постачальник сховища, Nimble Storage, повернувся сьогодні, однозначно сказавши, що знімки, зроблені як частина групи захисту, дійсно узгоджуються в обсягах / зроблених в точний момент часу, тому моє питання справді суперечить. Однак - мені все одно цікаво, якщо хтось має коментарі, оскільки в нашому тестуванні Postgres здається досить надійним, щоб вижити знімків, зроблених не одночасно.
Стів Р.

Що ви маєте на увазі, коли ви говорите "Спочатку обсяг даних знімка, об'єм журналу ~ 1 хвилину пізніше", якщо і дані, і об'єм журналу знаходяться в одній групі знімків, це буде зроблено одночасно. помістіть дані та обсяг журналу в одну групу знімків і зробіть знімок, а потім відновіть БД з цього знімка, це як відновлення аварійного завершення. Я тестував резервне копіювання на основі зберігання EMC за допомогою технології знімків для Oracle. Це дуже надійно.
fairybetty

Відповіді:


2

Документація, яку ви цитували, говорить про це все, але я б не звинувачував вас, якщо ви хочете спробувати перевірити претензії постачальника щодо знімків, зроблених одночасно. Можливо, способом розкрити щось могло б бути стрес-тест WAL-системи більш конкретно.

Наприклад, крім ваших тестів на основі pgbench, спробуйте додати випадкові виклики, щоб pg_switch_xlog()примусити обертання журналу, коротші та довші інтервали контрольних точок (скорочення та подовження checkpoint_timeoutта checkpoint_timeout) та навіть використовуючи невеликі чи великі розміри файлів wal.

Якщо щось не вистачає, для ваших знімків, зроблених не одночасно, я віднесу ваші відновлені БД, можливо, до трохи вдалого часу. В останньому випадку уявіть, що ви зробили знімок свого журналу, коли, наприклад, поточне місце розташування xlog було 0/A1C0FFEE. Тоді у вас є 3 хвилини особливо великого навантаження на систему, що спричиняє повний цикл через файли WAL, і ваша БД зараз знаходиться, 0/DEADBEEFколи зроблений знімок даних. Коли ви намагаєтесь відновити, файли WAL, записані в момент знімка даних, давно минули, і відновлення не вдалося.

Використовуючи наш веб-сайт, ви визнаєте, що прочитали та зрозуміли наші Політику щодо файлів cookie та Політику конфіденційності.
Licensed under cc by-sa 3.0 with attribution required.