Adg oracle что это
Целью данной работы ставилось построение демо стенда для изучения возможностей Oracle Data Guard из узлов Oracle RAC 12.1.0.2.0.
Так как под рукой у меня не нашлось сервера, на котором я бы мог разместить все необходимые мне виртуальные машины (7 штук), то строить будем с использованием офисных PC.
- 3 PC с такими характеристиками: CPU i5, 16 GB RAM
- Обычная офисная сеть 1Gbit/s
На третьем PC разместится одна виртуалка управления с Oracle Enterprise Manager Cloud Control 12c Release 5 (12.1.0.5). Насчет EM — дальше я о нем упоминать не буду ввиду того, что это отдельная тема в данном случае больше связанная не с построением стенда Data Guard, а с его использованием.
Необходимое программное обеспечение Oracle скачиваем с их сайта, а в качестве основной операционной системы я выбрал Fedora 22 с qemu-kvm + libvirt + openvswitch. В качестве гостевой ОС используем Oracle Linux 6.6.
Подготовка Fedora для хостинга виртуальных машин
Распределим IP адреса следующим образом:
Избавляемся от GNOME на каждой из персоналок:
Сконфигурируем HugeMem для виртуалок из расчета 4300M на каждую.
Кластерам нужна синхронизация времени, поэтому на prmy конфигурируем chronyd:
На prmy конфигурируем DHCP сервер для раздачи IP адресов виртуалкам:
В стандартный /etc/named.conf добавим следующие стрчки:
У нас будет свои DHCP и DNS сервера и чтобы не мешать остальной офисной сети мы сконфигурируем для работы стенда свои подсети в отдельных VLAN.
Устанавливаем Open vSwitch:
Создаем отдельный свич для public сети кластера:
Вместе с мостом создается внутренний порт и на нем внутренний интерфейс по имени совпадающем с имением моста ovsbr0. Этот интерфейс будет получать IP адрес с офисного DHCP через физический интерфейс enp3s0.
В свою очередь физический интерфейс enp3s0 подключим к этому мосту:
Конфигурируем порт (VLAN 100) и интерфейс на Open vSwitch для public сети кластеров. Через него будем раздавать IP адреса, DNS и NTP для вируалок кластеров и EM 12c.
Конфигурируем отдельный свич, порт (VLAN 101) и интерфейс на Open vSwitch для первого inetrconnect'а кластера.
Конфигурируем отдельный свич, порт (VLAN 102) и интерфейс на Open vSwitch для второго inetrconnect'а кластеров.
Конфигурируем отдельный свич, порт (VLAN 103) и интерфейс на Open vSwitch для трафика Data Guard.
Создаем такие же определения интерфейсов на sby меняя HWADDR на актуальные и последнюю цифру в IP адресах для sby на 2.
Свичи iconn1, iconn2 и dg0 получились у нас изолированными и их трафик не выходит наружу. Для того чтобы виртуальные машины на prmy могли обмениваться данными по всем внутренним сетям с виртуальными машинами на sby и наоборот, мы подключим эти свичи к ovsbr0, который имеет внешний физический порт.
Реализуем это соединением всех свичей «паровозиком» при помощи Patch портов на свичах.
Определения следующих интерфейсов идентичны на prmy и sby:
Теперь перезагружаем prmy и sby.
Проверяем получившуюся конфигурацию openvswitch:
Конфигурация должна быть одинаковой на всех компьютерах.
Проверяем IP адреса:
Проверяем что ping есть на все адреса.
Создание виртуальных машин
Удаляем default сеть libvirt:
Создаем свои определения сетей:
Создаем диски для prmy1:
Заставить правильно работать qemu+kvm с общими дисками в формате qcow2 мне не удалось, поэтому общие диски создаем в формате raw.
Берем дистрибутив Oracle Linux 6.6 64bit и кладем его на место:
Конфигурируем NFS сервер:
В /stage скачиваем дистрибутивы Grid Infrastructure, Oracle Database 12.1.0.2 и распаковываем их.
Создаем определение виртуальной машины prmy1:
Запускаем Virtual Machine Manager и инсталлируем операционную систему любым удобным для вас способом. Сетевые интерфейсы должны получить свои IP адреса с нашего DHCP. 200MB отдаем для /boot, 8GB для swap и остальное для /. В качестве файловой системы для / и /boot используем, например ext3.
В состав пакетов для установки включим группы пакетов:
Конфигурирование Oracle Linux 6
Подключаемся к созданной виртуалке и конфигурируем ее:
Избавляемся от GNOME:
Избавляемся от вопросов при удалении файла пользователем root:
Избавляемся от запуска ненужных сервисов типа cups и прочих командой chkconfig:
Сервисы ntpd и nscd наоборот включаем:
У меня после перезагрузки получилось следующее:
eth0,eth3 — public eth1, eth2 — interconnect
Создаем группы для Oracle:
Включаем пользователя oracle в группы dba, oper и asmdba
Создаем пользователя grid:
Для удобства будем отображать имя экземпляра Oracle в подсказке bash:
Создаем раздел и файловую систему на диске предназначенном для установки софта Oracle.
Должно получиться так:
Монтировать разделы я хочу не по uuid, а по LABEL:
Нарезаем разделы для ASM дисков, у меня получилось в итоге так:
С сайта Oracle скачиваем пакет oracleasmlib-2.0.4-1.el6.x86_64 помещаем на prmy в /stage и устанавливаем его:
Создаем ASM диски:
На этом конфигурирование виртуалки можно считать законченным, теперь выключаем ее приступаем к ее клонированию. Но перед этим для облегчения клонирования скопируем с нее файлы, которые будут разными в каждой виртуалке.
Клонирование виртуальных машин
Копируем общие диски на sby:
Создаем каталоги для виртуалок:
Копируем наши «эталонные» образы system.qcow и u01.qcow2 на sby.
Клонируем виртуальный диск system.qcow2 на prmy:
Диск u01.qcow2 просто копируем:
Готовим файлы на замену в виртуалках:
Туда же копируем определение виртуальной машины prmy1:
Копируем их в образ виртуальной машины prmy2:
Редактируем определение виртуалной машины prmy2.
меняем имена:
меняем mac адреса:
удаляем IDE контроллер:
И создаем виртуальную машину prmy2:
Продолжаем в том же духе с prmy3.
Имена меняем командой:
Mac адреса соответственно:
Запускаем виртуальные машины:
Подключаемся к ним проверяем что имя у них правильное, соседок по сети, DNS и NTP сервера они видит, диски на месте:
Их тоже стартуем:
Инсталляция Grid Infrastructure
Процесс довольно длинный и скучный.
Инсталлируем Grid Infrastructure на prmy:
Flex Cluster нам не нужен.
Сконфигурируем GNS на домене, указанном в DNS при делегировании зоны.
Сконфигурируем Flex ASM, хотя он тут по большому счету не нужен. Впрочем это же стенд для изучения возможностей и можно ограничить количество узлов на которых стартует ASM двумя. При использовании стандартного ASM можно было сэкономить по памяти — его минимальные требования 300M вместо 1G у Flex ASM.
Берем первые 8 дисков
Если сделали вся как у меня, то проверки и инсталляция должна пройти без замечаний.
После окончания инсталляции выгрузим данные GNS для подключения клиента:
GNS будет в одном экземпляре. Резервный кластер будет использовать GNS основного.
Инсталляция Grid Infrastructure на sby похожа на то что мы уже делали за исключением имен узлов и GNS.
Если бы мы выбрали инсталляцию Flex Cluster, то не смогли бы использовать GNS соседнего кластера.
Создание дополнительных дисковых групп ASM
Нам понадобятся дополнительные дисковые группы на обоих кластерах:
FRA — Fast Recovery Area
ACFS — для общего Oracle Home Oracle Database.
Под каждую дисковую группу берем по 4 оставшихся диска, redundancy external.
На ACFS создаем том и файловую систему acfs и туда будем инсталлировать программное обеспечение Oracle Database. Проблема непрерывности обслуживания при установке патчей и апгрейах нас не очень волнует — на этом стенде вряд ли будет больше одного пользователя. Зато немного быстрее пройдет инсталляция софта и чуть проще будет конфигурировать Data Duard.
Создаем точку монтирования acfs:
Других версий программного обеспечения у нас не будет, поэтому меняем версию совместимости compatible.rdbms и compatible.asm группы DATA на 12.1.0.2.0.
FRA также создаем с compatible.rdbms и compatible.asm 12.1.0.2.0.
На ACFS дополнительно ставим compatible.advm= 12.1.0.2.0.
Нас попросят выполнить скрипт от пользователя root:
Аналогично конфигурируем дисковые группы на кластере sby.
Инсталляция программного обеспечения Oracle Database
Инсталлируем программное обеспечение Oracle Database. Саму базу будем создавать отдельно при помощи dbca. Устанавливаем на все 3 узла кластера.
При проверке он почему-то не видит установленного в нужное ему значения параметра hard memlock=3828161. Создает fixup скрипт, а при его выполнении переустанавливает параметр в то же значение, но все равно на этот параметр обижается.
Короче, смело это игнорируем.
Аналогично устанавливаем софт на кластер sby.
После после завершения инсталляции на sby запускаем следующую команду:
Иначе наша stanby БД не получит доступа к файлам на ASM.
Создание основной кластерной базы данных
Базу данных создать можно и policy или administrator managed. В любом случае для этой БД задействуем только 2 узла кластера. Третий оставим для Far Sync.
Я создавал administrator managed базу данных:
Конфигурирование Oracle Net для Data Guard
Конфигурируем основной кластер. Сначала задействуем оставшуюся неиспользованной сеть 192.168.103.0/24 для Data Guard.
Проверяем те сети, что уже сконфигурированы:
Дальше я буду делать вторую public dhcp сеть, хотя делать этого не стоит даже на стенде, а в документации на команду srvctl add network об этом прямо сказано:
Oracle only supports DHCP-assigned networks for the default network, not for subsequent networks.
Так что в команде srvctl add network используйте опцию -nettype static выделяйте статические VIP адреса, ну и далее по документации.
Тем не менее такую сеть нам сделать позволят и внешне все будет какое-то время работать. Но при старте VIP адреса у меня наблюдался шторм DHCP запросов на этот адрес.
Все это не помешало мне довести создание конфигурации Data Guard до конца (VIP agent не успел своими логами запросов к DHCP переполнить файловую систему).
Следующий свободный номер сети -2, конфигурируем ее:
Добавляем VIP адреса:
Добавляем SCAN LISTENER'ы:
В отличие от тех что в public сети, эти слушают порт 12001.
Добавляем в эту сеть SCAN адрес. Назначение его такое же что и аналогичного SCAN в public сети:
Все что мы сейчас создали должно отобразиться в GNS:
Теперь создадим листенер базы данных в этой сети с названием LISTENER_DG и портом 12001.
Этот листенер предназначет исключительно для Data Guard требует дополнительного конфигурирования на каждом узле кластеров и в нем же будет прописан статический сервис для Data Guard.
Конфигурировать буду в 2 шага, сначала через netmgr для того чтобы не ошибиться в синтаксисе:
А потом еще и руками, потому что netmgr не понимает больших значений параметров *_BUF_SIZE.
Для кластера sby процедуру придется повторить:
Смотрим что получилось (выполняем команду на prmy1):
Синим цветом помечены записи GNS соответствующие адресам второй сети кластера sby.
Создаем листенер базы данных.
The Active Data Guard Option is an evolution of Data Guard technology that incorporates significant innovation (multiple patents pending) designed for a specific purpose - to improve production database performance for critical transactions. Active Data Guard enables read-only access to a physical standby database while Redo Apply is active. Queries and reports can be offloaded from the production system to a synchronized physical standby database - all queries at the standby database return up-to-date results. An Active Data Guard Option license must be purchased in addition to Oracle Enterprise Edition in order to utilize these new capabilities.
Active Data Guard and Oracle Data Guard 11g are related technologies, each having a different area of focus. Oracle Data Guard provides a comprehensive set of capabilities for data availability and protection that are included with Oracle Database Enterprise Edition.
Licensing requirements for Active Data Guard and Oracle Data Guard 11g features are summarized in the following table:
Capabilities and corresponding license requirements | Oracle Enterprise Edition 11g | Active Data Guard Option | Advanced Compression Option |
---|---|---|---|
All Data Guard 10g features | X | ||
New Data Guard 11g features (excludes Active Data Guard and Advanced Compression features) | X | ||
Real-time Query, enables a physical standby to be open read-only while Redo Apply is active | X | ||
The ability to enable RMAN block change tracking on a physical standby database | X | ||
Data Guard Redo Transport compression | X |
Additional frequently asked questions include:
Must I purchase Active Data Guard if I am not using Real-time Query or RMAN block change tracking on my standby database?
No. An Oracle Database Enterprise Edition license is the only license required to use Data Guard features other than those explicitly included with the Active Data Guard Option as described in the table above.
I am already using Data Guard 10g, do I need to purchase Active Data Guard when I upgrade to Oracle Database 11g ?
No - as long as you do not enable the Real-time Query feature or RMAN block change tracking on your physical standby database. Thus your physical standby database could be open read-only, but it cannot be applying redo at the same time. Similarly, you can perform RMAN incremental backups your physical standby, but you cannot perform fast RMAN incremental backups using RMAN block change tracking. You must only purchase the Active Data Guard Option if you wish to use either or both of these features.
Separate from Active Data Guard - Oracle states that Data Guard 11g continues to be an included feature of Oracle Enterprise Edition. What are the new Data Guard features that are included in Data Guard 11g?
Data Guard 11g has many new features that enhance its value for data protection and availability, and just as with previous Data Guard releases, these new features are included with Oracle Database Enterprise Edition at no extra charge.
I thought a Data Guard physical standby could always be opened read-only and/or used for incremental backups - why do I need the Active Data Guard Option ?
Previous capabilities did not allow Redo Apply to be active while a physical standby database was open read-only, and did not enable RMAN block change tracking on the standby database. This resulted in (a) read-only access to data that was frozen as of the time that the standby database was opened read-only, (b) failover and switchover operations that could take longer to complete due to the backlog of redo data that would need to be applied, and (c) incremental backups that could take up to 20x longer to complete - even on a database with a moderate rate of change. Previous capabilities are still included with Oracle Data Guard 11g, no additional license is required to use previous capabilities.
Why would I use Active Data Guard and not just add another node to my primary Oracle RAC cluster to enhance performance ?
Oracle RAC offers many advantages for scalability and high availability that are well understood and embraced by thousands of Oracle customers. Active Data Guard is designed to address a different requirement where customers wish to physically isolate the overhead of processing ad-hoc queries and reports from their OLTP system by using a completely independent, synchronized replica of the production database. If the customer requirement can be addressed using read-only access to an up-to-date replica of the production database, then Active Data Guard is an ideal solution.
Why would I use Active Data Guard and not simply use SQL Apply (logical standby) that is included with Data Guard 11g ?
If read-only access satisfies the requirement - Active Data Guard is a closer fit for the requirement, and therefore is much easier to implement than any other approach. Active Data Guard supports all datatypes and is very simple to implement. An Active Data Guard replica can also easily support additional uses - offloading backups from the primary database, serve as an open read-write test system during off-peak hours (Snapshot Standby), and provide an exact copy of the production database for disaster recovery - fully utilizing standby servers, storage and software while in standby role.
With the availability of Active Data Guard, what role does SQL Apply (logical standby) continue to play?
Use SQL Apply for the following requirements: (a) when you require read-write access to a synchronized standby database but do not modify primary data, (b) when you wish to add local tables to the standby database that can also be updated, or (c) when you wish to create additional indexes to optimize read performance. The ability to handle local writes makes SQL Apply better suited to packaged reporting applications that often require write access to local tables that exist only at the target database. SQL Apply also provides rolling upgrade capability for patchsets and major database releases. This rolling upgrade functionality can also be used by physical standby databases beginning with Oracle 11g using Transient Logical Standby.
My reporting application makes some temporary writes which require read-write access to the standby database, even though the writes do not modify primary data. How can I use it with Active Data Guard ?
Active Data Guard does not support any writes to the physical standby database. That said, it is possible that limited writes needed by the reporting application can be directed back to the primary database or to a local database that is on the same server as the standby database, using Oracle database links. For further details, refer to the Active Data Guard best practices paper on the MAA OTN site.
How do I collect stats from an Active Data Guard replica given that it is open read-only ?
This is described in Metalink Note 454848.1 that details installation and usage of standby statspack.
Ensure high availability, data protection, and disaster recovery for enterprise data with Oracle Active Data Guard. Survive disasters and data corruption while creating, maintaining, and managing one or more synchronized standby databases.
Active Data Guard versus storage remote mirroring
Fully integrated into the Oracle Database, Data Guard and Active Data Guard’s architectural advantages provide superior data protection and availability for the Oracle Database compared to the increased risks of storage replication techniques.
Data Guard and Active Data Guard MAA best practices
Implement Oracle Data Guard best practices to achieve minimal downtime and zero data loss for unplanned outages.
Autonomous Data Guard: Disaster recovery protection with a couple clicks in the cloud
Autonomous Data Guard provides a fully managed high-availability and disaster- recovery configuration across availability domains (ADs) with the simple click of a button or REST API call to enable it.
Вот пуля пролетела, и… ага? Recovery.
- Часть GRD таблицы с ресурсами упавшего узла «замораживается».
- Не вышедший на связь узел помечается как «пропавший», чтобы оставшиеся узлы к нему не обращались зря по interconnect.
- Узел, который первым обнаружил пропажу, начинает восстановление информации, которая обрабатывалась на исчезнувшем узле:
- Понижает темпы обслуживания собственных транзакций, бросая вычислительные ресурсы на восстановление
- Обращается к общему файловому хранилищу (datastorage), и на себе начинает применять online redo logs, принадлежавшие пропавшему узлу. С учетом порядкового номера SCN блоков, merge их с тем, что хранится в буфере, и «накатывает» (roll-forward) в своем кэше. При этом узел пропускает те устаревшие записи блоков (PI), более поздние версии которых, уже были сброшены на диск. Если у считанных блоков в кластере присутствует master соответствующего ресурса, то узел сообщает список считанных блоков, и master на этих ресурсах выставляет блокировку, чтобы узлы к ним не обращались (пока они восстанавливаются).
- После чего, вторым прочтением по redo log, учитывая уже undo записи, откатывает (roll-back) незафиксированные транзакции. Происходит это по технологии fast-recovery, т.е. откат транзакций будет производиться отдельным background процессом. Oracle вернет заблокированные незавершенными транзакциями (uncommitted) блоки в согласованное состояние (consistent), к прежним значениям, как только придет запрос на эти блоки. Либо они уже к тому времени будут восстановлены этим самым параллельным background процессом. Таким образом, уже в кластере снимаются блокировки и могут выполняться новые запросы пользователей.
- Часть таблицы GRD, принадлежавшая упавшему узлу, размораживается на восстанавливающем узле (теперь он master ресурса). Таким образом, в кластере восстанавливается состояние обрабатываемых транзакций на пропавшем узле на момент «падения».
Но пока все эти процессы происходят, нетерпеливому клиенту есть что предложить.
Режимы защиты
При использовании Oracle Data Guard для обслуживания резервных базы данных на выбор доступны три режима защиты. Эти режимы защиты являются отражением компромисса между степенью готовности и степенью производительности.
- Режим максимальной защиты. Этот режим, также называемый режимом двойной защиты от сбоев (double failure protection mode), обеспечивает наивысший уровень защиты. Он гарантирует, что в случае выхода из строя главной базы данных никакие данные утрачиваться не будут. Для обеспечения такой защиты данные повторного выполнения перед фиксацией транзакции должны обязательно записываться как в соответствующий оперативный журнал главной базы данных, так и в соответствующий оперативный журнал хотя бы одной резервной базы данных. При невозможности выполнить запись данных повторного выполнения в хотя бы один из журнальных файлов второстепенной базы данных, главная база данных будет останавливаться.
- Режим максимальной готовности. Этот режим, также называемый режимом безотлагательной защиты (instant protection mode), обеспечивает защиту от отказа главной производственной базы данных. Он гарантирует наивысший из возможных уровень защиты данных при поддержании главной базы данных в доступном состоянии. При этом режиме данные повторного выполнения с главного сервера записываются на нем асинхронно сразу же после фиксации транзакций. В случае использования этого режима возможна утрата главной базы данных, резервной базы данных или соединения между ними, но не утрата каких-либо данных. При утрате соединения с резервной базой данных главный сервер прекращает пересылать ей изменения, но все равно продолжает работать.
- Режим максимальной производительности. При отсутствии необходимости в защите с нулевой потерей данных и желании, чтобы уровень производительности главной базы данных был максимальным, следует выбирать именно этот режим. В этом режиме главная база данных не ожидает получения подтверждения от второстепенной прежде, чем фиксировать транзакции. Из-за этого, в случае выхода главной базы данных из строя, в резервной базе данных может не хватать каких-нибудь изменений, которые уже были зафиксированы в главной базе.
Как не трудно заметить, каждый режим предусматривает обеспечение либо более высокой производительности, либо более сильной защиты данных. Выбирать нужно тот, который более всего соответствует потребностям конкретной организации.
Продолжение статьи про Real Application Cluster (RAC). Окончание.
Считаем, что кластер поднялся и все закрутилось.
Active Data Guard Features
Key capabilities
Disaster recovery to multiple standby databases
Oracle Data Guard’s automation manages one or more synchronized copies of a live database—providing zero data loss in the case of an unexpected outage of the primary database.
In-memory database replication
In-memory redo replication ensures isolation from underlying corruption such as disk corruption and includes automatic comprehensive validation of replicated data blocks.
Flexible protection modes
Data Guard provides three different protection modes that allow data replication flexibility to balance data loss protection and performance.
Real-Time Query and DML Offload on Oracle Active Data Guard
Real-time query and data manipulation language uses the standby database for queries, reports, and occasional updates without impacting the primary database
Data protection
Fast-start failover (FSFO)
Fast-start failover allows the Oracle Data Guard broker to automatically failover to a standby database without the need for human intervention.
Automatic Block Repair
Provides automatic and user-transparent recovery of a corrupted database from the standby database.
Far Sync
Achieve zero data loss across any distance in the event of site failure—with no network latency.
Advanced features
Application Continuity
Masks outages from end-users and applications by recovering in-flight database transactions following recoverable outages.
Rolling database upgrades
Reduces downtime for database version upgrades without the complexity of adding extra software to the system.
Global Data Services (GDS)
GDS provides load balancing for connection requests ,distributing service management across multiple replicated databases and enables connections depending on read or read/write workload for Active Data Guard.
Oracle Sharding
Oracle Sharding maximizes the ability to horizontally partition and distribute data geographically, providing greatly enhanced scalability and fault isolation.
Пока узлы спасают друг друга… Failover.
Virtual IP (VIP) – логический сетевой адрес, назначаемый узлу на внешнем сетевом интерфейсе. Он предоставляет возможность CRS спокойно запускать, останавливать и переносить работу с этим VIP на другой узел. Listener (процесс, принимающий соединения) на каждом узле будет прослушивать свой VIP. Как только какой-то узел становится недоступным, его VIP подхватывает на себя другой узел в кластере, таким образом, временно обслуживая свои и запросы упавшего узла.
- Database VIPs: Клиент подсоединится по VIP, но уже подключится к другому узлу. Временно замещающий узел ответит “logon failed”, несмотря на то, что VIP будет active, нужный экземпляр БД за ним будет отсутствовать. И клиент тут же повторит попытку, но уже к другому экземпляру/узлу кластера из своего списка в конфигурации.
- Application VIP: то же, что и прежде. Но только теперь по этому VIP можно будет обратиться к приложению, на каком бы узле оно ни крутилось.
Если узел восстановится и выйдет в online, CRS опознает это и попросит сбросить в offline на подменяющем его узле и вернет VIP адрес обратно владельцу. VIP относится к CRS, и может не перебросится если выйдет из строя именно экземпляр БД.
Важно отметить, что при failover переносятся только запросы select, вместе и открытыми курсорами (возвращающими результат). Транзакции не переносятся (PL/SQL, temp tables, insert, update, delete), их всегда нужно будет запускать заново.
- Connect-time failover and client load-balancing
В этом случае клиент всегда случайно выбирает к какому узлу кластера подключиться из своего списка конфигурации сетевого подключения. Если узел, выполняющий запрос, выходит из строя, то по TAF клиент выбирает другой узел кластера и переподключается. - Preconnect
В этом случае, клиент всегда при установлении соединения с кластером подключается ко всем узлам, хотя запрос будет запускать только на одном экземпляре. Если же узел выходит из строя, то просто переводит запрос на другой узел. Failover происходит быстрее, но расходует ресурсы на подключение на всех узлах кластера.
Системы с высокой готовностью
Система с высокой степенью готовности будет обеспечивать практически непрерывную доступность данных при возникновении аварий практически любого рода. Главным способом для обеспечения такой высокой степени готовности является применение нескольких систем данных с разными архитектурами. Oracle предлагает в этом отношении несколько вариантов.
Технология Oracle Data Guard и резервные базы данных часто применяются для обеспечения возможности восстановления после аварий, защиты данных и высокой степени готовности. Поэтому давайте вкратце рассмотрим, как они работают.
Taking fire, need assistance! Workload distribution.
Описанное устройство Cache-fusion, предоставляет кластеру возможность самому (автоматически) реагировать на загрузку узлов. Вот как происходит workload distribution или resource remastering (перераспределение вычислительных ресурсов):
Если, скажем, через узел №1 1500 пользователей обращается к ресурсу A, и примерно в это же время 100 пользователей обращается к тому же ресурсу A через узел №2, то очевидно, что первый узел имеет большее количество запросов, и чаще будет читать с диска. Таким образом узел №1 будет определен как master для запросов к ресурсу A, и GRD будет создано и координироваться начиная с узла №1. Если узлу №2 потребуются те же самые ресурсы, то для получения доступа к ним он должен будет согласовать свои действия с GCS и GRD узла №1, для получения ресурсов через interconnect.
Если же распределение ресурсов поменяется в пользу узла №2, то процессы №2 и №1 скоординируются свои действия через interconnect, и master-ом ресурса A станет узел №2, т.к. теперь он будет чаще обращаться к диску.
Это называется родственность (affinity) ресурсов, т.е. ресурсы будут выделяться тому узлу, на котором происходит больше действий по получению и их блокированию. Политика родственности ресурсов скоординирует деятельность узлов, чтобы ресурсы более доступны были там, где это более необходимо. Вот, кратко, и весь workload distribution.
Перераспределение (remastering) также происходит, когда какой-то узел добавляется или покидает кластер. Oracle перераспределяет ресурсы по алгоритму называемому «ленивое перераспределение» (lazy remastering), т.к. Oracle почти не принимает активных действий по перераспределению ресурсов. Если какой-то узел упал, то все, что предпримет Oracle – это перекинет ресурсы, принадлежавшие обвалившемуся узлу, на какой-то один из оставшихся (менее загруженный). После стабилизации нагрузки GCS и GES заново (автоматически) перераспределят ресурсы (workload distribution) по тем позициям, где они более востребованы. Аналогичное действие происходит при добавлении узла: примерно равное количество ресурсов отделяется от действующих узлов и назначается вновь прибывшему. Потом опять произойдет workload distribution.
Как правило, для инициализации динамического перераспределения, загруженность на определенном узле должна превышать загруженность остальных в течение более 10 минут.
Minimize downtime for upgrades
Full upgrade automation with minimal downtime via rolling database version upgrades without the complexity of adding extra software to the system.
Epsilon improves availability and security with Oracle
Zero data loss at any distance
Zero data loss is achieved when utilizing Far Sync even over configurations where the primary and standby databases are distributed over long geographical distances without risking application performance.
В блогах нашего сообщества вы можете найти приемы резервного копирования позволят защитить базу данных от неожиданных отказов дисков и прочих неполадок с оборудованием. Наличие хорошо спроектированной системы с зеркальным отображением дисков или сконфигурированным массивом RAID обеспечит достаточную степень избыточности для сохранения работоспособности базы данных после обычных аварий. Однако даже самые продуманные схемы резервного копирования не могут гарантировать высокой готовности системы. Любая серьезная авария способна легко вывести информационные ресурсы организации из строя и стать причиной длительных простоев в предоставлении услуг. Для защиты от подобных событий требуется иметь в распоряжении не только обычные системы резервного копирования, но и целую стратегию по обеспечению высокой готовности.
Технология Oracle Data Guard и резервные базы данных
Функция резервных баз данных предлагается Oracle уже много лет. Технология Oracle Data Guard представляет собой уровень управления и мониторинга, посредством которого осуществляется обслуживание резервных баз данных. Резервные базы данных поддерживаются в актуальном состоянии, благодаря постоянной передаче изменений с главного сервера.
В случае аварии резервная база данных активизируется и переводится в оперативный режим для выполнения роли главной базы данных. Помимо защиты от полного разрушения главной базы данных, резервная база данных может также применяться и для генерации отчетов.
Базы данных, обслуживаемые в рамках конфигурации Oracle Data Guard, могут находиться как в одной и той же локальной сети (LAN), так и в более широкой глобальной сети (WAN). Резервные базы данных, находящиеся в локальной сети, обеспечивают возможность более быстрого восстановления после обычных неполадок, а резервные базы данных, находящиеся в глобальной сети, лучше защищают от катастрофических аварий, охватывающих весь центр данных или целые локальные сайты. Конфигурировать можно одну главную базу данных и несколько резервных. За счет выбора правильного уровня защиты при настройке резервных баз данных время простоя можно сводить до менее чем одной минуты. Ниже приведен краткий перечень тех многочисленных преимуществ, которые дает использование технологии Oracle Data Guard и резервных баз данных:
- Высокая степень готовности.
- Защита от аварий.
- Защита от физического повреждения данных.
- Защита от ошибок пользователей.
- Возможности передачи управления (failover) или переключения (switchover), которые могут применяться как для запланированного, так и незапланированного переключения производственных и резервных баз данных.
- Географическое разделение главных (первичных) и второстепенных (вторичных) серверов посредством Oracle Net.
Для оказания помощи в создании и управлении конфигурациями Oracle Data Guard компания Oracle предоставляет замечательное программное обеспечение Oracle Data Guard Broker (Брокер защиты данных Oracle). Оно способно поддерживать вплоть до десяти баз данных сразу (одну главную и девять резервных) и управлять выполнением административных операций, наподобие применения журналов, их переноса и передачи управления или переключения с главной базы данных на второстепенную. В нем предусмотрено два интерфейса: интерфейс командной строки и графический пользовательский интерфейс под названием Data Guard Manager (Диспетчер средств защиты данных).
Oracle Data Guard Broker является замечательным инструментом, поскольку автоматизирует выполнение многих задач, связанных с управлением сложными группировками резервных баз данных, а также настройку зачастую сложных сетевых аспектов, необходимых для их обслуживания.
На заметку! Технология Oracle Data Guard не предназначена для обеспечения минимального времени простоя. Она предназначения для усиления защиты данных и предоставления альтернативной базы данных во время проведения запланированного обслуживания производственной базы.
Automatic role transitions to maintain business continuity
Failover automation ensures a seamless transition from the primary database to a synchronized standby database in cases of failure, while ensuring database availability by replaying uncommitted in-flight transactions.
Data Guard use cases
Data Guard customer successes
Oracle Data Guard offers data protection and availability across data centers or the cloud.
Туда не ходи, сюда ходи… Load-balancing.
При выполнении любых операций, информацию, относящуюся к производительности запросов (наподобие «отладочной»), Oracle собирает в AWR (Automatic Workload Repository). Она хранится в tablespace SYSAUX. Сбор статистики запускается каждые 60 минут (default): I/O waits, wait events, CPU used per session, I/O rates on datafiles (к какому файлу чаще всего происходит обращение).
Необходимость в Load-balancing (распределении нагрузки) по узлам в кластере определяется по набору критериев: по числу физических подключений к узлу, по загрузке процессора (CPU), по трафику. Жаль что нельзя load-balance по среднему времени выполнения запроса на узлах, но, как правило, это некоторым образом связано с задействованными ресурсами на узлах, а следовательно оставшимися свободными ресурсам.
О Client load-balancing было немного сказано выше. Он просто позволяет клиенту подключаться к случайно выбранному узлу кластера из списка в конфигурации. Для осуществления же Server-side load-balancing отдельный процесс PMON (process monitor) собирает информацию о загрузке узлов кластера. Частота обновления этой информации зависит от загруженности кластера и может колебаться в пределе от приблизительно 1 минуты до 10 минут. На основании этой информации Listener на узле, к которому подключился клиент, будет перенаправлять его на наименее загруженный узел.
- Based on elapsed-time (CLB_GOAL_SHORT): по среднему времени выполнения запроса на узле
- Based on number of sessions (CLB_GOAL_LONG): по количеству подключений к узлу
Complete data protection and disaster recovery
Automates the management of synchronized copies of a live database and is included with Oracle Database Enterprise Edition.
Физические и логические резервные базы данных
Резервные базы данных бывают двух видов: физические и логические. Логическая база данных, несмотря на свое название, все равно является самой настоящей резервной базой данных. Обслуживание логических и физических резервных баз данных осуществляется одинаково: за счет передачи всех изменений из главной производственной базы данных резервной.
Физические резервные базы данных обновляются за счет применения принадлежащих главной базе данных архивных журналов повторного выполнения с помощью фонового процесса ARCH (процесс архивирования). Однако процесс LGWR тоже может использоваться для передачи данных журналов повторного выполнения из главной базы данных резервным. Физические резервные базы данных идентичны производственной базе. Для того чтобы соответствовать производственной базе данных, физическая резервная база данных должна подвергаться постоянному процессу восстановления.
Что касается логических резервных баз данных, то они предусматривают использование тех же самых архивных журналов для извлечения информации о транзакциях, которая применяется к ним с помощью операторов SQL.
Главное отличие между двумя этими видами резервных баз данных состоит в том, что физическую резервную базу данных нельзя использовать для генерации отчетов при выполнении для нее процедуры восстановления. К логической резервной базе данных можно постоянно получать доступ как для генерации отчетов, так и для отправки запросов, даже во время выполнения для нее процедуры восстановления. Всего в конфигурации Oracle Data Guard допускается иметь максимум девять логических и физических резервных баз данных.
И у логических, и у физических резервных баз данных имеются свои собственные преимущества и недостатки. Физическая резервная база данных является традиционным вариантом резервной базы данных Oracle и подразумевает применение журналов повторного выполнения с производственного сервера для выполнения восстановления. Никаких ограничений по данным нет — все типы DML и DDL могут передаваться механически с применением журналов повторного выполнения.
Взаимодействие узлов. Cache-fusion.
Много экземпляров БД, много дисков. Хлынули пользовательские запросы… вот они, клиенты, которых мы так ждали. =)
Самым узким местом любой БД являются дисковый ввод-вывод. Поэтому все базы данных стараются как можно реже обращаться к дискам, используя отложенную запись. В RAC все так же, как и для single-instance БД: у каждого узла в RAM располагается область SGA (System Global Area), внутри нее находится буферный кэш (database buffer cache). Все блоки, некогда прочитанные с диска, попадают в этот буфер, и хранятся там как можно дольше. Но кэш не бесконечен, поэтому, чтобы оценить важность хранимого блока, используется TCA (Touch Count Algorithm), считающий количество обращений к блокам. При первом попадании в кэш, блок размещается в его cold-end. Чем чаще к блоку обращаются, тем ближе он к hot-end. Если же блок «залежался», он постепенно утрачивает свои позиции в кэше и рискует быть замещенным другой записью. Перезапись блоков начинается с наименее используемых. Кэш узла – крайне важен для производительности узлов, поэтому для поддержания высокой производительности в кластере кэшем нужно делиться (как завещал сами-знаете-кто). Блоки, хранимые в кэше узла кластера, могут иметь роль локальных, т.е. для его собственного пользования, но некоторые уже будут иметь пометку глобальные, которыми он, поскрипев зубами дисками, будет делится с другими узлами кластера.
Технология общего кэша в кластере называется Cache-fusion (синтез кэша). CRS на каждом узле порождает синхронные процессы LMSn, общее их название как сервиса — GCS (Global Cache Service). Эти процессы копируют прочитанные на этом экземпляре блоки (глобальные) из буферного кэша к экземпляру, который за ними обратился по сети, и также отвечают за откат неподтвержденных транзакций. На одном экземпляре их может быть до 36 штук (GCS_SERVER_PROCESSES). Обычно рекомендуется по одному LMSn на два ядра, иначе они слишком сильно расходуют ресурсы. За их координацию отвечает сервис GES (Global Enqueue Service), представленный на каждом узле процессами LMON и LMD. LMON отслеживает глобальные ресурсы всего кластера, обращается за блоками к соседним узлам, управляет восстановлением GCS. Когда узел добавляется или покидает кластер, он инициирует реконфигурацию блокировок и ресурсов. LMD управляет ресурсами узла, контролирует доступ к общим блоками и очередям, отвечает за блокировки запросов к GCS и управляет обслуживанием очереди запросов LMSn. В обязанности LMD также входит устранение глобальных взаимоблокировок в рамках нескольких узлов кластера.
Таблица GRD распределена между узлами кластера. Каждый узел принимает участие в распределении ресурсов кластера, обновляя свою часть GRD. Часть таблицы GRD относится к ресурсам – объектам: таблицы, индексы и.т.п. Она постоянно синхронизируется (обновляется) между узлами.
Когда узел прочел блок данных с диска, он становится master-ом этого ресурса и делает соответствующую отметку в своей части таблицы GRD. Блок помечается как локальный, т.к. узел пока использует его в одиночку. Если же этот блок потребовался другому узлу, то процесс GCS пометит этот блок в таблице как глобальный («опубликован» для кластера) и передаст затребовавшему узлу.
DBA | location | mode | role | SCN | PI/XI |
500 | узел №3 | shared | local | 9996 | 0 |
- Data Block Address (DBA): физический адрес блока
- Location: узел на котором доступен этот блок
- Resource mode: определяется тем, кто на текущий момент является владельцем блока и какая операция к нему будет применяться
- null: узел не претендует на изменение этого блока (только select)
- shared: к блоку осуществляется защищенный множественный доступ только для чтения на нескольких узлах.
- exclusive: узел собирается изменить (или уже изменил) этот блок. Хотя одновременно в кластере могут содержаться прежние (согласованные) версии этого же блока, менять их нельзя.
- local: когда узел только прочитал блок с диска, и ни с кем им еще не делился.
- global: когда узел был изначально считан этим блоком, но после был передан запросившему его узлу в некотором режиме (mode). Теперь этот же блок может присутствовать на других узлах.
- Past Image (PI): глобальный грязный блок (старая версия, после изменения), хранящийся в кэше узла после того, как узел передал его по сети другому. Блок держится в памяти пока он или более поздняя версия не будет записана на диск, о чем оповестит GCS, когда блок будет больше не нужен.
- Current Image (XI): текущая последняя копия блока, содержащаяся в последнем узле кластера в цепочке запросов этого блока.
- как можно реже обращаться к диску, за счет активной работы с кэшем
- обеспечить consistency read (CR), согласованность по чтению, т.е. данные неподтвержденной транзакции никто никогда не увидит ни в какой (параллельной) сессии
- Read/read behavior (no transfer).
Пусть данные таблицы A первым считал узел №4. Он является master этой таблицы и отвечает за соответствующую часть в GRD. - На узел №3 пришел запрос на чтение из таблицы A. У узла №3 в кэше нет необходимого блока. Из GRD он узнает, что master таблицы A – это узел №4, и обращается к нему.
- Узел №4 просматривает GRD на наличие запрашиваемого блока. Если бы он был у него в кэше, то он просто бы передал его. Но допустим, что нужного блока не оказалось. Узел №4 отправит узлы №3 самостоятельно считать этот блок с диска.
- Узел №3 сам считывает его с диска, пока только для себя и ни с кем блоком не делится (local), но впоследствии может предоставлять к нему доступ другим узлам через посредника — master-а этой таблицы (shared).
- Узел №3 отчитывается перед master таблицы A узлом №4, и тот вносит соответствующую запись в GRD (на узле №4):
Без необходимости никаких записей на диск не происходит. Всегда копия блока хранится на узле, на котором он чаще используется. Если определенного блока пока еще нет в глобальном кэше, то при запросе master попросит соответствующий узел прочитать блок с диска и поделиться им с остальными узлами (по мере надобности).
- Участвует 2 узла: когда целевому узлу потребовался блок, который хранился в кэше master.
- Участвует 3 узла: когда master отправляет запрос промежуточному узлу, и тот передает блок востребованному в нем узлу.
Читайте также: