Сравнение на висока наличност на база данни - MySQL / MariaDB репликация срещу Oracle Data Guard

В „Състоянието на пазара на СУБД с отворен код, 2018 г.“, Gartner прогнозира, че до 2022 г. 70 процента от новите вътрешни приложения ще бъдат разработени в база данни с отворен код. И 50% от съществуващите търговски бази данни ще бъдат конвертирани. Така че, администратори на база данни на Oracle, пригответе се да започнете да внедрявате и управлявате нови бази данни с отворен код – заедно с вашите наследени екземпляри на Oracle. Освен ако вече не го правите.

И така, как MySQL или MariaDB репликацията се подрежда срещу Oracle Data Guard? В този блог ще сравним двете от гледна точка на решение за база данни с висока достъпност.

Какво да търсите

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

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

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

Основни теми за сравнение

• Наличност и последователност на данните
  • Gtid, scm
  • Споменете репликация към множество модели в режим на готовност, асинхронно + синхронизиране
  • Изолиране на режим на готовност от производствени грешки (напр. забавена репликация за mysql)
  • Избягвайте загуба на данни (синхронизирана репликация)
• Използване на системи в режим на готовност
  • Използване на режим на готовност
• Преминаване при отказ, превключване и автоматично възстановяване
  • Преминаване при отказ на база данни
  • Прозрачен отказ на приложение (TAF срещу ProxySQL, MaxScale)
• Сигурност
• Леснота на използване и управление (унифицирано управление на предварително интегрирани компоненти)

Наличност и последователност на данните

MySQL GTID

Репликацията на MySQL 5.5 се базираше на двоични дневници, където всичко, което робът знаеше, беше точното събитие и точната позиция, която току-що прочете от главния. Всяка отделна транзакция от главен може да е завършила в различни двоични регистрационни файлове от различни подчинени и транзакцията обикновено има различни позиции в тези регистрационни файлове. Това беше просто решение, което идваше с ограничения, промените в топологията можеха да изискват администратор да спре репликацията на участващите екземпляри. Тези промени могат да причинят някои други проблеми, например подчинен не може да бъде преместен надолу по веригата на репликация без отнемащо време възстановяване. Коригирането на счупена връзка за репликация ще изисква ръчно определяне на нов двоичен регистрационен файл и позиция на последната транзакция, изпълнена на подчинения и възобновяване от там, или пълно възстановяване. Всички трябваше да заобиколим тези ограничения, докато мечтаем за глобален идентификатор на транзакция.

MySQL версия 5.6 (и MariaDB версия 10.0.2) въведе механизъм за решаване на този проблем. GTID (глобален идентификатор на транзакция) осигурява по-добро картографиране на транзакциите между възлите.

С GTID подчинените могат да видят уникална транзакция, идваща от няколко главни и това може лесно да бъде картографирано в списъка за изпълнение на подчинени, ако трябва да рестартира или възобнови репликацията. Така че съветът е винаги да използвате GTID. Имайте предвид, че MySQL и MariaDB имат различни реализации на GTID.

Oracle SCN

През 1992 г. с изданието 7.3 Oracle представи решение за запазване на синхронизирано копие на база данни в режим на готовност, известно като Data Guard от версия 9i издание 2. Конфигурацията на Data Guard се състои от два основни компонента, една основна база данни и резервна база данни (до 30). Промените в основната база данни се предават през резервната база данни и тези промени се прилагат към нея, за да се поддържа синхронизирана.

Oracle Data Guard първоначално се създава от резервно копие на основната база данни. Data Guard автоматично синхронизира основната база данни и всички резервни бази данни, като предава първичната база данни за повторение – информацията, използвана от всяка база данни на Oracle за защита на транзакции – и я прилага към резервната база данни. Oracle използва вътрешен механизъм, наречен SCN (System Change Number). Номерът за промяна на системата (SCN) е часовникът на Oracle, всеки път, когато извършваме ангажимент, часовникът се увеличава. SCN маркира последователен момент във времето в базата данни, който е контролна точка, която е актът на запис на мръсни блокове (модифицирани блокове от буферния кеш на диска). Можем да го сравним с GTID в MySQL.

