Firebirdの障害対策

10,779 views

Published on

Published in: Technology, Health & Medicine
  • Be the first to comment

Firebirdの障害対策

  1. 1. Firebirdの障害対策、バックアップとシャドウ、リストア、パフォーマンス対策まで<br />Firebird日本ユーザー会 はやしつとむ<br />2010/01/17@APEX<br />
  2. 2. Firebirdの障害対策<br />データベースの運用時に障害対策は必須の問題です。ハードウェアでの障害対策はもちろんのこと、Firebird単体での障害対策も行っていくことが必要です。Firebird単体で可能な障害対策は以下の三つに絞られます。<br /><ul><li>バックアップ
  3. 3. シャドウの作成
  4. 4. レプリケーションの導入</li></ul>この他に、「所定の性能が出ない」とか「運用している間に性能が落ちてきた」というのも「性能障害」ととらえることも出来ます。パフォーマンス対策には多数の選択肢があります。<br /><ul><li>CS or SS or SC?
  5. 5. PageSize?
  6. 6. DBキャッシュのサイズ
  7. 7. ファイルシステムの変更
  8. 8. インデックスの追加
  9. 9. PLANの修正
  10. 10. ForcedWriteをOFFにする(MaxUnflushedWrites = 1)</li></li></ul><li>Firebirdのバックアップ<br />データベースの破損に備えるため、FirebirdはコマンドレベルとAPIレベルの両方でバックアップ及びリストアをサポートしています。Gbakと Nbackupの主な違いは以下のようになります。<br />gbak<br />NBackup<br />フルバックアップ<br />○<br />○<br />増分バックアップ<br />×<br />○<br />差分バックアップ<br />×<br />○<br />ガベコレ<br />○<br />×<br />トランスポータブル<br />○<br />×<br />
  11. 11. NBackupのデータベースロック・アンロック<br />NBackupでデータベースをロックしている間の読み書きは全てデルタに対して行われる。<br />クライアント<br />クライアント<br />クライアント<br />クライアント<br />NBackupによるロック操作<br />NBackupによるアンロック操作<br />Firebird<br />Firebird<br />ロック<br />データベース<br />デルタ<br />データベース<br />デルタ<br />マージ<br />ロック中にファイルコピーをしてバックアップ可能<br />
  12. 12. NBackupによる増分バックアップ<br />Level0でのフルバックアップ後、Level1でバックアップを取り続けると、Level0からの変更が全て含まれているので、Level0+最後のLevel1でリストア出来る。<br />初期状態 Level0<br />初期状態 Level0<br />Level1<br />初期状態 Level0<br />Level1<br />初期状態 Level0<br />Level1<br />
  13. 13. NBackupによる差分バックアップ<br />Level0でのフルバックアップ後、各LevelでLevel-1からの変更を取得出来る。Level1、Level2、Level3とLevelを挙げていくとLevel間の差分が蓄積されるので、下の例ではLevel0~Level3までを揃えてリストアする。<br />初期状態 Level0<br />初期状態 Level0<br />Level1<br />初期状態 Level0<br />Level1<br />Level2<br />初期状態 Level0<br />Level1<br />Level2<br />Level3<br />
  14. 14. gbakと NBackupのバックアップ・リストア速度の比較<br />CentOS5.3上のDbBench-SCALE1000データベース(約6GB)をそれぞれフルバックアップ・リストアしてみた。Ext3とXFSでテストしたが優位な差は無かったので、Ext3のみ掲載する。<br />
  15. 15. NBackupを使用したバックアップ手法<br />実際の運用局面を考慮した場合、NBackupでのバックアップは以下のようなストラテジーで運用することが考えられます。<br /> <br /><ul><li>毎月一回のLevel0バックアップ 1年間保管
  16. 16. 毎週一回のLevel1バックアップ 1~2ヶ月保管
  17. 17. 毎日一回のLevel2バックアップ 1~2週間保管
  18. 18. 毎時一回のLevel3バックアップ 1週間保管</li></ul>※バックアップファイルを圧縮することはお勧め出来ません。解凍するのにも時間がかかるからです。<br /> <br /> ロシアのIBSurgeon社のDmitry Kuzumenko氏によると、最終的に約6GBになったデータベースでこうした運用を行ったところ、1年間でバックアップファイルの総容量は40GB程度だったようです。この状態でLevel3バックアップに1~2分程度だということですが、データベースが数百GBになってくるとLevel3バックアップでも1時間を超える可能性があるので、そうした際にはバックアップ間隔を大きくとる必要が出てくるでしょう。<br />
  19. 19. Shadow<br />Shadowが存在しているかどうかは、クライアントは関知しないので、通常通りFirebirdに接続すればよい。<br />クライアント<br />クライアント<br />クライアント<br />クライアント<br />Firebird<br />Firebird<br />データベース<br />データベース<br />シャドウ<br />※データベース、シャドウ共にマルチファイル構成を取れる<br />
  20. 20. Shadowの昇格<br />データベースに障害が発生した場合、gfixコマンドを利用してシャドウをデータベースに昇格させる。<br />クライアント<br />クライアント<br />クライアント<br />クライアント<br />Firebird<br />Firebird<br />データベース<br />データベースに昇格<br />データベース<br />シャドウ<br />
  21. 21. Shadowに障害が発生した場合<br />シャドウに障害が発生した場合、各モードで動作が分かれる。デフォルトはAUTO。<br />AUTOモード<br />MANUALモード<br />クライアント<br />クライアント<br />クライアント<br />クライアント<br />Firebird<br />Firebird<br />データベース<br />シャドウ<br />データベース<br />シャドウ<br />
  22. 22. CONDITIONALモードの動作<br />CONDITIONALモードの場合、自動的にシャドウを再作成する。ディスク障害の場合等ではこの動作自体がエラーになる可能性がある。<br />CONDITIONALモード<br />クライアント<br />クライアント<br />クライアント<br />クライアント<br />Firebird<br />Firebird<br />データベース<br />シャドウ<br />データベース<br />シャドウ<br />自動的にシャドウを作成<br />
  23. 23. Shadowのパフォーマンスへの影響<br />CentOS5.3上のDbBench-SCALE100データベース(約600MB)に対して、同一フォルダにShadowを作成した場合、別ドライブにShadowを作成した場合のそれぞれでTPC-Bテストを実行した。同時接続クライアント数は10で各1000トランザクションを実行した。<br />6割パフォーマンス減<br />8割パフォーマンス減<br />
  24. 24. Firebirdのレプリケーション<br />Firebirdはその前身であるInterBase5.xの時代からレプリケーションがサポートされてきました。InterBase6でBorlandが本体に同梱していたIBReplicatorが筆頭ですが、その他にも以下の商用・オープンソースの製品があります。(IBReplicatorはその後、Firebirdの支援企業であるIBPhoenix社が開発・販売するようになり、名称をIBP Replicatorと変更して現在に至る)<br /><ul><li>IBP Replicator – 商用、クロスプラットフォームhttp://www.ibphoenix.com/main.nfs?a=ibphoenix&page=ibp_replicator
  25. 25. FiBRE – オープンソース、クロスプラットフォームhttp://fibre.sourceforge.net/
  26. 26. FBReplicator – オープンソースhttp://www.meta.com.au
  27. 27. IBO Replication Module - Delphi/C++ Builder用コンポーネント、IBObjectsの作者Jason Wahrton氏によるものhttp://www.ibobjects.com/iborpl.html
  28. 28. ReplicadorBR – オープンソースhttp://sourceforge.net/projects/replicadorbr/
  29. 29. Replicador Firebird – フリーウェアhttp://replicadorfirebird.ich.pro.br/
  30. 30. CopyCat (components) and CopyTiger (application) – 商用、Microtec Communications社はフランスの会社http://www.microtec.fr/copycat/
  31. 31. ININ Replication Manager – 商用、ININ社はクロアチアの会社http://www.inin.hr/
  32. 32. Daffodil Replicator – 商用、Daffodil社はインドの会社http://enterprise.replicator.daffodilsw.com/index.html
  33. 33. DB Replicator – オープンソース、Dafodilからの派生プロダクトhttp://dbreplicator.org/
  34. 34. DBRE – オープンソース、FirebirdとMySQLをサポートhttp://dbre.sourceforge.net/</li></li></ul><li>IBP Replicator<br />IBP ReplicatorはIBPhoenix社が販売するFirebird/InterBase用の商用レプリケーション製品です。IBP Replicatorは2つのコンポーネントから構成されています。<br />レプリケーションマネージャ、32bit/64bitのWindows95/98/2000/XP/2003/2008上で動作します。<br />レプリケーションサーバー、32bit/64bitのWindows/Linuxの各OS用バイナリが存在します 。サポートするFirebird/InterBaseのバージョンは以下の通りです。Firebird V1.x, 2.x, InterBase V5.x, V6.x, V7.x, 2007,2009<br />IBP Replicatorのライセンス体系としては、以下の二つのライセンスがあり、必要に応じて組み合わせる事になります。<br /> <br />サーバーライセンス:レプリケーションサーバーの1インスタンス毎に1ライセンス必要<br />レプリカントライセンス:レプリケートするDBの1つ毎に1ライセンス必要<br />レプリケーションサーバー<br />※左の構成だと、<br />1サーバーライセンス<br />+3レプリカントライセンス<br />DB1<br />DB2<br />DB3<br />
  35. 35. IBP Replicator Replication Managerでの設定<br />Replication Managerでの設定はGUIを利用して手軽に行える。<br />「File」-「New configuration」を実行<br />「Database」-「Add」を実行<br />
  36. 36. IBP Replicator Replication Managerでの設定<br />各データベースを設定する<br />※今回設定した内容<br /><1つ目><br />・Descriptive name:scale100-master<br />・Server:192.168.1.148:/mnt/xfs/firebird/SCALE100.25.FDB<br />・Administrative user name:sysdba<br />・Administrative password:masterkey<br />・Character set :UTF8<br /><2つ目><br />・Descriptive name:scale100-master<br />・Server: 192.168.1.148:/mnt/xfs/firebird/SCALE100.25.repl.FDB<br />・Administrative user name:sysdba<br />・Administrative password:masterkey<br />・Character set :UTF8<br />
  37. 37. IBP Replicator Replication Managerでのスキーマ設定<br />「New shcema」でスキーマを新規作成する<br />
  38. 38. IBP Replicator Replication Managerでのスキーマ設定<br />「Target database」を追加する<br />「Generate Tables, Keys and Fields」でレプリケーション<br />の定義を作成する<br />
  39. 39. IBP Replicator Replication Managerでのスキーマ設定<br />主キーのないテーブルの場合は注意が必要<br />Data columuns定義を解消して、Primary keys<br />定義を追加した<br />
  40. 40. レプリケーションのパフォーマンスへの影響<br />CentOS5.3上のDbBench-SCALE100データベース(約600MB)に対してレプリケーション無しの場合と、マスター/スレーブのフル・レプリケーションを実行中の二つの条件でTPC-Bテストを実行した。同時接続クライアント数は10で各1000トランザクションを実行した。<br />
  41. 41. データベースが破損した場合の対策<br />データベース破損に対しても、まずは本体付属のgfixで破損の状態を確認してみることになります。-vオプションと-nオプションを指定すると、エラーを発見して報告しますが修復はしないので、まず状況を確認という場合はこの二つを指定して実行します<br />&gt;gfix -user sysdba –festdin c:databasesample.fdb –v -n<br />Summary of validation errors<br /> Number of data page errors : 3<br /> Number of index page errors : 1<br /> -fオプションを指定した場合には、もう少し詳細なエラーが報告されます。調べる範囲が違うので、index pageのエラーが実はもう少し多かったことがわかります。<br />&gt;gfix -user sysdba -password masterkey c:databasesample.fdb -v -f<br />Summary of validation errors<br /> Number of record level errors : 431<br /> Number of data page errors : 3<br /> Number of index page errors : 4<br /> Number of database page errors : 24<br />
  42. 42. gfixでのデータベース破損の修復<br /> 破損してしまったデータベースは、gfixに-mオプションをつけて実行し、破損箇所をマークした上でgbakによるバックアップ/リストアを行うことでエラーを修復することが可能です。<br /> -vや-v –f オプションでも修復を試みますが、これは孤立ページをページインベントリから削除したり、逆に使用中にも関わらず未使用と記録されているページをページインベントリへ記録するなどのページレベルの修復に限られます。<br /> レコードレベルでの破損については、各レコードに「damaged」というラベルを付けておくに留まります。また、インデックスの破損については報告はされますが、修復はされません 。( Firebirdのソースコード中のsrc/jrd/validation.cppをご覧下さい。)<br />gfix -v -n<br />障害の有無を確認<br />障害対応手順<br />gfix -v -f<br />障害の詳細を確認<br />gfix -m<br />破損箇所のマーク<br />gbakでバックアップ+リストア<br />
  43. 43. Firebirdのページタイプ<br />Page-n<br />3-Transaction<br /> Inventory<br />
  44. 44. Firebirdのページ関連図<br />ページ0~2はヘッダ、ページ使用情報、使われていないWALページとなっている。その後、ページ3~5がシステムテーブルRDB$PAGEになっていて、この後に各システムテーブルが続く。<br />Page-0<br />1-Header<br />Page-1<br />2-PageInventory<br />Page-2<br />10-WAL<br />Page-3<br />4-Pointer<br />Page-4<br />6-IndexRoot<br />Page-5<br />5-Data<br />テーブルを辿る際には、テーブル名等からシステムテーブルRDB$RELATIONSに格納されるページ番号<br />を取得。ページ番号によって、システムテーブルRDB$PAGEに格納されるPointerPageとIndexRootページ<br />のページ番号を取得し、そこから各テーブルのDataPageやIndexPageを辿って行く。<br />リレーション名<br />RDB$RELATIONS<br />RDB$PAGES<br />DatePage<br />PointerPage<br />IndexPage<br />IndexRootPage<br />
  45. 45. IBFirstAID<br /> gfixで直しきれないデータベースの破損が発生した場合には、IBSurgeon社製のIBFirstAIDを利用して修復を試みます。起動すると「お金払って~!」といわれますが、まずは「Diagnosebeforebuy(free)」でDB破損の検証だけ無料で行えます。<br />IBFirstAIDの起動画面<br />
  46. 46. IBFirstAIDの実行画面<br />
  47. 47. Firebirdのパフォーマンス対策<br />Firebirdのパフォーマンス対策の第一歩は、実はエンジンの選択。SuperServerか、ClassicServerかという問題に加えて、2.5からはSuperClassicが選択肢に追加された。<br /><ul><li>Firebird2.5では、これまでの制約がほとんど取り除かれた。SuperClassicは過渡期の製品だけど、SuperServerとClassicServerのそれぞれの制約を超えるもの。どちかというと、Classicの代替製品なので、こういう名前になったのかも。
  48. 48. ファイルシステムの選択CentOSをはじめ、Linuxの各ディストリビューションではExt3がデフォルトのファイルシステム。Ext4をはじめ、新しいファイルシステムが提案されているが、しばらくはExt3が主流。ところが、こいつは遅い・・・
  49. 49. OSの選択Windowsなのか、Linuxなのか、はたまたMacOSXなのか、Soralisなのか。OS毎にパフォーマンスの出方が違う。Windowsはスレッドに強いが、プロセスに弱い。Linuxは真逆。Windowsの場合には、NTFSしか選択肢がないが、これはなかなかに早い。
  50. 50. インデックス統計情報の更新が自動では行われない。SETSTATISTICSの実行により、更新必要。カーディナリティの低いインデックスに、主キーを追加した複合インデックスを作成すると選択されるようになる(FB1.5まで)</li></li></ul><li>Firebirdのインデックス統計情報<br />Firebirdのインデックス統計情報は、システムテーブル RDB$INDEX_SEGMENTS で各インデックス毎に保持されている RDB$STATISTICSカラム が唯一のものです。RDB$STATISTICSには各インデックスのカーディナリティの逆数が格納されています。これはデータが一様に分布している理想的な条件下でのセレクティビティにあたります。<br />RDB$STATISTICS=0.020833<br />48都道府県全体<br />Nレコード<br />東京都 nレコード<br />セレクティビティ = n÷N<br />カーディナリティ = 48<br />
  51. 51. A36<br />Dmitry Yemanov<br />Firebirdのパフォーマンス対策<br />Firebird2.0の時代のDmitryYeamanovの結論Scaling Up: Searching for the Best Setup<br />Firebird 2.0 Classic on Linux<br /><ul><li>Use a 8K or 16K page size
  52. 52. Find (experimentally) an optimal page cache size
  53. 53. Calculate and set up LockMemSize accordingly
  54. 54. Play with LockAcquireSpins and test the performance
  55. 55. Consider FW=OFF with MaxUnflushedWrites = 1
  56. 56. Set up SortMemUpperLimit, if necessary
  57. 57. Monitor the lock table and increase LockHashSlots</li></ul>Slide 30<br />
  58. 58. A36<br />Dmitry Yemanov<br />Page Cache Performance for Writers<br />Slide 31<br />
  59. 59. A36<br />Dmitry Yemanov<br />CPU Scalability<br />Slide 32<br />
  60. 60. A36<br />Dmitry Yemanov<br />Concurrency: TPC-C benchmark<br />Slide 33<br />

×