PGConf.ASIA 2018

大規模DBのバックアップ運用に向けた取り組み
Ver.2
2018/12/10(株)日立製作所 システム＆サービスビジネス統括本部
OSSソリューションセンタ
© Hitachi, Ltd. 2018. All rights reserved.

Contents
1. 本取り組みの概要
2. ストレージ機能を用いたバックアップ検証
3. BART 2.2 β版のバックアップ／リカバリ検証

4. サービス紹介© Hitachi, Ltd. 2018. All rights reserved.

1

１. 本取り組みの概要© Hitachi, Ltd. 2018. All rights reserved.

2

1-1. 取り組みの概要◼ 概要
日立内で、金融向けのシステムに対して、PostgreSQLの採用が加速している。
今回は、現在開発を行っているオンラインサービスのプロジェクトにおける事例から技術的要素をピックアップして紹介する。
PostgreSQLを採用するにあたっては、機能面はもちろんのこと、スループットやレスポンスといった性能面、リソース負荷具合、また、様々な障害パターンからの復旧、といった非機能面が要件に合致するかどうか検討、検証を行い対応してきた。
今回は、一番懸念となったバックアップ／リカバリについて紹介する。

© Hitachi, Ltd. 2018. All rights reserved.

31-2. バックアップ要件◼ 要件
今回のプロジェクトのバックアップ要件は以下の点である。
✓ バックアップは日次バックアップを行うこと✓ 日次バックアップは、月次メンテナンス日以外のサービス停止はできないため、オンライン中でのバックアップ取得であること✓ 日次バックアップ時間はなるべく短時間であること（上限は3時間以内）✓ バックアップ時のリソース利用率が閾値以内であること（オンラインへの影響度を範囲内に抑える）✓ 障害時の復旧は3時間以内のサービス再開ができること（リストア）✓ 運用作り込みによる開発スケジュールへの影響を抑える✓ ストレージは既に利用しており、本プロジェクトに利用可能© Hitachi, Ltd. 2018. All rights reserved.

41-3. バックアップ方式検討 (1/2)◼ 方式検討①（凡例 ○問題なし △課題あり ▲課題あり（高） ×問題あり）

PostgreSQLを採用するにあたり、バックアップ方式の比較を行った結果を共有する。
バックアップ方式

案1:物理バックアップ

案2:論理バックアップ

案3:物理バック
アップ＋レプリケーション

案4:物理差分バッ
クアップ

案5:ストレージ
筐体内レプリカ方法

pg_basebackup

pg_dump /pg_restore

pg_basebackup

pg_rman
BART

ShadowImage /Thin Image

バックアップ
時間△
論理バックアップより高速であるが長時間化す
る可能性あり×
論理バックアップのため低速△案1と同じだが、マスタの負荷軽減による短時間化の可能性あり▲～○○差分のため案1～3 ストレージ機能に比べ高速だが、 のため高速更新多だと悪化の可能性あり。フル
バックアップの取得が必要。

リカバリ時間△DBのファイル
コピーのためサ
イズによって長時間化

×論理バックアップからのリカバ
リのため低速△DBのファイルコ
ピーのためサイズによって長時
間化▲
フルバックアップと差分バックアップの両方のリスト
アになるため低速○ストレージ機能のため高速© Hitachi, Ltd. 2018. All rights reserved.

51-3. バックアップ方式検討 (2/2)◼ 方式検討②（凡例 ○問題なし △課題あり ▲課題あり（高） ×問題あり）

バックアップ方案1:物理バック 案2:論理バック 案3:物理バック 案4:物理差分
案5:ストレージ
PostgreSQLを採用するにあたり、バックアップ方式の比較を行った結果を共有する。
式
アップ
アップ
アップ＋レプリ バックアップ
筐体内レプリカケーション
オンラインバックアップデータの信頼性○
PostgreSQLコ
マンドで取得するため問題なし○
PostgreSQLコ
マンドで取得するため問題なし○
PostgreSQLコ
マンドで取得するため問題なし○
サポート対象のツールで取得するため問題なし※
実績なし（→検証実施）オンラインへの影響度△
I/O負荷による業務影響の可能性あり△
I/O負荷による業務影響の可能性あり○
スレーブサーバ
による取得のため影響が少ない△
I/O負荷による業務影響の可能性あり※
ストレージ機能によるため、影響が少ないはず

運用作り込みによる開発スケ
ジュールへの影響▲△追加開発に加え、 追加開発、テス
サーバ購入費・ トが必要
期間に影響あり×△
追加開発に加え、 追加開発、テス
サーバ購入費・ トが必要
期間に影響大○影響少

プロジェクトの要件から「時間」が最も重要視されるため、ストレージコピーによるバックアップがベター。
本講演では、ストレージコピーによるバックアップソリューション化に向けて実施した検証内容を報告する。
なお、BARTによるバックアップ機能についても、併せて検証した結果を報告する。
© Hitachi, Ltd. 2018. All rights reserved.

6

2. ストレージ機能を用いたバックアップ／リカバリ検証© Hitachi, Ltd. 2018. All rights reserved.

72-1. 概要
◼ 概要
バックアップ処理時間の課題解決のアプローチの一つとして、従来からあるストレージ機能を使ったバックアップがある。
他のRDBMSでは、ストレージに対してRAWで直接アクセスする方法であったが、PostgreSQLではファイルシステムが前提となるため、ファイルキャッシュが介在し、オンラ
イン中では見かけのDBの状態とディスクの状態が常時同期はしておらず、バックアップとして保証できるか漠然とした不安がある。
この不安を払しょくするため、調査・検証を実施した結果をまとめる。

ハイブリッドフラッシュアレイ

VSP Gシリーズ© Hitachi, Ltd. 2018. All rights reserved.

8

2-2. ストレージ機能の概要◼ ストレージ筐体内レプリカ機能（ShadowImage）＝フルバックアップ
・ホスト非経由で同一のサブシステム内にボリュームのレプリカを作成する機能
・上位ハード／ソフト環境を殆ど変更せず実現可能・１つのVOLに対し最大9VOLまでレプリカを作成可能（但し、レプリカ作成には同じ容量が必要）
・正ボリューム（オンライン側、以降『P-VOL』）と副ボリューム（バックアップ側、以降『SVOL』）は、物理ディスクが完全に独立しているので、性能や障害の影響はない
Unix／Winｻｰﾊﾞ

Unix／Winｻｰﾊﾞ
RAID Manager

ｵﾝﾗｲﾝ業務

レプリカ作成(max.9個)

