![Firebirdの障害対策 データベースの運用時に障害対策は必須の問題です。ハードウェアでの障害対策はもちろんのこと、Firebird単体での障害対策も行っていくことが必要です。Firebird単体で可能な障害対策は以下の三つに絞られます。 ,[object Object]](data:image/gif;base64,R0lGODlhAQABAIAAAAAAAP///yH5BAEAAAAALAAAAAABAAEAAAIBRAA7)
Recommended
More Related Content
What's hot
What's hot (20)
Viewers also liked
Viewers also liked (14)
Recently uploaded
Recently uploaded (16)
Firebirdの障害対策
- 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
- 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 データベース シャドウ データベース シャドウ 自動的にシャドウを作成
- 27. IBO Replication Module - Delphi/C++ Builder用コンポーネント、IBObjectsの作者Jason Wahrton氏によるものhttp://www.ibobjects.com/iborpl.html
- 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 定義を追加した
- 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
- 46. IBFirstAIDの実行画面
- 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