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により
高可用性を実現する方法と、それにより得られた
成果について、事例を交えて説明させて頂きます。
3

アジェンダ
1. 高可用性を導入したシステムの紹介
2. Data GuardによるDBのBCP
3. 自動フェイルオーバーの仕組み
4. アプリケーション側の追従
5. 導入後のDBシステム全体の可用性
4

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

Yahoo!ニューストピックスシステムの概要
6
Oracle
11g
編集部 (入稿者) ユーザ
入稿ツール
ジェネレータ solr
表示系
※詳細は省略した概要図です
1. 編集者がツールから入稿
2. ツールからOracleへ書き込み
3. ジェネレータがOracleのデータを元にデータ生成
4. 表示系がsolrのデータを元にページを生成

Oracle DBの利用内容
• Yahoo!ニューストピックスのすべてのデータ
を保持
• マスタデータの役割
• 高頻度の読み込みが必要なため、実際に表示に
利用する際はsolrを利用
7

DB停止による影響
• トピックスのPVは月間100億PVを超える
• そのトピックスのマスタデータを担っている
• DBの書き込み・参照が出来なくなると、トピッ
クスの更新や閲覧が出来なくなる事につながる
• ユーザへ与える影響は非常に大きい
 ただし、実際には障害・災害に備え、Oracleがたとえ停止した
際にでも必要な更新・閲覧ができるようYahoo!ニュースは備え
ている
8

自動フェイルオーバー導入の経緯
• 手動でのフェイルオーバーでは、切り替え完了
までの間、サービスの提供を止めてしまう危険
性があった
• DB担当者のアラート検知
• DB側の設定
• DB担当者とサービス担当者の連絡
• クライアント側の設定変更
 Yahoo!ニューストピックスは常にサービスを提供し続けられ
る必要がある
9

２．Data GuardによるDBのBCP
10

Data Guardとは
• Oracle Databaseのレプリケーション機能
• １つ以上のStandby DBを構成することが可能
• リアルタイムなデータ連携も可能
• データ保護、災害時のリカバリに適している
11
Primary
DB
Standby
DB
Standby
DB
Standby
DB

Data Files
Data Guard によるデータ転送
• Primary DBからRedoログが転送される
• Standby Redoログからデータファイルへのリ
カバリが行われる
12
Standby
Redo
Redo
Data Files
DB
Instance
DB
Instance
Primary DB Standby DB
Redo転送
リカバリ
同じデータ

Data Guard の保護モード
13
モード名
Commit時の
Standby Redoへの書込み
Standby DB障害時の
Primary DBの挙動
最大保護モード完全同期停止される
最大可用性モード完全同期稼動が続く
最大パフォーマンスモード非同期稼動が続く
データの保護レベルの設定が可能
Standby
Redo
Data Files
DB
Instance
Primary DB Standby DBRedo転送
リカバリ

Data Guard の保護モード
14
モード名
Commit時の
Standby Redoへの書込み
Standby DB障害時の
Primary DBの挙動
最大保護モード完全同期停止される
最大可用性モード完全同期稼動が続く
最大パフォーマンスモード非同期稼動が続く
データの保護レベルの設定が可能
Standby
Redo
Data Files
DB
Instance
Primary DB Standby DBRedo転送
リカバリ
採用

Data Guard フェイルオーバーの概要
• Standby DBをPrimary DBへ変更して利用可能
• Standby Redoの更新ログは全てリカバリ可能
• 最大可用性モードであればデータロスト無し
15
Data Files
Standby
Redo
Redo
Data Files
DB
Instance
DB
Instance
リカバリ
Redo転送

Data Guard フェイルオーバーの概要
• Standby DBをPrimary DBへ変更して利用可能
• Standby Redoの更新ログは全てリカバリ可能
• 最大可用性モードであればデータロスト無し
16
Data Files
Standby
Redo
Redo
Data Files
DB
Instance
DB
Instance
リカバリ
DOWN
【対応ステップの概要】
１．リカバリ状況の確認
２．Primary ロールへ変更
３．Databaseをオープン

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