Транспортните услуги на Data Guard се справят с всички аспекти на предаването на повторно изпълнение от първична към резервна база данни. Тъй като потребителите извършват транзакции на основния, записи за повторение се генерират и записват в локален онлайн регистрационен файл. Транспортните услуги на Data Guard едновременно предават едно и също повторно изпълнение директно от първичния регистрационен буфер на базата данни (памет, разпределена в рамките на глобалната област на системата) към резервната база данни(и), където се записва в резервен регистрационен файл за повторно изпълнение.

Има няколко основни разлики между MySQL репликацията и Data Guard. Директното предаване на Data Guard от паметта избягва претоварването на дисковия вход/изход върху основната база данни. Това е различно от начина, по който работи MySQL – четенето на данни от паметта намалява I/O на основна база данни.

Data Guard предава само повторение на базата данни. Това е в рязък контраст с отдалеченото копиране на съхранение, което трябва да предава всеки променен блок във всеки файл, за да поддържа синхронизация в реално време.

Асинхронни + синхронизиращи модели

Oracle Data Guard предлага три различни модела за повторно прилагане. Адаптивни модели в зависимост от наличния хардуер, процеси и в крайна сметка бизнес нужди.

• Максимална производителност – режим на работа по подразбиране, позволяващ на транзакция да се завърже веднага щом данните за повторно изпълнение, необходими за възстановяване на тази транзакция, бъдат записани в локалния дневник за повторно изпълнение на главния.
• Максимална защита – без загуба на данни и максимално ниво на защита. Данните за повторно извършване, необходими за подобряване на всяка операция, трябва да бъдат записани както в локалния онлайн дневник за повторно изпълнение на главния, така и в резервния регистър за повторно изпълнение в поне една резервна база данни, преди транзакцията да бъде ангажирана (Oracle препоръчва поне два режима на готовност). Основната база данни ще се изключи, ако грешка я блокира да запише своя поток за повторно изпълнение в поне една синхронизирана база данни в режим на готовност.
• Максимална наличност – подобно на максималната защита, но основната база данни няма да се изключи, ако грешка не й позволи да запише своя поток за повторно изпълнение.

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

• Прилагането на асинхронен binlog е методът по подразбиране за MySQL репликация. Главният записва събития в своя двоичен дневник и подчинените ги изискват, когато са готови. Няма гаранция, че някое събитие някога ще достигне до роб.
• Полусинхронното записване на първичния се отлага, докато главният не получи потвърждение от полусинхронното подчинено устройство, че данните се получават и записват от подчинения. Моля, имайте предвид, че полусинхронната репликация изисква инсталиране на допълнителен плъгин.

Използване на системи в режим на готовност

MySQL е добре известен със своята простота и гъвкавост на репликация. По подразбиране можете да четете или дори да пишете на вашите резервни/подчинени сървъри. За щастие MySQL 5.6 и 5.7 донесоха много значителни подобрения на репликацията, включително глобални идентификатори на транзакции, контролни суми на събития, многонишкови подчинени и безопасни при срив подчинени/главни, за да го направят още по-добро. DBA, свикнали с MySQL репликация, четене и запис, биха очаквали подобно или дори по-просто решение от неговия по-голям брат, Oracle. За съжаление не по подразбиране.

Стандартната физическа готовност за Oracle е затворена за всякакви операции четене-запис. Всъщност Oracle предлага логически варианти, но има много ограничения и не е проектиран за HA. Решението на този проблем е допълнителна платена функция, наречена Active Data Guard, която можете да използвате за четене на данни от режим на готовност, докато прилагате регистрационни файлове за повторно изпълнение.

Active Data Guard е платена добавка към безплатния софтуер за възстановяване след бедствие на Oracle Data Guard, наличен само за Oracle Database Enterprise Edition (лиценз с най-висока цена). Той предоставя достъп само за четене, като същевременно прилага непрекъснато промени, изпратени от основната база данни. Като активна резервна база данни, тя помага за разтоварване на заявки за четене, отчети и инкрементални архиви от основната база данни. Архитектурата на продукта е проектирана така, че да позволи на резервните бази данни да бъдат изолирани от повреди, които могат да възникнат в основната база данни.