RAID Manager

ｵﾝﾗｲﾝ業務一時停止

ｵﾝﾗｲﾝ一時停止後
VOL分割

ｵﾝﾗｲﾝ業務再開

バッチ
バックアップ

バッチ業務開始
Primary
Vol

Secondary
SecondaryVol
SecondaryVol
Vol

Primary
Vol

Secondary
Vol
Secondary
SecondaryVol
Vol

Primary
Vol

Secondary
Vol
Secondary
Secondary
Vol
Vol

ShadowImage© Hitachi, Ltd. 2018. All rights reserved.

92-2. ストレージ機能の概要

V2◼ ストレージ筐体内レプリカ機能（Thin Image）＝増分バックアップ
・同一のサブシステム内にスナップショットデータを取得する機能
・更新前のデータだけをS-VOLに退避する（最大1024個退避可能）。
そのため、P-VOLに障害が発生すると、全てのボリュームが使用不可になる。
・S-VOLは実体のない仮想ボリュームなので、ディスクアレイシステム全体で使用する
容量を低減可能・S-VOLの生成や再同期処理が瞬時に実行可能
Unix／Winｻｰﾊﾞ

バックアップ範囲

RAID Manager

ｵﾝﾗｲﾝ業務

レプリカ作成(max.1024個)

Primary
Vol

Secondary
Vol
Secondary
Vol
SecondaryVol

Thin Image

bkup1

bkup2

bkup3

current

timeline

bkup3
bkup2

bkup1
© Hitachi, Ltd. 2018. All rights reserved.

102-2. ストレージ機能の概要

V2◼ ストレージ筐体内レプリカ機能（Thin Image）の事前検証
Thin Imageを使った際にどのくらいのバックアップサイズになるのか、事前検証を実施した。
検証には、pgbenchを使用した。
(1) 更新データサイズとバックアップサイズの比較検証

1000

15

16.5

5000

73

82.4

10000

146

164.7

50000

730

823.6

[GB]

バックアップサイズ

scale pg_database_size Backup size
factor
[GB]
[GB]

1000
800
600
400
200
0
0

200

400
600
更新データサイズ

800[GB]→更新データサイズとバックアップサイズは比例しており、約1.2倍見込んでおけばよい。これによりストレージサイズ検討は、比較的に容易である。 © Hitachi, Ltd. 2018. All rights reserved.

112-2. ストレージ機能の概要

V2◼ ストレージ筐体内レプリカ機能（Thin Image）の事前検証(2) ペア数に応じたバックアップサイズの比較検証
レプリカの作成（バックアップ）とpgbench(sf=10000)を交互に実施して、1～3世代作成
した場合のバックアップサイズを測定した。以下に、イメージを図示した。

Pair
count

timeline

backupbackupcurrent
pgbenchpgbenchpgbench[GB]600

pg_database_size Backup size
[GB]
[GB]

1

146

164.7

2

292

329.5

3

438

494.2

バックアップサイズ

backup

400
200
0
0

1

2
ペア数

3

→通常、複数の増分バックアップを取得した場合は、バックアップサイズが指数的に増加する一方で、Thin Imageによる増分バックアップは、一番過去から現在までのバック
アップサイズとなった。世代管理等をしたい場合は非常に有用である。
© Hitachi, Ltd. 2018. All rights reserved.

412

2-2. ストレージ機能の概要

V2◼ ストレージ機能によるオンラインバックアップ運用
・業務運用しているバックアップには、ShadowImageによるフルバックアップを取得する
・世代管理を行うには、ShadowImageのS-VOLから、Thin Imageによる増分バックアップ（以降『3rd-VOL』）を取得する
特徴：
・業務運用しているストレージが壊れた場合でも、最新のフルバックアップからすぐに復旧可能
・世代管理数が多いシステムでも、トータルのバックアップ容量の低下ができるので、ストレー
ジサイズの低減が図れる
・Thin Imageは、ShadowImageのS-VOLからバックアップをするため、Thin Imageの負荷や障害がオンライン業務に影響することは無い。
Unix／Winｻｰﾊﾞ
RAID Manager

ｵﾝﾗｲﾝ業務

Third
Vol

Primary
Vol

SecondaryVol

ShadowImage

Third
Vol
Third
Vol

Thin Image© Hitachi, Ltd. 2018. All rights reserved.

132-3. 調査、検証◼ 検証内容ストレージ機能によるオンラインバックアップ運用を整理してきたが、次に、データ完全性が担保できるか、机上調査を行った。

机上調査の概要は以下の通り。
① ストレージ機能を使ったバックアップとリカバリ手順② ①で構築した各手順におけるデータベースの書込み処理を検討し、懸念点洗い出し

ファイルシステムが介在することにより、特に下記が重要ポイントと考える。
✓ PostgreSQLの共有バッファ、ファイルシステムのキャッシュが介在するため、見かけのDB状態とストレージの状態が異なるため、バックアップとして成立するかどうか？

✓ オンライン中バックアップを想定しており、バックアップ断面がファイルシステムとして整合性が担保できるのか？できない場合、回復できるのか？
③ トランザクションログ（WAL）の書込み処理の検討
上記で洗い出した懸念点について、実機で調査が必要なものについては実機検証を実施した。
© Hitachi, Ltd. 2018. All rights reserved.

142-4. バックアップ手順（机上検証①）

V2◼ ストレージ機能を使ったバックアップ手順
ストレージ機能を使ったバックアップを実施する場合、PostgreSQLは低レベルAPIを使用したバックアップとなる。一般的な使い方になるが、その場合の手順をまとめた。
バックアップ手順：①(2回目以降)増分バックアップ（Thin Image）②pg_start_backupの実行③syncの実行④fsfreezeによるファイルシステムへのアクセスをフリーズ⑤フルバックアップ（ShadowImage）⑥fsfreezeによるアクセスのフリーズを解除⑦pg_stop_backupの実行⑧バックアップ中のWALを退避（対応するバックアップはわかるようにしておく）© Hitachi, Ltd. 2018. All rights reserved.

15

2-5. リカバリ手順（机上検証①）

V2◼ ストレージ機能を使ったリカバリ手順
次にリカバリ手順についてもまとめた。
リカバリ手順：①リカバリしたい対象が3rd-VOLにある場合は、S-VOLにリストアする。
②ストレージバックアップからリストア
・パターン１：P-VOLにリストアする・パターン２：S-VOLをP-VOLとして利用する③リカバリ準備・リストアしたデータからpostmaster.pidを削除
・ストレージバックアップに対応した退避WALを準備
・recovery.confの設定④PostgreSQLを起動してロールフォワードを実施© Hitachi, Ltd. 2018. All rights reserved.

