1. Firebirdの障害対策、バックアップとシャドウ、リストア、パフォーマンス対策まで Firebird日本ユーザー会 はやしつとむ 2010/01/17@APEX

3. シャドウの作成

5. PageSize？

6. DBキャッシュのサイズ

7. ファイルシステムの変更

8. インデックスの追加

9. PLANの修正

11. NBackupのデータベースロック・アンロック NBackupでデータベースをロックしている間の読み書きは全てデルタに対して行われる。 クライアント クライアント クライアント クライアント NBackupによるロック操作 NBackupによるアンロック操作 Firebird Firebird ロック データベース デルタ データベース デルタ マージ ロック中にファイルコピーをしてバックアップ可能

12. NBackupによる増分バックアップ Level0でのフルバックアップ後、Level1でバックアップを取り続けると、Level0からの変更が全て含まれているので、Level0+最後のLevel1でリストア出来る。 初期状態 Level0 初期状態 Level0 Level1 初期状態 Level0 Level1 初期状態 Level0 Level1

13. NBackupによる差分バックアップ Level0でのフルバックアップ後、各LevelでLevel-1からの変更を取得出来る。Level1、Level2、Level3とLevelを挙げていくとLevel間の差分が蓄積されるので、下の例ではLevel0～Level3までを揃えてリストアする。 初期状態 Level0 初期状態 Level0 Level1 初期状態 Level0 Level1 Level2 初期状態 Level0 Level1 Level2 Level3

14. gbakと NBackupのバックアップ・リストア速度の比較 CentOS5.3上のDbBench-SCALE1000データベース（約6GB）をそれぞれフルバックアップ・リストアしてみた。Ext3とXFSでテストしたが優位な差は無かったので、Ext3のみ掲載する。

16. 毎週一回のLevel1バックアップ 1～2ヶ月保管

17. 毎日一回のLevel2バックアップ 1～2週間保管

18. 毎時一回のLevel3バックアップ 1週間保管※バックアップファイルを圧縮することはお勧め出来ません。解凍するのにも時間がかかるからです。 ロシアのIBSurgeon社のDmitry Kuzumenko氏によると、最終的に約6GBになったデータベースでこうした運用を行ったところ、1年間でバックアップファイルの総容量は40GB程度だったようです。この状態でLevel3バックアップに1～2分程度だということですが、データベースが数百GBになってくるとLevel3バックアップでも1時間を超える可能性があるので、そうした際にはバックアップ間隔を大きくとる必要が出てくるでしょう。

19. Shadow Shadowが存在しているかどうかは、クライアントは関知しないので、通常通りFirebirdに接続すればよい。 クライアント クライアント クライアント クライアント Firebird Firebird データベース データベース シャドウ ※データベース、シャドウ共にマルチファイル構成を取れる

20. Shadowの昇格 データベースに障害が発生した場合、gfixコマンドを利用してシャドウをデータベースに昇格させる。 クライアント クライアント クライアント クライアント Firebird Firebird データベース データベースに昇格 データベース シャドウ

21. Shadowに障害が発生した場合 シャドウに障害が発生した場合、各モードで動作が分かれる。デフォルトはAUTO。 AUTOモード MANUALモード クライアント クライアント クライアント クライアント Firebird Firebird データベース シャドウ データベース シャドウ

22. CONDITIONALモードの動作 CONDITIONALモードの場合、自動的にシャドウを再作成する。ディスク障害の場合等ではこの動作自体がエラーになる可能性がある。 CONDITIONALモード クライアント クライアント クライアント クライアント Firebird Firebird データベース シャドウ データベース シャドウ 自動的にシャドウを作成

23. Shadowのパフォーマンスへの影響 CentOS5.3上のDbBench-SCALE100データベース（約600MB）に対して、同一フォルダにShadowを作成した場合、別ドライブにShadowを作成した場合のそれぞれでTPC-Bテストを実行した。同時接続クライアント数は10で各1000トランザクションを実行した。 6割パフォーマンス減 8割パフォーマンス減

25. FiBRE – オープンソース、クロスプラットフォームhttp://fibre.sourceforge.net/

26. FBReplicator – オープンソースhttp://www.meta.com.au

27. IBO Replication Module - Delphi/C++ Builder用コンポーネント、IBObjectsの作者Jason Wahrton氏によるものhttp://www.ibobjects.com/iborpl.html

28. ReplicadorBR – オープンソースhttp://sourceforge.net/projects/replicadorbr/

29. Replicador Firebird – フリーウェアhttp://replicadorfirebird.ich.pro.br/

30. CopyCat (components) and CopyTiger (application) – 商用、Microtec Communications社はフランスの会社http://www.microtec.fr/copycat/

31. ININ Replication Manager – 商用、ININ社はクロアチアの会社http://www.inin.hr/

32. Daffodil Replicator – 商用、Daffodil社はインドの会社http://enterprise.replicator.daffodilsw.com/index.html

33. DB Replicator – オープンソース、Dafodilからの派生プロダクトhttp://dbreplicator.org/

35. IBP Replicator Replication Managerでの設定 Replication Managerでの設定はGUIを利用して手軽に行える。 「File」－「New configuration」を実行 「Database」－「Add」を実行