Вълнуваща характеристика на базата данни на Oracle 12c и нещо, което Oracle DBA би пропуснало, е проверката на повреда на данните. Проверките за повреда на Oracle Data Guard се извършват, за да се гарантира, че данните са в точно подравняване, преди данните да бъдат копирани в резервна база данни. Този механизъм може да се използва и за възстановяване на блокове от данни на първичния директно от резервната база данни.

Преминаване при отказ, превключване и автоматично възстановяване

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

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

Има два основни подхода за преминаване на MySQL при отказ, автоматичен и ръчен. И двата варианта имат своите фенове, ние описваме концепциите в друга статия.

С GTID ръчното преминаване при отказ става много по-лесно. Състои се от стъпки като:

• Спрете модула на приемника (STOP SLAVE IO_THREAD)
• Превключете главен (ПРОМЯНЕТЕ ГЛАВНИЯ КЪМ )
• Стартирайте модула на приемника (START SLAVE IO_THREAD)

Oracle Data Guard идва със специално решение за отказ/превключване - Data Guard Broker. Брокерът е разпределена рамка за управление, която автоматизира и централизира създаването, поддръжката и наблюдението на конфигурации на Oracle Data Guard. С достъпа до инструмента за брокер на DG можете да извършвате промени в конфигурацията, превключване, превключване на отказ и дори сух тест на вашата настройка за висока наличност. Двете основни действия са:

• Командата SWITCHOVER TO се използва за извършване на операцията по превключване. След успешната операция по превключване, екземплярите на базата данни сменят местата си и репликацията продължава. Не е възможно да превключите, когато режимът на готовност не отговаря или е изключен.
• Общото FAILOVER TO <име на база данни в готовност> се използва за извършване на отказ. След операцията за преодоляване на отказ предишният основен сървър изисква повторно създаване, но новият основен може да поеме работното натоварване на базата данни.

Говорейки за отказване, трябва да помислим колко безпроблемно може да бъде превключването на вашето приложение при отказ. В случай на планирано/непланирано прекъсване, колко ефективно потребителските сесии могат да бъдат насочени към вторичен сайт с минимално прекъсване на бизнеса.

Стандартният подход за MySQL би бил да се използва един от наличните Load Balancers. Започвайки от HAProxy, който се използва широко за HTTP или TCP/IP преодоляване на срив, до Maxscale или ProxySQL, наясно с базата данни.

В Oracle този проблем се решава от TAF (Transparent Application Failover). След като настъпи превключване или отказ, приложението автоматично се насочва към новия първичен. TAF позволява на приложението автоматично и прозрачно да се свърже отново с нова база данни, ако екземплярът на базата данни, към който е направена връзката, не успее.

Сигурност

Сигурността на данните е горещ проблем за много организации в наши дни. За тези, които трябва да внедрят стандарти като PCI DSS или HIPAA, сигурността на базата данни е задължителна. Кръстосаните WAN среди могат да доведат до опасения относно поверителността и сигурността на данните, особено тъй като все повече фирми трябва да спазват националните и международните разпоредби. MySQL двоични регистрационни файлове, използвани за репликация, може да съдържат лесни за четене чувствителни данни. Със стандартната конфигурация кражбата на данни е много лесен процес. MySQL поддържа SSL като механизъм за криптиране на трафик както между MySQL сървъри (репликация), така и между MySQL сървъри и клиенти. Типичен начин за внедряване на SSL криптиране е използването на самоподписани сертификати. През повечето време не се изисква получаване на SSL сертификат, издаден от сертифициращия орган. Можете да използвате openssl за създаване на сертификати, пример по-долу:

$ openssl genrsa 2048 > ca-key.pem
$ openssl req -new -x509 -nodes -days 3600 -key ca-key.pem > ca-cert.pem
$ openssl req -newkey rsa:2048 -days 3600 -nodes -keyout client-key.pem > client-req.pem
$ openssl x509 -req -in client-req.pem -days 1000 -CA ca-cert.pem -CAkey ca-key.pem -set_serial 01 > client-cert.pem
$ openssl req -newkey rsa:2048 -days 3600 -nodes -keyout client-key.pem > client-req.pem
$ openssl x509 -req -in client-req.pem -days 1000 -CA ca-cert.pem -CAkey ca-key.pem -set_serial 01 > client-cert.pem
$ openssl rsa -in client-key.pem -out client-key.pem
$ openssl rsa -in server-key.pem -out server-key.pem

След това променете репликацията с параметри за SSL.

….MASTER_SSL=1, MASTER_SSL_CA = '/etc/security/ca.pem', MASTER_SSL_CERT = '/etc/security/client-cert.pem', MASTER_SSL_KEY = '/etc/security/client-key.pem';

За по-автоматизирана опция можете да използвате ClusterControl за активиране на криптиране и управление на SSL ключове.

В Oracle 12c, Data Guard повторното транспортиране може да бъде интегрирано с набор от специални функции за сигурност, наречени Oracle Advanced Security (OAS). Разширената защита може да се използва за активиране на услуги за криптиране и удостоверяване между първичната и резервната системи. Например, активиране на алгоритъм за криптиране Advanced Encryption Standard (AES) изисква само няколко промени в параметрите във файла sqlnet.ora, за да се направи повторното (подобно на MySQL binlog) криптирано. Не се изисква настройка на външен сертификат и изисква само рестартиране на базата данни в режим на готовност. Модификацията в sqlnet.ora и портфейла са прости като:

Създайте директория на портфейла

mkdir /u01/app/wallet

Редактирайте sqlnet.ora

ENCRYPTION_WALLET_LOCATION=
 (SOURCE=
  (METHOD=file)
   (METHOD_DATA=
    (DIRECTORY=/u01/app/wallet)))

Създайте хранилище за ключове

ADMINISTER KEY MANAGEMENT CREATE KEYSTORE '/u01/app/wallet' identified by root ;

Отворете магазин

ADMINISTER KEY MANAGEMENT set KEYSTORE open identified by root ;

Създайте главен ключ

ADMINISTER KEY MANAGEMENT SET KEY IDENTIFIED BY root WITH BACKUP;

В режим на готовност

копирайте p12 и .sso файлове в директорията на портфейла и за да актуализирате файла sqlnet.ora подобно на основния възел.

За повече информация, моля, следвайте бялата книга на Oracle TDE, можете да научите от бялата книга как да шифровате файла с данни и да направите портфейла винаги отворен.

Леснота на използване и управление

Когато управлявате или внедрявате конфигурация на Oracle Data Guard, може да разберете, че има много стъпки и параметри, които да търсите. За да отговори на това, Oracle създаде DG Broker.

Със сигурност можете да създадете конфигурация на Data Guard, без да прилагате DG Broker, но това може да направи живота ви много по-удобен. Когато бъде внедрена, помощната програма за командния ред на брокера - DGMGRL вероятно е основният избор за DBA. За тези, които предпочитат GUI, Cloud Control 13c има опция за достъп до DG Broker чрез уеб интерфейса.

Задачите, с които Broker може да помогне, са автоматично стартиране на управляваното възстановяване, една команда за отказ/превключване, наблюдение на репликацията на DG, проверка на конфигурацията и много други.

DGMGRL> show configuration 
Configuration - orcl_s9s_config 

Protection Mode: MaxPerformance
  Members:

s9sp  - Primary database
    s9ss - Physical standby database 

Fast-Start Failover: DISABLED
Configuration Status:
SUCCESS   (status updated 12 seconds ago

MySQL не предлага подобно решение на Oracle DG Broker. Въпреки това можете да разширите функционалността му, като използвате инструменти като Orchestrator, MHA и балансьори на натоварване (ProxySQL, HAProxy или Maxscale). Решението за управление на бази данни и балансьори на натоварване е ClusterControl. ClusterControl Enterprise Edition ви предоставя пълен набор от функции за управление и мащабиране в допълнение към функциите за внедряване и наблюдение, предлагани като част от безплатното издание на Общността.