Data Guard Brokerの導入が必要
• Data Guard Brokerとは
• Data Guardの管理機能
• 複数のStandby DBを一元管理可能
• Data Guardのオペレーションを簡略化
• 専用のCUI(DGMGRL)、又はOEMから操作可能
• SQL*Plusで行うよりオペレーションが容易
• 自動フェイルオーバー機能
• 前述のフェイルオーバー処理を自動化可能
• 障害時に必要とされる様々な構成変更が自動化
18

フェイルオーバーを自動化する仕組み
• Observerを導入する事で可能
• Primary DBを死活監視
• 障害検知時にStandby DBへフェイルオーバー命令
• Standby DBが自動でOpenされ、使用可能となる
19
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サーバと合わせる必要がある
20

導入フロー（Observerの構築）
• Observerサーバのセットアップ
• Primary、Standbyとは別サーバを準備
可用性を考慮した構成のサーバが望ましい
• OS仮想化
– Oralce VM
– KVM
• Grid Infrastructureへのリソース登録
• Etc…
• Oracle Full Clientをインストール
PSRレベルでDatabaseサーバと合わせる必要がある
21
弊社での構成

導入フロー（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の双方を登録
22

導入フロー（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;
23

導入フロー（Data Guard構築その３）
• 構成を有効化
DGMGRL> enable configuration;
Brokerにより、Data Guardに必要な設定が、
データベースに反映されます。
これで、Data Guardは完成です。
24

導入フロー自動フェイルオーバー設定
• フェイルオーバー先を設定
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
25

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

アプリケーション追従の問題点
• DBが自動でフェイルオーバーしても、アプリ
ケーションのセッションがStandby DBに切換
わらなくては意味が無い
• 自動フェイルオーバー時に、アプリケーション
のセッションをどうやってStandby DBに切り
替えるか？
• アプリケーションの修整は最小限に留めたい
27

TAFの利用
• TAF(透過的接続フェイルオーバー)
• セッションが切れた際に自動で再接続を行う
• この機能の応用することを検討
28
Local ListenerLocal ListenerLocal 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されていない為、接続不能。
31
Primary DB
(open)
Client Server
Standby DB
(mount)

セッションの動作(フェイルオーバー時)
• TAFの接続リトライでStandbyに接続される
• クライアントにエラーは返らない
※但し、未完了トランザクションはエラーとなる。
32
Primary DB
(open)
Client Server
Standby DB
(open)
DOWN

セッションの動作(フェイルオーバー後)
• Standby DBに接続される。
• 旧Primary DBは障害復旧後もopenされない。
２重更新防止の為、Brokerがopenを阻む。
33
Primary DB
(open)
Client Server
Standby DB
(open)
DOWN

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

拠点内での可用性
• 障害ポイントを冗長化している
• DB node
Oracle RAC
• Storage
ASM
• Network
• Bonding
• Multipath
拠点内でも、
高い可用性を実現
35
Oracle ASM
RAC DB
DB
Instance
DB
Instance
DB
Instance
Storage 3 Storage 2 Storage 1
DB node 1DB node 3 DB node 2
Core Switch

DBシステム全体の可用性
• 前述のDBシステムを、東西２拠点に構築
• Primaryとは別サイトにObserverを構築
• TAFによるDB接続でフェイルオーバーを追従
36
西東
Standby
DB
Primary
DB
Observer
Application Application
TAFによるDB接続
Data Guard
死活監視

得られた成果
• Yahoo!ニューストピックスの可用性向上
• DBに自動フェイルオーバーを導入
拠点レベルの災害を考慮したシステム構成となった
• アプリケーション側の追従も実現
TAFの機能で、Standby DBへ自動で接続が切換わる
• 導入時のアプリケーションの変更点は１つだけ
• 接続文字列の変更のみ
Oracle Data Guardを活用する事で、
システムに高い可用性を実現することが出来た。
37

Oracle Data Guard による高可用性

Recommended

Recommended

More Related Content

What's hot

What's hot (20)

Viewers also liked

Viewers also liked (8)

Similar to Oracle Data Guard による高可用性

Similar to Oracle Data Guard による高可用性 (20)

More from Yahoo!デベロッパーネットワーク

More from Yahoo!デベロッパーネットワーク (20)

Recently uploaded

Recently uploaded (8)

Oracle Data Guard による高可用性