16

2-6. 各種操作とデータベースの状態（机上検証②）

ShadowImageを利用したバックアップでの各種操作とDBおよび各種資源の状態※オンライン中で常時DBが更新されている想定です。図中A,B,C,…は見かけ上のDB状態の違いを示したものです。
pg_stop_backup

pg_start_backup
WAL
スイッチ

見かけのDB(共有バッファ)

ファイル
キャッシュ

ディスク

CHECK
POINT

backup_label
作成

fsfreezesync

A B C D E F G H I J K L M N

ペア
分割

O

fsfreeze
解除

WAL
スイッチ

.backup
作成

時間

P Q R S T U V(継続的な)
dirtyページ
フラッシュ

D

I

D

L

I

P

S

L

次シート以降、各操作と状態での想定される懸念と検討内容を説明する© Hitachi, Ltd. 2018. All rights reserved.

172-6. 各種操作とデータベースの状態（机上検証②）(1)pg_start_backup
pg_stop_backup

pg_start_backup
WAL
スイッチ

見かけのDB(共有バッファ)
ファイル
キャッシュ
ディスク

CHECK
POINT

backup_label
作成

fsfreeze

sync

ペア
分割

A B C D E F G H I J K L M N(継続的な)
dirtyページ
フラッシュ

D

D

I

O

fsfreeze
解除.backup
作成

時間

P Q R S T U V

L
I

WAL
スイッチ

P

S

L

✓(pg_start_backup処理の)CHECKPOINTによる書込み処理
CHECKPOINTでディスク書き込みが完全に実施されるかが心配。

© Hitachi, Ltd. 2018. All rights reserved.

18

2-6. 各種操作とデータベースの状態（机上検証②）(2)fsfreeze
pg_stop_backup

pg_start_backup
WAL
スイッチ

見かけのDB(共有バッファ)
ファイル
キャッシュ
ディスク

CHECK
POINT

backup_label
作成

fsfreeze

sync

ペア
分割

A B C D E F G H I J K L M N(継続的な)
dirtyページ
フラッシュ

D

D

I

O

fsfreeze
解除.backup
作成

時間

P Q R S T U V

L
I

WAL
スイッチ

P

S

L

✓ファイルシステム、fsfreezeの信頼性
ファイルシステムそのものの信頼性が大丈夫かが心配。
fsfreezeはRHEL6.5から正式サポートで比較的歴史が浅く、信頼性が心配。
✓fsfreeze中のファイルシステムの状態
日立Linux有識者によれば、fsfreezeは排他制御でI/Oのシステムコールをロックしているだけであり、ファイルシステムとして整合性を保証するものではなく、不完全な状態があり得る。（マシンダウンと同じ状態）
バックアップのベースとして成立するかが心配。
19© Hitachi, Ltd. 2018. All rights reserved.

2-6. 各種操作とデータベースの状態（机上検証②）(3)pg_stop_backup
pg_stop_backup

pg_start_backup
WAL
スイッチ

見かけのDB(共有バッファ)
ファイル
キャッシュ
ディスク

CHECK
POINT

backup_label
作成

fsfreeze

sync

ペア
分割

A B C D E F G H I J K L M N(継続的な)
dirtyページ
フラッシュ

D

D

I

O

fsfreeze
解除.backup
作成

時間

P Q R S T U V

L
I

WAL
スイッチ

P

S

L

✓大量トランザクション時のバックアップの信頼性
バックアップは、通常トランザクションが少ないときにすべきだが、大量トランザクションが発生したときにバックアップする可能性もあり得る。それによる信頼性に影響がないかが心配。

© Hitachi, Ltd. 2018. All rights reserved.

20

2-6. 各種操作とデータベースの状態（机上検証②）#

懸念事項

机上確認結果1 (pg_start_backup処理の)
CHECKPOINTによる書込み処理

CHECKPOINTにてfsyncシステムコールを呼び出している。
日立Linux有識者によれば、fsyncシステムコールにより、OSファイル
キャッシュ、およびディスク自体のキャッシュをフラッシュするとのことで問題なし。

2 ファイルシステム、fsfreezeの
信頼性• ext4とxfsを比較すると、xfsの方が数倍不具合対策されている状況で、まだ枯れてないと言える• RHEL7で対策された不具合がRHEL6にバックポートされていないものがある→不具合対策の状況を見つつ、OSのバージョンとファイルシステムを決める必要あり。

3 fsfreeze中のファイルシステムの fsfreeze中にペア分割した内容はファイルとして不完全な場合があるが、マ状態
ウント時にファイルシステムの機能により修復が行われるのでファイルシス
テムとしての整合性は保証される。
→ただし、データベースとしては不完全な場合もある。
→WALを用いたリカバリで修復される。
これらは実機でも確認する。
4 大量更新トランザクション中のバックアップの信頼性

机上では問題点は無いが、S-VOLにバックアップ取得、3rd-VOLにバックアップ取得、の両方を実機検証し、データの信頼性を確認する。
© Hitachi, Ltd. 2018. All rights reserved.

21

2-6. 各種操作とデータベースの状態（机上検証③）◼ トランザクションログ（WAL）の扱いについて
WALファイルの書き込み先については、ShadowImageの対象外とする。
・リカバリはPITR(Point In Time Recovery = 任意時点の回復)を想定しており、バックアップファイルとWALファイルが必要
・障害発生契機はバックアップ以降であり、ペア分割時点のWALファイルはリカバリ時には意味が無い
・世代管理等でバックアップを複数作成、管理する場合には、バックアップと対応するWALファイルの対応付けを管理する必要がある© Hitachi, Ltd. 2018. All rights reserved.

22

2-7. 検証環境
◼ 物理構成
ハード構成

VM1

ハード

HP ProLiant ML370 G6

CPUIntel Xeon Processor E5649(12core(HT有効) x 2Processor)

OS

メモリ

32GB

HyperVisor(KVM)

HDD

外部ストレージ(FC 8Gbps接続)

アプリ
PostgreSQL

H/W

Primary
Vol

Secondary
Vol

Third
Vol
Third
Vol

ストレージ構成ハード

HDD

VSP-G350
合計で約8TB© Hitachi, Ltd. 2018. All rights reserved.

23

2-7. 検証環境
◼ 論理構成

VM構成

VM1

CPU

4core

メモリ

8GB

ソフトウェア構成

アプリ

OS

PostgreSQL

RedHat Enterprise Linux 7.4 (x86_64)

PostgreSQL EDB Postgres Advanced Server 10.4.9

OS
HyperVisor(KVM)

アプリ

pgbench (業務アプリ代替)

API

RAID Manager (ストレージ操作)

H/W
ストレージ構成

Primary
Vol

Secondary
Vol

Third
Vol
Third
Vol

/

OS領域(500GB)/h1

DB領域(2TB)※この領域がボリュームレプリケーション対象/h2

WAL、アーカイブ領域（500GB)© Hitachi, Ltd. 2018. All rights reserved.

24

2-7. 検証環境
◼ postgresql.conf設定
parameter

value

listen_addresses

‘*’

port

5444

max_connections

200

shared_buffers

2048MBfsync

on

wal_sync_method

fsync

checkpoint_timeout

60min

max_wal_size

10GBcheckpoint_completion_target

0.8

archive_modeonarchive_command'cp %p /h2/pg_archive/%f'logging_collectoronlog_directory'/var/lib/edb/pg_log'© Hitachi, Ltd. 2018. All rights reserved.

25

2-8. 実機検証①◼ 大量更新トランザクション中のバックアップ／リカバリ検証●検証概要
業務アプリから大量更新のトランザクションがあるオンライン状態で、ストレージ機能のバックアップ処理が正しく実施できるか、実機検証で次の点を確認する。
pgbenchpg_start_backup

fsfreeze

pg_stop_backup

バックアップ処理①取得したバックアップデータとWALファイルでロールフォワードした結果（以降、『バックアップデータ』）と、pg_stop_backup時点のデータ（以降、『最新データ』）
を比較し、バックアップ時点のデータが正しいことを確認する。
なお、S-VOLにバックアップした場合と3rd-VOLにバックアップした場合の両方を確認するため、2回処理を行う形とする。
②バックアップ処理時間を実機検証し、fsfreezeによる処理待ち等のポイントを整理する。
© Hitachi, Ltd. 2018. All rights reserved.

26

2-8. 実機検証①◼ 大量更新トランザクション中のバックアップ／リカバリ検証※検証データについて
pgbenchを使用してデータを作成するが、バックアップデータと最新データの突合せはPostgreSQLで実施する。巨大テーブルの突合せは避けたいため、pgbench_accounts
テーブルをパーティション化（sf=1000／テーブル）するように、pgbenchのソースをカスタマイズしてデータ作成を行った。
なお、同じサイズのデータベースを２つ作成し、１つは大量トランザクション発生時の検証、
もう１つは無トランザクション時の検証を行った。
初期化コマンド$ pgbench –i -s 10000 pgbench(データサイズ：約150GB)

pgbench_accounts
Partition by range (aid)・・・
pgbench_accounts_01(1~100000000)

pgbench_accounts_02(100000001~200000000)

pgbench_accounts_10(900000001~1000000000)© Hitachi, Ltd. 2018. All rights reserved.

27

2-8. 実機検証①

V2◼ 大量更新トランザクション中のバックアップ／リカバリ検証●検証方法（枠内はコマンド例）①1回目のバックアップ処理の実行（併せてアーカイブWALをバックアップする）#!/bin/sh# 大量トランザクション発生
pgbench -u enterprisedb -p 5444 -c 128 -j 64 -t 10000 pgbench &# pg_start_backupの実施
psql -h 192.168.0.1 -p 5444 -U enterprisedb -c “select pg_start_backup(‘label’, true);“# fsfreezeによる静止化
fsfreeze -f /h1# ペア分割（バックアップ） ※ShadowImageコマンド
pairsplit -g si -fq normal -IM11# fsfreezeの解除
fsfreeze -u /h1# 大量トランザクション終了
pkill pgbench# pg_stop_backupの実施
psql -h 192.168.0.1 -p 5444 -U enterprisedb -c "select pg_stop_backup();“© Hitachi, Ltd. 2018. All rights reserved.

28

2-8. 実機検証①

V2◼ 大量更新トランザクション中のバックアップ／リカバリ検証●検証方法（枠内はコマンド例）②1回目の最新データの論理バックアップを取得$ pg_dump -f /tmp/pgbench1.dump -Fc --compress=1 -v pgbench③増分バックアップのための処理を実行
スナップショット取得（バックアップ） ※Thin Imageコマンド# raidcom modify snapshot -snapshotgroup incr1 -snapshot_data create④2回目のバックアップ処理の実行（併せてアーカイブWALをバックアップする）①と同じ処理を実施する。
⑤2回目の最新データの論理バックアップを取得$ pg_dump -f /tmp/pgbench2.dump -Fc --compress=1 -v pgbench⑥増分バックアップのための処理を実行
スナップショット取得（バックアップ） ※Thin Imageコマンド# raidcom modify snapshot -snapshotgroup incr2 -snapshot_data create© Hitachi, Ltd. 2018. All rights reserved.

29

2-8. 実機検証①

V2◼ 大量更新トランザクション中のバックアップ／リカバリ検証●検証方法（枠内はコマンド例）⑦2回目のバックアップデータのリストアを実行$ pairresync -g si -fq normal -restore -IM11※この時、リストア対象をumountしていないと、ファイルシステムを破壊するので注意⑧リカバリ準備を行った後、PostgreSQLの起動（リカバリ実行）$ pg_ctl start⑨2回目の論理バックアップをリストアする$ pg_restore -d pgbench -v /tmp/pgbench2.dump⑩データ比較
(全テーブルを双方向で比較、pgbench_accountsテーブルは子テーブルを比較)
psql=#(select * from pgbench_accounts01 except all select * from pgbench_accounts2_01)
union all(select * from pgbench_accounts2_01 except all select * from pgbench_accounts01);© Hitachi, Ltd. 2018. All rights reserved.

30

2-8. 実機検証①

V2◼ 大量更新トランザクション中のバックアップ／リカバリ検証●検証方法（枠内はコマンド例）⑪1回目のバックアップを3rd-VOLからS-VOLにリストアを実行# スナップショットからリストア ※Thin Imageコマンド
raidcom modify snapshot -snapshotgroup incr1 -snapshot_data restore⑫1回目のバックアップデータのリストアを実行$ pairresync -g si -fq normal -restore -IM11※この時、リストア対象をumountしていないと、ファイルシステムを破壊するので注意⑬リカバリ準備を行った後、PostgreSQLの起動（リカバリ実行）$ pg_ctl start⑭1回目の論理バックアップをリストアする$ pg_restore -d pgbench -v /tmp/pgbench1.dump⑮データ比較
(全テーブルを双方向で比較、pgbench_accountsテーブルは子テーブルを比較)
psql=#(select * from pgbench_accounts01 except all select * from pgbench_accounts2_01)
union all(select * from pgbench_accounts2_01 except all select * from pgbench_accounts01);© Hitachi, Ltd. 2018. All rights reserved.

31

2-8. 実機検証①

V2◼ 大量更新トランザクション中のバックアップ／リカバリ検証●S-VOLバックアップの検証結果
psql=#(select * from pgbench_accounts01 except all select * from pgbench_accounts2_01)
union all(select * from pgbench_accounts2_01 except all select * from pgbench_accounts01);
aid | bid | abalance | filler-----+-------+-------+-------(0 rows)
テーブル

大量トランザクション時
出力件数（アンマッチ数）

無トランザクション時
出力件数（アンマッチ数）

pgbench_history00pgbench_branches

00pgbench_tellers

00pgbench_accounts_01～10

00© Hitachi, Ltd. 2018. All rights reserved.

32

2-8. 実機検証①

V2◼ 大量更新トランザクション中のバックアップ／リカバリ検証●3rd-VOLバックアップの検証結果
psql=#(select * from pgbench_accounts01 except all select * from pgbench_accounts2_01)
union all(select * from pgbench_accounts2_01 except all select * from pgbench_accounts01);
aid | bid | abalance | filler-----+-------+-------+-------(0 rows)
テーブル

大量トランザクション時
出力件数（アンマッチ数）

無トランザクション時
出力件数（アンマッチ数）

pgbench_history00pgbench_branches

00pgbench_tellers

00pgbench_accounts_01～10

0

0→S-VOLへのバックアップ、3rd-VOLへのバックアップとも、バックアップデータと最新データが一致していることから、ストレージ機能を使ったオンラインバックアップは問
題なく使用できると判断できる（トランザクション状態やWAL領域の場所による違いは© Hitachi, Ltd. 2018. All rights reserved.
無かった）。

33

2-8. 実機検証①◼ ShadowImageによるバックアップ処理時間
バックアップ処理にはfsfreezeを使用しているため、この期間だけファイルへのアクセスが停止する。そのため、バックアップ時間を測定し、時間の傾向をつかんでおく。
なお、ボリュームは事前に同期(PAIR)しておくことが必要である。
pgbenchpg_start_backup

fsfreeze

CHECKPOINT処理に依存

pg_stop_backup＜１sec

fsfreeze
フリーズ

0.5~1
sec

ペア
分割

0.5sec fsfreeze
解除＜0.１sec→バックアップ処理時間は、pg_start_backupのCHECKPOINT処理時間に依存する。また、
fsfreezeによるアクセス停止時間が1秒前後あることから、業務アクセスが少ないときに実施© Hitachi, Ltd. 2018. All rights reserved.
することを推奨する。

34

2-8. 実機検証①◼ Thin Imageによるバックアップ処理時間
Thin Imageによるバックアップ処理は、ShadowImageでバックアップを取ったものを利用するため、オンラインバックアップでも業務の停止時間は不要である。
そのため、バックアップ時間はあまり気にする必要はなく、スナップショットを取得するのみのため1～2分で完了する。

© Hitachi, Ltd. 2018. All rights reserved.

35

2-9. 実機検証②◼ ファイルシステムの回復の担保
バックアップにおいて、ファイルシステムが不完全な状態があり得ると述べたが、リカバリにおいて整合性が担保できる状態に回復するか実機確認を実施した。
（ファイルシステムはxfs）
下記の通り、mount時に回復することをsyslogで確認できた。
Aug 8 09:35:32 pg10sv1 kernel: XFS (vdb1): Mounting V5 Filesystem
Aug 8 09:35:32 pg10sv1 kernel: XFS (vdb1): Starting recovery (logdev: internal)
Aug 8 09:35:32 pg10sv1 kernel: XFS (vdb1): Ending recovery (logdev: internal)© Hitachi, Ltd. 2018. All rights reserved.

36

2-10. 実機検証③◼ ストレージバックアップ影響評価
ストレージ機能のバックアップを使用すると、基本的に業務側には影響がないと言われているが、実際に性能やシステムにどの程度の影響を及ぼすか評価を行った。
なお、Thin Imageによる増分バックアップは、業務利用のボリュームと物理的に異なるため、業務側に影響は出ることはない。そのため、評価は対象外とした。
①性能影響評価→pgbench（バイナリ）を使用して、ペア同期時、ペア非同期時、ペアコピー時の性能測定を行い、影響評価を行った。
初期化コマンド$ pgbench –i -s 50000 pgbench(データサイズ：約750GB)

検証コマンド$ pgbench -c 128 -j 64 -s 50000 -t 200 -M extended pgbench②システム影響評価→dstatを使用して、バックアップ時のCPU、メモリ、ディスクI/Oの影響評価を行った。
$ dstat -f --output output_full.txt$ dstat -m -t --output output_mem.txt© Hitachi, Ltd. 2018. All rights reserved.

37

2-10. 実機検証③◼ ストレージバックアップ影響評価 - ①性能影響評価
ストレージの各状態でpgbenchを行った結果を示す。

pgbench result [TPS]
800
600
400
200
0
ペア無

ペアリング

ペア分割中

再同期中

初期同期中

→初期同期は業務時間外（運用開始前や定期メンテナンス時）に実施すると考えると、業務への影響は少ない。
© Hitachi, Ltd. 2018. All rights reserved.

38

2-10. 実機検証③◼ ストレージバックアップ影響評価 - ②システム影響評価(CPU、メモリ)
バックアップによるシステム影響評価を行った。なお、バックアップ実施前にpgbenchである程度更新データを蓄積してからバックアップを実施している。
cpu all Usage100

pg_start_backup

fsfreezeフリーズ
pairsplit
fsfreeze解除

Memory Usage

pg_stop_backup

80

8E+09

pg_start_backup

fsfreezeフリーズ
pairsplit
fsfreeze解除
pg_stop_backup

6E+09

60
4E+09
40
20

0

usr

used

2E+09
0

© Hitachi, Ltd. 2018. All rights reserved.

39

2-10. 実機検証③◼ ストレージバックアップ影響評価 - ②システム影響評価(I/O)
バックアップによるシステム影響評価を行った。なお、CHECKPOINT処理を考慮し、バックアップ実施前にpgbenchである程度更新データを蓄積してからバックアップを実施している。
Disk (データベース領域)

fsfreezeフリーズ
pairsplit
fsfreeze解除
pg_stop_backup

pg_start_backup

300000000
250000000

Disk (アーカイブ領域)

fsfreezeフリーズ
pairsplit
fsfreeze解除
pg_stop_backup

pg_start_backup

50000000

40000000

200000000

30000000

08:33:37

08:33:36

08:33:35

08:33:34

08:33:33

08:33:32

08:33:31

08:33:30

08:33:29

writ

08:33:28

08:33:37

08:33:36

08:33:35

08:33:34

08:33:33

08:33:32

08:33:31

08:33:30

08:33:29

08:33:28

0

08:33:27

0

08:33:26

10000000

08:33:25

50000000

read

08:33:27

writ20000000

08:33:26

read

100000000

08:33:25

150000000→システムへの影響は、pg_start_backupのCHECKPOINT処理によるディスク負荷のみであるが、これはストレージ機能のバックアップによるものではない。

© Hitachi, Ltd. 2018. All rights reserved.

40

2-11. 結論

V2◼ ストレージ機能を使ったバックアップの結論
机上検証、実機検証を行った結果、以下のことが確認できた。
✓ オンライン中でのバックアップとリカバリの手順の確立✓ 検証により、データベースのデータの完全性は担保✓ 定常運用に入った後は、業務やシステムへの影響は軽微✓ Thin Imageのスナップショット機能で、増分バックアップ運用（世代管理）も可能
以上のことから、ストレージ機能を使ったバックアップに問題ないことが確認できた。
なお、一般的なことだが、使用するにあたって以下の点を注意すべきである。
➢ バックアップ処理の大半がCHECKPOINT処理でサーバ負荷が高くなるので、業務負荷の少ない時間帯で実行すべきである。
➢ ペア分割のコマンドは非同期でペア未反映分のコピーが行われるため、コピー中に障害が発生するとバックアップが取得できていないことになるので、完了確認を行う必要がある。
➢ ペアリングを行う際のストレージ間コピー処理には時間がかかるため、時間的制約がある場合には運用に気を付ける。
➢ ストレージ操作を行うに当たっては、スクリプト化等をして操作間違いを起こさない運用にすべきである。
© Hitachi, Ltd. 2018. All rights reserved.

41

3. BART 2.2 β版のバックアップ／リカバリ検証© Hitachi, Ltd. 2018. All rights reserved.

42

3-1. 概要
◼ 概要
バックアップ処理時間の課題解決のもう一つのアプローチとして、pg_basebackupではなく、高機能なバックアップツールを使用する方法がある。
EDB Postgresでは、EDB Backup and Recovery Tool（以降、『BART』）を提供しており、このツールはバックアップの高速化機構やインクリメンタルバックアップなど優れた機能が多数搭載されている。
ここでは、バックアップの高速化機構（パラレルバックアップ）とインクリメンタルバッ
クアップ機能について、調査・検証を実施した結果をまとめる。
※
なお、EDB社以外のサードパーティからもデータベースツールがいくつか提供されている。
これらのバックアップツール（pg_rmanやBarman、OmniPITR）の調査結果については、
PostgreSQL エンタープライズ・コンソーシアムの成果物を参考にしてほしい。

© Hitachi, Ltd. 2018. All rights reserved.

43

3-2. 調査、検証◼ 検証内容BARTによるバックアップの調査、検証の概要は以下の通り。
①バックアップのフォーマット形式の検証②パラレルバックアップ
・機能調査
・パラレルバックアップの実機検証③インクリメンタルバックアップ
・機能調査
・インクリメンタルバックアップの実機検証© Hitachi, Ltd. 2018. All rights reserved.

44

3-3. 検証環境
◼ 論理構成

VM構成

VM1

VM2

アプリ
PostgreSQL

アプリ(bart)

OS

OS

メモリ

8GB

OS

RedHat Enterprise Linux 7.4(x86_64)

PostgreSQL EDB Postgres Advanced Server
10.4.9アプリ

H/W

PrimaryVol

4core

ソフトウェア構成

HyperVisor(KVM)

PrimaryVolCPUpgbench (業務アプリ代替)
bart 2.2.0 β1 (バックアップ)

ストレージ構成(VM1)

ストレージ構成(VM2)//OS領域(500GB)/h1 DB領域(2TB)/h2 WAL領域（500GB)

OS領域(500GB)/h1 バックアップ、アー
カイブ領域(2TB)© Hitachi, Ltd. 2018. All rights reserved.

45

3-3. 検証環境
◼ postgresql.conf設定
parameter

value

listen_addresses

‘*’

port

5444

max_connections

200

shared_buffers

2048MBfsync

on

wal_sync_method

fsync

checkpoint_timeout

60min

max_wal_size

10GBcheckpoint_completion_target

0.8

archive_modeonarchive_command'cp %p /h2/pg_archive/%f'logging_collectoronlog_directory'/var/lib/edb/pg_log'© Hitachi, Ltd. 2018. All rights reserved.

46

3-4. 実機検証①◼ バックアップのフォーマット形式検証
まず、バックアップのフォーマット形式を検討を行った。これにより、バックアップサイズや時間が影響するので、実際にどのパラメータにするのがベターか考察するためである。
$ bart BACKUP -s EDBAS10 [format option]

フォーマットバックアップ
サイズ

バックアップ コメント
時間

Plain

730.25GB

2640sec

業務DBとバックアップサイズが同じなため、世代管理を考えると巨大なディスクが必要

tar.gz(compress-level: default)

39.64GB

15002sec

処理が遅く、圧縮処理のサーバ負荷が高いtar.gz(compress-level: 1)

42.43GB6847sec

サイズと処理時間を考えると、バランスが良い(いずれもthread-count=1で測定)

compress-level=1がベターと考え、以降の検証ではこの設定を使用している。
© Hitachi, Ltd. 2018. All rights reserved.

47

3-5. パラレルバックアップ◼ 機能概要
現在、BART 2.2のβ版が提供されているが、新機能としてパラレルバックアップ機能が追加されており、次期リリース版でも提供される予定である。
この機能の優位点は、フルバックアップのみの機能で、複数のワーカースレッドを起動してバックアップ並列化し高速化をはかることができる。なお、圧縮操作にも適用されるため、非常に有用と考えられる。
使い方は、BART設定ファイル(bart.cfg)、もしくは、実行時の引数で指定する。
パラメータ名： --thread-count（デフォルト1）●検証概要
・パラレルバックアップの並列化の影響© Hitachi, Ltd. 2018. All rights reserved.

48

3-5. 実機検証② - パラレルバックアップ◼ バックアップ検証
バックアップのワーカースレッド数によるパラレルバックアップ速度の影響について、実機検証をした結果をグラフ化した。
$ bart BACKUP -s EDBAS10 -Ft -z -c1 --thread-count [count]

バックアップ取得時間

backup time (thread count)
01:45:00
01:30:00

スレッド数20で
Out of memoryエラー

01:15:00
01:00:00
00:45:00
00:30:00
00:15:00
00:00:00

1

3

5

7

9

11
スレッド数

13

15

17

19

→ワーカースレッド数は、環境依存であることが大きいと思われるため、実環境で試したのち使用すべきである。
© Hitachi, Ltd. 2018. All rights reserved.

49

3-5. 実機検証② - パラレルバックアップ◼ バックアップ処理結果
あわせてバックアップの内容について確認した。
以下が、lsの結果である。
-rw-rw-r--. 1 enterprisedb enterprisedb
610 Aug 15 19:46 backupinfo-rw-------. 1 enterprisedb enterprisedb
199 Aug 15 19:03 backup_label
drwxrwxr-x. 4 enterprisedb enterprisedb
37 Aug 15 19:03 base-rw-rw-r--. 1 enterprisedb enterprisedb 9108936532 Aug 15 19:46 base-1.tar.gz-rw-rw-r--. 1 enterprisedb enterprisedb 9115177188 Aug 15 19:46 base-2.tar.gz-rw-rw-r--. 1 enterprisedb enterprisedb 9124355483 Aug 15 19:46 base-3.tar.gz-rw-rw-r--. 1 enterprisedb enterprisedb 9113831955 Aug 15 19:46 base-4.tar.gz-rw-rw-r--. 1 enterprisedb enterprisedb 9036390386 Aug 15 19:46 base-5.tar.gz-rw-rw-r--. 1 enterprisedb enterprisedb
128 Aug 15 19:46 base.tar.gz→パラレルバックアップは、データベースやテーブルサイズの偏りがあったとしてもきれいに分割できていることが確認できた。つまり、データベースの中身がどのような状態でもパラレル化は有効であると言える。
© Hitachi, Ltd. 2018. All rights reserved.

50

3-5. 実機検証② - パラレルバックアップ◼ リカバリ検証
リカバリもワーカースレッド数が指定できるため、パラレルリカバリ速度の影響について、実機検証をした結果をグラフ化した。なお、ワーカースレッド数はバックアップのワーカースレッド数と同じにしている。
$ bart RESTORE -s EDBAS10 –i [BACKUP ID] -r enterprisedb@192.168.0.1 -p /h1/restore/data--workers [count]restore time (worker count)
リストア時間

01:15:00
01:00:00
00:45:00
00:30:00
00:15:00
00:00:00
1

3

5

7
ワーカー数

9

11

13

15

→ワーカー数によるリカバリ速度の改善は見られなかった。
© Hitachi, Ltd. 2018. All rights reserved.

51

3-6. インクリメンタルバックアップ◼ 機能概要次に、インクリメンタルバックアップ機能だが、こちらはBART 2.0から提供されている。
この機能の優位点は、ブロックレベルで差分をスキャンしバックアップすることで、バックアップ時間の短縮化をはかることができる。なお、機能的に差分バックアップと増分バック
アップのいずれも利用できたので、後述する。
但し、インクリメンタルバックアップは、圧縮機能は対応しておらず、かつ、マスタサーバ側でしか実行できないという制約があるので、使い方には注意が必要である。
使い方は、① BART設定ファイル(bart.cfg)で、allow_incremental_backups = enabled の設定を追加② WALスキャナ bart-scanner を起動する③ バックアップ実行時の引数にパラメータを設定する
パラメータ名： --parent [親のBACKUP ID]●検証概要
・インクリメンタルバックアップのバックアップサイズと時間・差分バックアップと増分バックアップサイズの比較© Hitachi, Ltd. 2018. All rights reserved.

52

3-6. 実機検証③ - インクリメンタルバックアップ◼ insert量に対するインクリメンタルバックアップ
インサート量を可変させて、バックアップサイズとバックアップ時間を整理した。インサートは、pgbench_accountsテーブルに追加している。
psql=# insert into pgbench_accounts values (cnt, cnt / 100000 + 1, 0, null);

インサート量バックアップサイズ

バックアップ時間

100万件

9,984MB

14:28

200万件

9,696MB

14:28

500万件

9,711MB

48:55

1000万件

9,069MB

48:53

2000万件

8,345MB

48:44

5000万件

10,527MB

49:20

1億件

16,461MB

1:30:32→バックアップサイズ、時間とも値を詳細化してみた。
© Hitachi, Ltd. 2018. All rights reserved.

53

3-6. 実機検証③ - インクリメンタルバックアップ◼ insert量に対するインクリメンタルバックアップ
バックアップサイズを詳細化したところ、データが格納されているのは、ほぼbaseとpg_walの２ヶ所であった。この２つのディレクトリについて整理した。
インサート量バックアップサイズ

base/

pg_wal/バックアップ
時間

100万件

9,984MB

63.7MB

9,920MB

14:28

200万件

9,696MB127.3MB

9,568MB

14:28

500万件

9,711MB318.3MB

9,392MB

48:55

1000万件

9,069MB636.5MB

8,432MB

48:53

2000万件

8,345MB1273.1MB

7,072MB

48:44

5000万件

10,527MB

3182.7MB

7,344MB

1億件

16,461MB

6365.2MB

10,096MB

49:20
max_wal_size
1:30:32→バックアップのbase領域のサイズは、インサート量に比例しており差分を 取得していると言える。一方で、今回はbase領域が小さいため、バックアップサイズはpg_wal領域の影響が大きいのがわかる。通常の差分量のみではない点に注意が必要である。
© Hitachi, Ltd. 2018. All rights reserved.

54

3-6. 実機検証③ - インクリメンタルバックアップ◼ insert量に対するインクリメンタルバックアップ
次に、バックアップ時間を詳細化したところ、時間がかかっているのは実際のバックアップ
処理時間ではなくCHECKPOINT処理時間であることがわかる。

インサート量CHECKPOINT
処理

バックアップ処理

100万件

13:38

0:48

13:37

0:50

200万件

バックアップ バックアップ時間
サイズ
checkpoint_timeout
9,984MB & 14:28
checkpoint_completion_target
9,696MB
14:28

500万件

9,711MB

48:55

47:59

0:53

1000万件

