PostgreSQL
 sql >> база данни >  >> RDS >> PostgreSQL

Опции за архивиране в облак за PostgreSQL

Този блог беше актуализиран на 27.11.18 и 29.11.18 за да направи промени, както е препоръчано от нашите страхотни коментатори!

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

Независимо дали това е ядрото на бизнеса или просто друг компонент, базите данни трябва да се архивират редовно и да се съхраняват на безопасни места за евентуално бъдещо възстановяване.

Трябва ли да архивирам в облака?

Общо правило е да имате поне 3 копия на нещо ценно и да съхранявате тези резервни копия на различни места. Архивите на едно и също устройство са безполезни, ако самото устройство умре, същите архиви на хост също са изложени на риск, ако хостът се повреди, а същите архиви на сграда също са в опасност, ако сградата изгори (драстично и малко вероятно, но възможно).

Облачните архиви предлагат лесно решение за необходимостта от резервни копия извън сайта, без да се налага да завъртате нов хардуер на второ място. Има много различни облачни услуги, които предлагат архивно съхранение и изборът на правилния ще зависи от нуждите за архивиране, изискванията за размер, цената и сигурността.

Предимствата от наличието на облачни архиви са много, но основно се въртят около това тези резервни копия да се съхраняват на място, различно от основната база данни, което ни позволява да имаме защитна мрежа в случай на възстановяване след бедствие. Въпреки че няма да навлизаме в подробности как да настроим всяка от тези опции за архивиране, ще проучим някои различни идеи и конфигурации за архивиране.

Има някои недостатъци при съхраняването на резервни копия в облака, като се започне с прехвърлянето. Ако резервните копия на базата данни са изключително големи, може да отнеме много време за извършването на действителното качване и дори може да има увеличени разходи, ако облачната услуга таксува за прехвърляне на честотна лента. Компресирането е силно препоръчително, за да запазите времето и разходите ниски.

Сигурността може да бъде друг проблем с хостването на резервни копия в облака, докато някои компании имат строги указания за това къде се съхраняват и съществуват техните данни. Ако сигурността е проблем, всички резервни копия могат да бъдат криптирани, преди да бъдат експортирани в услуга за облачен хостинг.

Опции за архивиране в облак

Има няколко различни начина за създаване на резервни копия на база данни за PostgreSQL и в зависимост от вида на архивирането, времето за възстановяване, размера и инфраструктурните опции ще варират. Тъй като много от решенията за съхранение в облак са просто съхранение с различни интерфейси на API, всяко умно решение за архивиране може да бъде създадено с малко скриптове.

Архивни копия на моментни снимки

Моментните снимки са резервни копия, които имат копие на базата данни PostgreSQL в определен момент от време. Тези резервни копия се създават или чрез използване на pg_dump, който просто изхвърля базата данни в един файл, или чрез копиране на основната директория с данни за PostgreSQL. Всяко от тях може да бъде компресирано, копирано на други устройства и сървъри и копирано в желаната опция за съхранение в облак.

Използване на pg_dump с компресия

pg_dump -Fc severalnines > severalnines.dmp

Архивиране на директория с данни с помощта на pg_basebackup

Програмата pg_basebackup може да се използва за създаване на базов архив много лесно. За повече информация относно всички функции и как да ги настроите, посетете официалната документация за използваната версия на PostgreSQL.

pg_basebackup --format=tar -z -D severalnines_basebackup

Amazon S3

С платформата AWS на Amazon, S3 е услуга за съхранение на данни, която може да се използва за съхраняване на резервни копия на база данни. Докато резервните копия могат да се качват през уеб интерфейса, Amazon CLI (интерфейс на командния ред) може да се използва за това от командния ред и чрез скриптове за автоматизиране на архивиране. Информация за AWS CLI можете да намерите тук. Ако резервните копия трябва да се съхраняват много дълго време и времето за възстановяване не е проблем, резервните копия могат да бъдат прехвърлени към услугата Glacier на Amazon, осигурявайки много по-евтино дългосрочно съхранение.

aws s3 cp severalnines.dmp s3://severalninesbucket/backups

Amazon също има различни региони за своите услуги по целия свят. Въпреки че имат добра история на работа, разпространението на архивни копия в множество региони увеличава възможностите за възстановяване при бедствие и намалява шансовете за загуба на ценни данни.

Microsoft Azure Storage

Облачната платформа на Microsoft, Azure, има опции за съхранение със собствен интерфейс на командния ред, информация може да бъде намерена тук.

az storage blob upload --container-name severalnines --file severalnines.dmp --name severalnines_backup

Всички други модерни услуги за съхранение в облак трябва да предлагат подобни инструменти за копиране на резервни копия на техните облачни сървъри, консултирайте се с тяхната документация за подробности.

Резервни копия в режим на готовност

Понякога самите резервни копия могат да бъдат изключително големи, дори ако са компресирани, а качването на ежедневен или седмичен архив в облачна услуга може да не подлежи на работа поради скорости на честотната лента и/или разходи. Така че получаването на резервно копие в облака за безопасно съхранение е много по-трудно.

Един от начините да направите това е да имате топъл или горещ режим на готовност, работещ в базирана на облак виртуална машина, като екземпляр на Amazon EC2, където това е точно копие на основната основна база данни и единствените данни, които се изпращат до облачния екземпляр е всякакви промени, а не друго копие на цялата база данни. Това ще изисква прехвърляне на цялата база данни наведнъж, но след това трябва да се прехвърлят само промените.

Но дали резервният сървър всъщност е резервно копие? Ако основната база данни падне, режимът на готовност може да бъде превърнат в главен и приложенията да бъдат пренасочени към нея, но ако целта е да има резервни копия за определен момент от време през последната седмица/месеци, това няма да се получи.

За да поправите това, могат да се направят няколко неща. Самото състояние на готовност може да бъде принудено да има забавяне, като например поглъща данни само след като е на ден. Друг е да създавате резервни копия по един от традиционните начини (pg_dump, копие на директория с данни) в режим на готовност в облака, което означава, че тези резервни копия няма да е необходимо да се прехвърлят по мрежата, тъй като се създават на самата облачна машина. Преводите в мрежата обикновено са по-бързи и по-евтини.

Архивни копия на ClusterControl и облак

Severalnines създаде ClusterControl, система за управление на база данни, която помага за управлението на много различни бази данни, включително PostgreSQL. Това е най-добрата кутия с инструменти за всеки администратор на база данни или системен администратор, за да има пълен контрол и видимост на своите бази данни и включва много удобни функции за архивиране.

С ClusterControl архивирането на PostgreSQL бази данни може лесно да се управлява, планира и настройва за автоматично копиране на направените архиви в услуги за „облачно съхранение“, включително Amazon S3, Microsoft Azure и Google Cloud. Това прави не е необходимо да се скриптират персонализирани инструменти за качване на архиви в облака, както и дава приятен потребителски интерфейс за архивирането като цяло.

Архивирането на нашите бази данни винаги трябва да се случва, а съхраняването им на второ, трето и четвърто място е много добра и често срещана практика. Добавянето на облачна опция увеличава опциите за възстановяване при бедствия и поставя още един слой на стабилност на задния край на бизнеса, където в много случаи, ако базата данни изчезне, компанията изчезва. Проучването на опциите за архивиране в облак днес може да премахне бедствието утре.


  1. Database
  2.   
  3. Mysql
  4.   
  5. Oracle
  6.   
  7. Sqlserver
  8.   
  9. PostgreSQL
  10.   
  11. Access
  12.   
  13. SQLite
  14.   
  15. MariaDB
  1. Изпълнете тази заявка за работни часове в PostgreSQL

  2. CS50:LIKE оператор, заместване на променлива с % разширение

  3. Грешка в Postgres:Повече от един ред, върнати от подзаявка, използвана като израз

  4. Събитието ROLLBACK се задейства в postgresql

  5. Postgres UTC формат на дата и епоха, инверсия на знака