oracle data guard による高可用性

Oracle Data Guardによる高可用性の実現

ヤフー株式会社

宇佐美茂正

自己紹介

• 氏名：宇佐美茂正（うさみしげまさ）

• 勤務先：ヤフー株式会社

• 職種：DBA

• 業務

• DB環境構築

• DB運用業務

• SQLチューニング

• DB監査

※ Oracle関連の業務を主に担当しています

Copyright (C) 2015 Yahoo Japan Corporation. All Rights Reserved. 無断引用・転載禁止 2

セッションの概要

弊社では、先日、Yahoo!ニューストピックス

システムに対して、Oracle Data Guardによる

高可用性の導入を行いました。

このセッションでは、Oracle Data Guardにより

高可用性を実現する方法と、それにより得られた

成果について、事例を交えて説明させて頂きます。


アジェンダ

1. 高可用性を導入したシステムの紹介

2. Data GuardによるDBのBCP

3. 自動フェイルオーバーの仕組み

4. アプリケーション側の追従

5. 導入後のDBシステム全体の可用性


１．高可用性を導入したシステムの紹介


Yahoo!ニューストピックスシステムの概要


Oracle 11g

編集部 (入稿者) ユーザ

入稿ツール

ジェネレータ solr

表示系

※詳細は省略した概要図です

1. 編集者がツールから入稿

2. ツールからOracleへ書き込み

3. ジェネレータがOracleのデータを元にデータ生成

4. 表示系がsolrのデータを元にページを生成

Oracle DBの利用内容

• Yahoo!ニューストピックスのすべてのデータを保持

• マスタデータの役割

• 高頻度の読み込みが必要なため、実際に表示に利用する際はsolrを利用


DB停止による影響

• トピックスのPVは月間100億PVを超える

• そのトピックスのマスタデータを担っている

• DBの書き込み・参照が出来なくなると、トピックスの更新や閲覧が出来なくなる事につながる

• ユーザへ与える影響は非常に大きい

ただし、実際には障害・災害に備え、Oracleがたとえ停止した

際にでも必要な更新・閲覧ができるようYahoo!ニュースは備えている


自動フェイルオーバー導入の経緯

• 手動でのフェイルオーバーでは、切り替え完了までの間、サービスの提供を止めてしまう危険性があった

• DB担当者のアラート検知

• DB側の設定

• DB担当者とサービス担当者の連絡

• クライアント側の設定変更

Yahoo!ニューストピックスは常にサービスを提供し続けられる必要がある


２．Data GuardによるDBのBCP


Data Guardとは

• Oracle Databaseのレプリケーション機能

• １つ以上のStandby DBを構成することが可能

• リアルタイムなデータ連携も可能

• データ保護、災害時のリカバリに適している


Primary DB

Standby DB

Standby DB

Standby DB

Data Files

Data Guard によるデータ転送

• Primary DBからRedoログが転送される

• Standby Redoログからデータファイルへのリカバリが行われる


Standby Redo

Redo

Data Files

DB Instance

DB Instance

Primary DB Standby DB

Redo転送

リカバリ

同じデータ

Data Guard の保護モード


モード名 Commit時の Standby Redoへの書込み

Standby DB障害時の Primary DBの挙動

最大保護モード完全同期停止される

最大可用性モード完全同期稼動が続く

最大パフォーマンスモード非同期稼動が続く

データの保護レベルの設定が可能

13

Standby Redo

Data Files

DB Instance

Primary DB Standby DB Redo転送

リカバリ

Data Guard の保護モード


モード名 Commit時の Standby Redoへの書込み

Standby DB障害時の Primary DBの挙動

最大保護モード完全同期停止される

最大可用性モード完全同期稼動が続く

最大パフォーマンスモード非同期稼動が続く

データの保護レベルの設定が可能

14

Standby Redo

Data Files

DB Instance

Primary DB Standby DB Redo転送

リカバリ

採用

Data Guard フェイルオーバーの概要

• Standby DBをPrimary DBへ変更して利用可能

• Standby Redoの更新ログは全てリカバリ可能

• 最大可用性モードであればデータロスト無し