9,069MB

48:53

47:59

0:52

2000万件

8,345MB

48:44

48:00

0:42

5000万件

10,527MB

49:21

47:59

1:19

1億件

16,461MB

1:30:33 (*)

48:00 (*)

2:07(*)insert処理のチェックポイントが走ったため処理が長期化した→バックアップ時間については、CHECKPOINT処理時間に大きく影響している© Hitachi, Ltd. 2018. All rights reserved.
と言える。

55

3-7. 結論
◼ BARTを使ったバックアップの結論
机上調査、実機検証を行った結果、以下のことが確認できた。
✓ パラレルバックアップの有効性は評価できる✓ インクリメンタルバックアップは、WAL領域の取得が大きいためmax_wal_sizeの指定には要検討✓ バックアップ管理は、CUIベースだが世代管理を行いやすい。ただ、GUIベースのPEMと早く統合を望まれる。
なお、一般的なことだが、使用するにあたって以下の点を注意すべきである。
➢ ストレージ機能のバックアップ同様に、バックアップ処理の大半がCHECKPOINT処理で時間がかかり、かつ、サーバ負荷が高くなるので、業務負荷の少ない時間帯で実行すべきである。
➢ インクリメンタルバックアップはplain形式のみで圧縮は未対応のため、追加・変更が多いとフルバックアップよりサイズや取得時間が悪化する可能性があり、業務から判断する必要がある。
➢ リストアについては、postgresql.conf の archive_mode=off になる設定が追加されるので注意が必要である。
© Hitachi, Ltd. 2018. All rights reserved.

56

4. サービス紹介© Hitachi, Ltd. 2018. All rights reserved.

57

4-1. 日立のEDB Postgresサポートサービス◼ 日立が提供するEDB Postgresサポートサービスの特長⚫ 日立サポート360によるワンストップサポート⚫ 日立およびEnterprise DB社の技術者の連携による問合せ対応
日立サポート360ご利用のメリット
日立の総合力によりシステム一体のサポートを提供します。障害発生時もお客さまは問題を切り分けることなくお問い合わせいただけます。また、原因究明が難しい問題も各製品技術者、導入
元ベンダとの連携により、多角的に問題解決にあたります。
お客様
障害
発生

お客様での
切り分け不要EnterpriseDB社

日立
各製品担当技術者間で連携

お問合せ
サーバ

連携

早期解決！
ストレージ

迅速回答

ミドルウェアOSSLinux/Windows

http://www.hitachi.co.jp/Prod/comp/soft1/support360/

自社DB開発経験者が対応© Hitachi, Ltd. 2018. All rights reserved.

58

4-2. 日立のEDB Postgresプロフェッショナルサービス
安定稼働の実現を支援する、システムの設計から運用フェーズまでをサポートするサービスです。
技術支援

概要

コンサルティング

お客さまの困りごとに対して、コンサルティング支援を行います。
下記の支援内容以外にも、例えば、テストや本番運用時に性能が出ない際の問題解決のためのノウハウ提供や支援を行います。

設計・構築支援要件に応じた構築を行うために、構成検討やインストール設計、
パラメタ設計、運用設計などのノウハウ支援、問題解決、作業支援を行います。
また、立ち会いによる構築支援を行います。

クラスタ構築支援

高可用性、高信頼性を確保しなければならない基幹システムには、クラスタソフトウェアと組み合わせた構成で設計・構築を支援します。

マイグレーション支援

他の商用データベースからEDB Postgresに移行する際の先行調査、影響範囲を見極め、マイグレーションを支援します。移行の際の留意点やノウハウを提供します。

製品トレーニング

製品を初めてご利用になる開発技術者に向けたサービスメニューです。
製品の概要説明や基本機能の使い方を習得できます。
© Hitachi, Ltd. 2018. All rights reserved.

59

4-2. 日立が対応する主要OSS
クラウド• OpenStack

ビッグデータ••••ビジネスルール• Red Hat Decision Manager

Web・
アプリケーションサーバ

•
•
•
•

データベース• EDB Postgres• PostGIS• Oracle MySQL• MySQL(コミュニティ版)• PostgreSQL• MongoDB

クラスタソフト※PostgreSQLとの組合せのみ• pgpool-II• pacemaker• Corosync

ネットワーク

• BIND• Sambaメール• dovecot• Postfix

ファイル同期• rsync

運用管理• Ansible• MIRACLE ZBX

認証・セキュリティ

• OpenLDAP• GnuPG• OpenSSL• Keycloak• Spring Security Oauth

開発管理• Redmine

開発言語・
フレームワーク• Apache Struts• MyBatis• Spring Framework• Red hat Developer Studio

ライブラリ・API• jQuery• jQuery UI• Log4j 2• SLF4J• Logback• JasperReports Library• ApachePOI

OS・プラットフォーム• Red Hat Enterprise Linux• MIRACLE LINUXCloudera Enterprise
Kafka(コミュニティ版)
ZooKeeper(コミュニティ版)
Asakusa Framework
Apache HTTP Server
JBoss Web Server
mod_jkApache Commons Collection• Hadoop(コミュニティ版)• Hive(コミュニティ版)• Hadoop(Cloudera版)• Spark(コミュニティ版)• HBase(コミュニティ版)• Talend• JBoss Process Automation Manager••••

TomcatRed Hat Fuse
Nginx
Apache Commons IO

•
•
•
•

JBoss Enterprise Application Platform
PHP
Apache Commons Lang
Apache Commons Net© Hitachi, Ltd. 2018. All rights reserved.

60

END
大規模DBのバックアップ運用に向けた取り組み Ver.2

2018/12/10(株)日立製作所 システム＆ビジネスビジネス統括本部
OSSソリューションセンタ

© Hitachi, Ltd. 2018. All rights reserved.

61付録．他社商品名，商標等の引用に関する表示
・HITACHIは、株式会社 日立製作所の商標または登録商標です。
・PostgreSQLは、PostgreSQL Community Association of Canadaのカナダにおける登録商標
およびその他の国における商標です。
・EnterpriseDBは、EnterpriseDB Corporationの登録商標です。 EDBおよびEDB Postgresは、EnterpriseDB Corporationの商標です。
・Linuxは，Linus Torvalds氏の日本およびその他の国における登録商標または商標です。
・Red Hatは，米国およびその他の国でRed Hat, Inc. の登録商標若しくは商標です。
その他記載の会社名，製品名などは，それぞれの会社の商標もしくは登録商標です。

© Hitachi, Ltd. 2018. All rights reserved.

62