Ми запускаємо багато віртуальних машин 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, але ми шукаємо рішення для зберігання лише для швидкості, зручності, нульовий вплив на наших клієнтів.