Data Files

Standby Redo

Redo

Data Files

DB Instance

DB Instance


リカバリ

Redo転送

Data Guard フェイルオーバーの概要

• Standby DBをPrimary DBへ変更して利用可能

• Standby Redoの更新ログは全てリカバリ可能

• 最大可用性モードであればデータロスト無し


Data Files

Standby Redo

Redo

Data Files

DB Instance

DB Instance


リカバリ

DOWN

【対応ステップの概要】１．リカバリ状況の確認２．Primary ロールへ変更３．Databaseをオープン

３．自動フェイルオーバーの仕組み


Data Guard Brokerの導入が必要

• Data Guard Brokerとは

• Data Guardの管理機能

• 複数のStandby DBを一元管理可能

• Data Guardのオペレーションを簡略化

• 専用のCUI(DGMGRL)、又はOEMから操作可能

• SQL*Plusで行うよりオペレーションが容易

• 自動フェイルオーバー機能

• 前述のフェイルオーバー処理を自動化可能

• 障害時に必要とされる様々な構成変更が自動化


フェイルオーバーを自動化する仕組み

• Observerを導入する事で可能

• Primary DBを死活監視

• 障害検知時にStandby DBへフェイルオーバー命令

• Standby DBが自動でOpenされ、使用可能となる


Primary Site Standby Site

Standby DB

Primary DB

Observer

死活監視フェイルオーバー

命令

導入フロー（Observerの構築）

• Observerサーバのセットアップ

• Primary、Standbyとは別サーバを準備

可用性を考慮した構成のサーバが望ましい

• OS仮想化

– Oralce VM

– KVM

• Grid Infrastructureへのリソース登録

• Etc…

• Oracle Full Clientをインストール

PSRレベルでDatabaseサーバと合わせる必要がある


導入フロー（Observerの構築）

• Observerサーバのセットアップ

• Primary、Standbyとは別サーバを準備

可用性を考慮した構成のサーバが望ましい

• OS仮想化

– Oralce VM

– KVM

• Grid Infrastructureへのリソース登録

• Etc…

• Oracle Full Clientをインストール

PSRレベルでDatabaseサーバと合わせる必要がある


弊社での構成

導入フロー（Data Guard構築その１）

• tnsnames.oraに必要情報を記載

Primary DBとStandby DBのネットサービス名を記載

Observerサーバも含めた構成内の全サーバが対象

• RMANでPrimary DBのコピーを作成 RMAN> duplicate target database for standby from active database;

Standby DBで実施

• CRSリソースへDBを登録

Primary DB、Standby DBの双方を登録


導入フロー（Data Guard構築その２）

• Data Guard Brokerへ構成登録

• Primary DBを登録

DGMGRL> create configuration ‘<Broker構成名>’

as primary database is ‘<db_unique_name(Primary)>’

connect identifier ‘<net_service_name(Primary)>’;

• Standby DBを登録

DGMGRL> add database ‘<db_unique_name(Standby)>’

as connect identifier is ‘<net_service_name(Standby)>’;

• 保護モードの設定（最大可用性モード） DGMGRL> edit configuration

set protection mode as maxavailability; Copyright (C) 2015 Yahoo Japan Corporation. All Rights Reserved. 無断引用・転載禁止

23

導入フロー（Data Guard構築その３）

• 構成を有効化 DGMGRL> enable configuration;

Brokerにより、Data Guardに必要な設定が、

データベースに反映されます。

これで、Data Guardは完成です。


導入フロー自動フェイルオーバー設定

• フェイルオーバー先を設定 DGMGRL> edit database ‘<db_unique_name(Primary)>’

set property FastStartFailoverTarget=

‘<db_unique_name(Standby)>’;

• Primary DB復旧待ち時間を設定

DGMGRL> edit configuration set property FastStartFailoverThreshold = ’XX’;

• Observerプロセスを起動

DGMGRL> enable fast_start failover;

DGMGRL> start observer


アプリケーション側の追従


アプリケーション追従の問題点

• DBが自動でフェイルオーバーしても、アプリケーションのセッションがStandby DBに切換わらなくては意味が無い