36. IBP Replicator Replication Managerでの設定 各データベースを設定する ※今回設定した内容 ＜1つ目＞ ・Descriptive name：scale100-master ・Server：192.168.1.148:/mnt/xfs/firebird/SCALE100.25.FDB ・Administrative user name：sysdba ・Administrative password：masterkey ・Character set ：UTF8 ＜2つ目＞ ・Descriptive name：scale100-master ・Server： 192.168.1.148:/mnt/xfs/firebird/SCALE100.25.repl.FDB ・Administrative user name：sysdba ・Administrative password：masterkey ・Character set ：UTF8

37. IBP Replicator Replication Managerでのスキーマ設定 「New shcema」でスキーマを新規作成する

38. IBP Replicator Replication Managerでのスキーマ設定 「Target database」を追加する 「Generate Tables, Keys and Fields」でレプリケーション の定義を作成する

39. IBP Replicator Replication Managerでのスキーマ設定 主キーのないテーブルの場合は注意が必要 Data columuns定義を解消して、Primary keys 定義を追加した

40. レプリケーションのパフォーマンスへの影響 CentOS5.3上のDbBench-SCALE100データベース（約600MB）に対してレプリケーション無しの場合と、マスター／スレーブのフル・レプリケーションを実行中の二つの条件でTPC-Bテストを実行した。同時接続クライアント数は10で各1000トランザクションを実行した。

41. データベースが破損した場合の対策 データベース破損に対しても、まずは本体付属のgfixで破損の状態を確認してみることになります。-vオプションと-nオプションを指定すると、エラーを発見して報告しますが修復はしないので、まず状況を確認という場合はこの二つを指定して実行します >gfix -user sysdba –festdin c:atabaseample.fdb –v -n Summary of validation errors Number of data page errors : 3 Number of index page errors : 1 -fオプションを指定した場合には、もう少し詳細なエラーが報告されます。調べる範囲が違うので、index pageのエラーが実はもう少し多かったことがわかります。 >gfix -user sysdba -password masterkey c:atabaseample.fdb -v -f Summary of validation errors Number of record level errors : 431 Number of data page errors : 3 Number of index page errors : 4 Number of database page errors : 24

42. gfixでのデータベース破損の修復 破損してしまったデータベースは、gfixに-mオプションをつけて実行し、破損箇所をマークした上でgbakによるバックアップ／リストアを行うことでエラーを修復することが可能です。 -vや-v –f オプションでも修復を試みますが、これは孤立ページをページインベントリから削除したり、逆に使用中にも関わらず未使用と記録されているページをページインベントリへ記録するなどのページレベルの修復に限られます。 レコードレベルでの破損については、各レコードに「damaged」というラベルを付けておくに留まります。また、インデックスの破損については報告はされますが、修復はされません 。（ Firebirdのソースコード中のsrc/jrd/validation.cppをご覧下さい。） gfix -v -n 障害の有無を確認 障害対応手順 gfix -v -f 障害の詳細を確認 gfix -m 破損箇所のマーク gbakでバックアップ＋リストア

43. Firebirdのページタイプ Page-n 3-Transaction Inventory

44. Firebirdのページ関連図 ページ0～2はヘッダ、ページ使用情報、使われていないWALページとなっている。その後、ページ3～5がシステムテーブルRDB$PAGEになっていて、この後に各システムテーブルが続く。 Page-0 1-Header Page-1 2-PageInventory Page-2 10-WAL Page-3 4-Pointer Page-4 6-IndexRoot Page-5 5-Data テーブルを辿る際には、テーブル名等からシステムテーブルRDB$RELATIONSに格納されるページ番号 を取得。ページ番号によって、システムテーブルRDB$PAGEに格納されるPointerPageとIndexRootページ のページ番号を取得し、そこから各テーブルのDataPageやIndexPageを辿って行く。 リレーション名 RDB$RELATIONS RDB$PAGES DatePage PointerPage IndexPage IndexRootPage

45. IBFirstAID gfixで直しきれないデータベースの破損が発生した場合には、IBSurgeon社製のIBFirstAIDを利用して修復を試みます。起動すると「お金払って～！」といわれますが、まずは「Diagnosebeforebuy(free)」でDB破損の検証だけ無料で行えます。 IBFirstAIDの起動画面

46. IBFirstAIDの実行画面

48. ファイルシステムの選択CentOSをはじめ、Linuxの各ディストリビューションではExt3がデフォルトのファイルシステム。Ext4をはじめ、新しいファイルシステムが提案されているが、しばらくはExt3が主流。ところが、こいつは遅い・・・

49. OSの選択Windowsなのか、Linuxなのか、はたまたMacOSXなのか、Soralisなのか。OS毎にパフォーマンスの出方が違う。Windowsはスレッドに強いが、プロセスに弱い。Linuxは真逆。Windowsの場合には、NTFSしか選択肢がないが、これはなかなかに早い。

52. Find (experimentally) an optimal page cache size

53. Calculate and set up LockMemSize accordingly

54. Play with LockAcquireSpins and test the performance

55. Consider FW=OFF with MaxUnflushedWrites = 1

56. Set up SortMemUpperLimit, if necessary

57. Monitor the lock table and increase LockHashSlotsSlide 30

58. A36 Dmitry Yemanov Page Cache Performance for Writers Slide 31

59. A36 Dmitry Yemanov CPU Scalability Slide 32

60. A36 Dmitry Yemanov Concurrency: TPC-C benchmark Slide 33