Базите данни могат да се провалят без предупреждение - или поради срив, причинен от софтуерна грешка, или поради основните хардуерни компоненти. Облакът внася друго измерение на проблема поради ефимерния характер на изчислителните и сторидж ресурси. За да изолираме нашата инфраструктура на базата данни от тези повреди, ние вграждаме излишък в нашите системи. Ако даден екземпляр стане недостъпен, системата в режим на готовност трябва да може да поеме натоварването и да продължи оттам. Репликацията е добре познат и широко разпространен метод за създаване на излишни копия на главна база данни.
В тази публикация ще сравним функционалността за репликация в двете най-популярни системи за бази данни на планетата (според db-engines) - Oracle и MySQL. Ще разгледаме специално логическата репликация на Oracle 12c и MySQL 5.7. И двете технологии предлагат надеждни системи в режим на готовност за разтоварване на производствените натоварвания и помощ в случай на бедствие. Ще разгледаме различните им архитектури, ще анализираме плюсовете и минусите и ще преминем през стъпките как да настроим репликация с Oracle и MySQL.
Архитектура на Oracle Data Guard – как работи
Oracle Data Guard гарантира висока наличност, защита на данните и възстановяване след бедствие на вашите данни. Вероятно това е първият избор на Oracle DBA за репликиране на данни. Технологията е въведена през 1990 г. (версия 7.0) с основно приложение на архивни регистрационни файлове в резервни бази данни. Data Guard се развива през годините и сега предоставя изчерпателен набор от услуги, които създават, поддържат, управляват и наблюдават резервни бази данни.
Data Guard поддържа резервни бази данни като копия на производствената база данни. Ако основната база данни спре да отговаря, Data Guard може да превключи всеки режим на готовност към производствената роля, като по този начин престои. Data Guard може да се използва за техники за архивиране, възстановяване и клъстери, за да осигури високо ниво на защита на данните и наличност на данни.
Data Guard е технология за корабно повторение/прилагане на повторение, „повторяване“ е информацията, необходима за възстановяване на транзакции. Производствена база данни, наричана първична база данни, излъчва повторно към една или повече реплики, наричани резервни бази данни. Когато се направи вмъкване или актуализация на таблица, тази промяна се улавя от записващия журнал в архивен дневник и се репликира в системата в режим на готовност. Резервните бази данни са в непрекъсната фаза на възстановяване, проверка и прилагане на повторно изпълнение за поддържане на синхронизация с основната база данни. Базата данни в режим на готовност също автоматично ще се синхронизира отново, ако временно бъде изключена с основната поради прекъсване на захранването, проблеми с мрежата и т.н.
Oracle Data Guard Net Services Data Guard Redo Transport Services регулира предаването на redo от първичната база данни към резервната база данни. Процесът LGWR (запис на регистрационни файлове) изпраща данните за повторно изпълнение на един или повече процеси на мрежов сървър (LNS1, LSN2, LSN3, ...LSNn). LNS чете от буфера за повторно изпълнение в SGA (споделена глобална зона) и предава повторното изпълнение на Oracle Net Services за предаване към резервната база данни. Можете да изберете атрибутите на LGWR:синхронен (LogXptMode ='SYNC') или асинхронен режим (LogXptMode ='ASYNC'). С такава архитектура е възможно да се доставят данните за повторно изпълнение в няколко резервни бази данни или да се използват с Oracle RAC (Real Application Cluster). Процесът на отдалечен файлов сървър (RFS) получава повторното изпълнение от LNS и го записва в обикновен файл, наречен регистрационен файл в режим на готовност (SRL).
Има два основни типа Oracle Data Guard. Прилагат се физически с повторно изпълнение и логически резервни бази данни с SQL.
Архитектура за логическа репликация на Oracle Dataguard Прилагането на SQL изисква повече обработка, отколкото прилагането на повторение, процесът първо чете SRL и „пробива“ повторното изпълнение, като го преобразува в записи за логически промени и след това изгражда SQL транзакции, преди да приложи SQL към резервната база данни. Има повече движещи се части, така че изисква повече процесор, памет и I/O, след което се прилага повторно.
Основното предимство на „SQL application“ е, че базата данни е отворена за четене и запис, докато процесът на прилагане е активен.
Можете дори да създавате изгледи и локални индекси. Това го прави идеален за инструменти за отчитане. Резервната база данни не трябва да е едно към едно копие на основната ви база данни и следователно може да не е най-добрият кандидат за целите на DR.
Основните характеристики на това решение са:
- База данни в режим на готовност, която се отваря за четене-запис, докато SQL прилагането е активно
- Прилага се възможно заключване за промяна на данните, които се поддържат от SQL
- Може да изпълнява непрекъснати надстройки на база данни
Има недостатъци. Oracle използва допълнително регистриране с първичен ключ или уникално ограничение/индекс, за да разпознае логически модифициран ред в логическата резервна база данни. Когато е активирано допълнителното регистриране на първичен ключ за цялата база данни и уникално ограничение/индекс, всеки оператор UPDATE също записва стойностите на колоните, необходими в регистъра за повторно изпълнение, за да идентифицира уникално модифицирания ред в логическата резервна база данни. Oracle Data Guard поддържа верижна репликация, която тук се нарича „каскадна“, но не е типична поради сложността на настройката.
Oracle препоръчва да добавите първичен ключ или ненулев уникален индекс към таблици в първичната база данни, когато е възможно, за да гарантирате, че SQL Apply може ефективно да прилага актуализации на данните за повторно изпълнение към логическата резервна база данни. Това означава, че не работи при никакви настройки, може да се наложи да промените приложението си.
Архитектура на Oracle Golden Gate – как работи
С Data Guard, когато блоковете се променят в базата данни, записи се добавят към дневника за повторно изпълнение. След това въз основа на режима на репликация, който изпълнявате, тези регистрационни записи или ще бъдат незабавно копирани в режим на готовност или ще бъдат извлечени за SQL команди и приложени. Golden Gate работи по различен начин.
Golden Gate репликира промените само след извършване на транзакцията, така че ако имате продължителна транзакция, може да отнеме известно време, за да се репликира. „Процесът на извличане“ на Golden Gate запазва транзакционните промени в паметта.
Друга голяма разлика е, че Oracle Golden Gate позволява обмен и манипулиране на данни на ниво транзакция между множество хетерогенни платформи. Вие не сте ограничени само до базата данни на Oracle. Той ви дава гъвкавостта да извличате и репликирате избрани записи с данни, транзакционни промени и промени в DDL (език за дефиниране на данни) в различни топологии.
Архитектура на Oracle Golden Gate Типичният поток на Golden Gate показва нови и променени данни от базата данни, които се улавят от изходната база данни. Заснетите данни се записват във файл, наречен изходна пътека. След това следата се чете от помпа за данни, изпраща се през мрежата и се записва в отдалечен файл следа от процеса Collector. Функцията за доставка чете отдалечената следа и актуализира целевата база данни. Всеки от компонентите се управлява от Мениджърския процес.
Логическа репликация на MySQL – Как работи
Репликацията в MySQL съществува от дълго време и се развива през годините. Има различни начини за активиране на репликация на MySQL, включително групова репликация, клъстери Galera, асинхронен "Master to Slave". За да сравним архитектурата на Oracle и MySQL, ще се съсредоточим върху форматите за репликация, тъй като това е основата за всички различни типове репликация.
На първо място, различните формати за репликация съответстват на двоичния формат за регистриране, посочен в конфигурационния файл my.cnf. Независимо от формата, журналите винаги се съхраняват в двоичен начин, не могат да се видят с обикновен редактор. Има три типа формат:базиран на редове, базиран на изрази и смесен. Смесена е комбинацията от първите две. Ще разгледаме изявлението и на базата на редове.
Основано на изявление – в този случай това са писмените запитвания. Не всички изрази, които модифицират данни (като изрази INSERT DELETE, UPDATE и REPLACE), могат да бъдат репликирани чрез репликация, базирана на изрази. LOAD_FILE(), UUID(), UUID_SHORT(), USER(), FOUND_ROWS() и т.н. няма да бъдат репликирани.
На базата на ред – в този случай това са промени в записи. Всички промени могат да бъдат репликирани. Това е най-сигурната форма на репликация. От 5.7.7 това е опцията по подразбиране.
Сега нека да разгледаме какво се случва под капака, когато репликацията е активирана.
Архитектура за репликация на MySQL На първо място, главната база данни записва промени във файл, наречен двоичен дневник или binlog. Записването в двоичен журнал обикновено е лека дейност, тъй като записите са буферирани и последователни. Двоичният регистрационен файл съхранява данни, които подчинено устройство за репликация ще обработва по-късно, основната дейност не зависи от тях. Когато репликацията започне, mysql ще задейства три нишки. Един на господаря, две на роба. Главният има нишка, наречена дъмп нишка, която чете двоичния дневник на главния и го доставя на подчинения.
На подчинения процес, наречен IO нишка, се свързва с главния, чете двоични регистрационни събития от главния, когато постъпят и ги копира в локален лог файл, наречен регистрационен файл на реле. Вторият подчинен процес – SQL нишка – чете събития от регистрационен файл на релето, съхраняван локално на подчинения за репликация, и след това ги използва.
MySQL поддържа верижна репликация, която е много лесна за настройка. Подчинените, които също са главни, трябва да работят с параметри --log-bin и --log-slave-update.
За да проверите състоянието на репликацията и да получите информация за нишките, изпълнявате на подчинения:
MariaDB [(none)]> show slave status\G
*************************** 1. row ***************************
Slave_IO_State: Waiting for master to send event
Master_Host: master
Master_User: rpl_user
Master_Port: 3306
Connect_Retry: 10
Master_Log_File: binlog.000005
Read_Master_Log_Pos: 339
Relay_Log_File: relay-bin.000002
Relay_Log_Pos: 635
Relay_Master_Log_File: binlog.000005
Slave_IO_Running: Yes
Slave_SQL_Running: Yes
Replicate_Do_DB:
Replicate_Ignore_DB:
Replicate_Do_Table:
Replicate_Ignore_Table:
Replicate_Wild_Do_Table:
Replicate_Wild_Ignore_Table:
Last_Errno: 0
Last_Error:
Skip_Counter: 0
Exec_Master_Log_Pos: 339
Relay_Log_Space: 938
Until_Condition: None
Until_Log_File:
Until_Log_Pos: 0
Master_SSL_Allowed: No
Master_SSL_CA_File:
Master_SSL_CA_Path:
Master_SSL_Cert:
Master_SSL_Cipher:
Master_SSL_Key:
Seconds_Behind_Master: 0
Master_SSL_Verify_Server_Cert: No
Last_IO_Errno: 0
Last_IO_Error:
Last_SQL_Errno: 0
Last_SQL_Error:
Replicate_Ignore_Server_Ids:
Master_Server_Id: 1
Master_SSL_Crl:
Master_SSL_Crlpath:
Using_Gtid: Current_Pos
Gtid_IO_Pos: 0-1-8
Replicate_Do_Domain_Ids:
Replicate_Ignore_Domain_Ids:
Parallel_Mode: conservative
SQL_Delay: 0
SQL_Remaining_Delay: NULL
Slave_SQL_Running_State: Slave has read all relay log; waiting for the slave I/O thread to update it
1 row in set (0.00 sec)Настройване на логическа репликация на Data Guard в Oracle
-
Създайте физическа база данни в режим на готовност
За да създадете логическа резервна база данни, първо създавате физическа база данни в режим на готовност и след това я прехвърляте към база данни в логическа готовност.
-
Спри, повтори прилагането на физическата резервна база данни
Спирането на Повторно прилагане е необходимо, за да избегнете прилагането на промените.
SQL> ALTER DATABASE RECOVER MANAGED STANDBY DATABASE CANCEL; -
Подгответе основната база данни за поддръжка на логическа резервна база данни
Променете атрибута VALID_FOR в оригиналния LOG_ARCHIVE_DEST_1 и добавете LOG_ARCHIVE_DEST_3 за логическа база данни.
LOG_ARCHIVE_DEST_1= 'LOCATION=/arch1/severalnines/ VALID_FOR=(ONLINE_LOGFILES,ALL_ROLES) DB_UNIQUE_NAME=severalnines' LOG_ARCHIVE_DEST_3= 'LOCATION=/arch2/severalnines/ VALID_FOR=(STANDBY_LOGFILES,STANDBY_ROLE) DB_UNIQUE_NAME=severalnines' LOG_ARCHIVE_DEST_STATE_3=ENABLEСъздайте речник в данните за повторение
SQL> EXECUTE DBMS_LOGSTDBY.BUILD; -
Преобразуване в логическа база данни в режим на готовност
За да продължите да прилагате данни за повторно изпълнение към физическата резервна база данни, докато не е готова за конвертиране в логическа база данни в режим на готовност, издайте следния SQL оператор:
SQL> ALTER DATABASE RECOVER TO LOGICAL STANDBY db_name; -
Настройте параметрите за инициализация за логическата резервна база данни
LOG_ARCHIVE_DEST_1= 'LOCATION=/arch1/severalnines_remote/ VALID_FOR=(ONLINE_LOGFILES,ALL_ROLES) DB_UNIQUE_NAME=severalnines_remote' LOG_ARCHIVE_DEST_2= 'SERVICE=severalnines ASYNC VALID_FOR=(ONLINE_LOGFILES,PRIMARY_ROLE) DB_UNIQUE_NAME=severalnines' LOG_ARCHIVE_DEST_3= 'LOCATION=/arch2/severalnines_remote/ VALID_FOR=(STANDBY_LOGFILES,STANDBY_ROLE) DB_UNIQUE_NAME=severalnines_remote' LOG_ARCHIVE_DEST_STATE_1=ENABLE LOG_ARCHIVE_DEST_STATE_2=ENABLE LOG_ARCHIVE_DEST_STATE_3=ENABLE -
Отворете логическата резервна база данни
SQL> ALTER DATABASE OPEN RESETLOGS;Проверете дали логическата резервна база данни работи правилно
v$data_guard_stats изглед
SQL> COL NAME FORMAT A20 SQL> COL VALUE FORMAT A12 SQL> COL UNIT FORMAT A30 SQL> SELECT NAME, VALUE, UNIT FROM V$Data_Guard_STATS; NAME VALUE UNIT -------------------- ------------ ------------------------------ apply finish time +00 00:00:00 day(2) to second(1) interval apply lag +00 00:00:00 day(2) to second(0) interval transport lag +00 00:00:00 day(2) to second(0) intervalv$logstdby_process изглед
SQL> COLUMN SERIAL# FORMAT 9999 SQL> COLUMN SID FORMAT 9999 SQL> SELECT SID, SERIAL#, SPID, TYPE, HIGH_SCN FROM V$LOGSTDBY_PROCESS; SID SERIAL# SPID TYPE HIGH_SCN ----- ------- ----------- ---------------- ---------- 48 6 11074 COORDINATOR 7178242899 56 56 10858 READER 7178243497 46 1 10860 BUILDER 7178242901 45 1 10862 PREPARER 7178243295 37 1 10864 ANALYZER 7178242900 36 1 10866 APPLIER 7178239467 35 3 10868 APPLIER 7178239463 34 7 10870 APPLIER 7178239461 33 1 10872 APPLIER 7178239472 9 rows selected.
Това са необходимите стъпки за създаване на логическа репликация на Oracle Data Guard. Действията ще бъдат малко по-различни, ако изпълните тази операция с набор за съвместимост, който не е по подразбиране, или бази данни, работещи в Oracle RAC среда.
Настройване на MySQL репликация
-
Конфигуриране на главната база данни. Задайте уникален server_id, посочете различни регистрационни файлове за репликация –log-basename (MariaDB) , активирайте двоичен дневник. Променете my.cnf файл с информация по-долу.
log-bin server_id=1 log-basename=master1Влезте в главната база данни и предоставете на потребителя за репликация достъп до основните данни.
GRANT REPLICATION SLAVE ON *.* TO replication_user -
Стартирайте и двата сървъра с активирани GTID.
gtid_mode=ON enforce-gtid-consistency=true -
Конфигурирайте подчинения да използва автоматично позициониране, базирано на GTID.
mysql> CHANGE MASTER TO > MASTER_HOST = host, > MASTER_PORT = port, > MASTER_USER = replication_user, > MASTER_PASSWORD = password, > MASTER_AUTO_POSITION = 1; -
Ако искате да добавите подчинен към главен с данни, тогава трябва да направите резервно копие и да го възстановите на подчинен сървър.
mysqldump --all-databases --single-transaction --triggers --routines --host=127.0.0.1 --user=root --password=rootpassword > dump_replication.sqlВлезте в подчинената база данни и изпълнете:
slave> tee dump_replication_insert.log slave> source dump_replication.sql slave> CHANGE MASTER TO MASTER_HOST="host", MASTER_USER=" replication_user ", MASTER_PASSWORD="password ", MASTER_PORT=port, MASTER_AUTO_POSITION = 1;