• 自動フェイルオーバー時に、アプリケーションのセッションをどうやってStandby DBに切り替えるか？

• アプリケーションの修整は最小限に留めたい


TAFの利用

• TAF(透過的接続フェイルオーバー)

• セッションが切れた際に自動で再接続を行う

• この機能の応用することを検討


Local Listener Local Listener Local Listener

Instance Node 1

Instance Node 2

Instance Node 3

Client Server

SCAN

Session Failover

DOWN

実際に採用した接続文字列 topics =

(DESCRIPTION_LIST =

(FAILOVER = on)

(LOAD_BALANCE = off)

# Primary DB

(DESCRIPTION =

(ADDRESS = (PROTOCOL = TCP)(HOST = <SCAN (Primary Site)>)(PORT = <SCAN Port>))

(CONNECT_DATA =

(SERVER = DEDICATED)

(SERVICE_NAME = sv_topics)

(FAILOVER_MODE = (TYPE = SELECT)(METHOD = BASIC)(RETRIES = 360)(DELAY = 10))

)

)

# Standby DB

(DESCRIPTION =

(ADDRESS = (PROTOCOL = TCP)(HOST = <SCAN (Standby Site)>)(PORT = <SCAN Port>))

(CONNECT_DATA =




)

)

) Copyright (C) 2015 Yahoo Japan Corporation. All Rights Reserved. 無断引用・転載禁止

29

実際に採用した接続文字列 topics =

(DESCRIPTION_LIST =

(FAILOVER = on)

(LOAD_BALANCE = off)

# Primary DB

(DESCRIPTION =

(ADDRESS = (PROTOCOL = TCP)(HOST = <SCAN (Primary Site)>)(PORT = <SCAN Port>))

(CONNECT_DATA =




)

)

# Standby DB

(DESCRIPTION =

(ADDRESS = (PROTOCOL = TCP)(HOST = <SCAN (Standby Site)>)(PORT = <SCAN Port>))

(CONNECT_DATA =




)

)

) Copyright (C) 2015 Yahoo Japan Corporation. All Rights Reserved. 無断引用・転載禁止

30

TAFの設定（FAILOVER_MODE句）

セッションの動作(通常時)

• Primary DBに接続される

• Standby DBに接続される事は無い

Standby DBはOpenされていない為、接続不能。


Primary DB (open)

Client Server

Standby DB (mount)


セッションの動作(フェイルオーバー時)

• TAFの接続リトライでStandbyに接続される

• クライアントにエラーは返らない

※但し、未完了トランザクションはエラーとなる。


Primary DB (open)

Client Server

Standby DB (open)


DOWN

セッションの動作(フェイルオーバー後)

• Standby DBに接続される。

• 旧Primary DBは障害復旧後もopenされない。

２重更新防止の為、Brokerがopenを阻む。


Primary DB (open)

Client Server

Standby DB (open)


DOWN

導入後のDBシステム全体の可用性


拠点内での可用性

• 障害ポイントを冗長化している

• DB node

Oracle RAC

• Storage

ASM

• Network

• Bonding

• Multipath

拠点内でも、

高い可用性を実現


Oracle ASM

RAC DB

DB Instance

DB Instance

DB Instance

Storage 3 Storage 2 Storage 1

DB node 1 DB node 3 DB node 2

Core Switch

DBシステム全体の可用性

• 前述のDBシステムを、東西２拠点に構築

• Primaryとは別サイトにObserverを構築

• TAFによるDB接続でフェイルオーバーを追従


西東

Standby DB

Primary DB

Observer

Application Application

TAFによるDB接続

Data Guard

死活監視

得られた成果

• Yahoo!ニューストピックスの可用性向上

• DBに自動フェイルオーバーを導入

拠点レベルの災害を考慮したシステム構成となった

• アプリケーション側の追従も実現

TAFの機能で、Standby DBへ自動で接続が切換わる

• 導入時のアプリケーションの変更点は１つだけ

• 接続文字列の変更のみ

Oracle Data Guardを活用する事で、

システムに高い可用性を実現することが出来た。


oracle data guard による高可用性

Technology