SQL Server
SQL Server の高可用性を実現する
Zach Nichter
概要:
- ミラーリング
- データベース スナップショット
- ログ配布
- クラスタリング
- レプリケーション
この記事で使用しているコードのダウンロード: NichterHA2007_03.exe (151KB)
高可用性は、データベース管理者なら必ず知っておく必要がある概念です。高可用性とは、システムの応答性とアクセシビリティを意味します。高可用性を秒単位の応答時間で示す場合もあれば、1 秒の数分の 1 単位で示す場合
もあります。かつて、私がコンサルティング業務を請け負ったある会社では、Web サーバーで SQL クエリを使用してラウンドトリップ応答時間をミリ秒単位で取得する必要がありました。そこでは、応答が制限時間を超えると、データベース システムが停止していると判断し、Web サーバーは次に使用可能なデータベース サーバーに再接続するようになっていました。
ユーザーがますます高速なアプリケーションを求めるようになっているので、高可用性と高速な応答時間の実現方法を理解することは、データ依存アプリケーションの計画を成功させるために有益です。
SQL Server™ 2005 には、可用性を向上させるレプリケーション、クラスタリング、データベース ミラーリング、データベース スナップショット、データベース ログ配布などのさまざまなオプションがあります。この記事では、これらの機能について説明し、個別の環境に適したオプションを選択する際の判断方法を示します。まずは、SQL Server 2005 の可用性オプションを示した図 1 をご覧ください。
Figure 1 高可用性オプション
| テクノロジの属性 | レプリケーション | データベース ミラーリング | クラスタリング | データベース スナップショット | ログ配布 |
| 高可用性オプション | |||||
| 高いトランザクション要件に対応する | |||||
| リアルタイムのデータ可用性 | |||||
| データ イメージは読み取り専用 | |||||
| 固有のハードウェア構成 | |||||
| 低コスト | |||||
| データ復元機能 | |||||
| 自動フェールオーバー | |||||
| 実装および管理が複雑になる可能性がある | |||||
| パフォーマンスに関する検討事項 |
高可用性を定義する
高可用性アプリケーションを計画する際の最初の目標は、個別の環境における高可用性の意味を定義することです。組織によっては、高可用性とは、実稼動ハードウェアと同等の冗長ハードウェアを用意し、データとハードウェアのアップタイムおよび可用性を 99.995 以上確保しなければならないことを意味します。一方、データのみの高可用性を確保すればよく、フェールオーバーが必要になった場合も実稼動レベルのパフォーマンスをそれほど考慮しなくてもよい組織もあります。高可用性の定義は、状況に応じて適切なソリューションを選択するために重要です。
また、起こり得るシステム停止の種類を特定し、その停止がサービス レベル契約 (SLA) にどのような影響を及ぼすかを明示しておく必要もあります。可用性に影響する可能性がある停止には、計画的停止、計画外停止、パフォーマンス低下などがあります。
計画的停止は、通常、事前のユーザー通知のためにスケジュールされたメンテナンス ウィンドウが原因で生じるシステム停止です。計画外停止は、一般に、ハードウェアまたはソフトウェアの障害が原因でユーザーのデータ アクセスが停止する状態を指します。パフォーマンスの低下もシステム停止の原因となります。パフォーマンスが低下したかどうかは、通常、何らかの形式の SLA で企業や IT 部門との間で事前に合意されているエンドユーザーの応答時間によって判断されます。
システム停止の原因となり得る要素を特定する以外に、データのアクティビティ レベルや、常時オンラインである必要があるか、それとも時にはニアラインまたはオフラインでかまわないかも決める必要があります。また、可用性オプションを同じ敷地に置くか、遠隔地に置くかを決める必要があります。予算の制約も選択の要因になります。各可用性オプションを個別に検討していきましょう。
データベース ミラーリング
データベース ミラーリングの詳細を説明する前に、用語を定義しておきます。
プリンシパル は、トランザクション ログを継続的にミラー サーバーおよびデータベースに送信するデータベースが格納されるプライマリ実稼動サーバーです。
ミラー は、データベースのバックアップ コピーが格納されるセカンダリ サーバーです。ミラー コピーは、一貫してプリンシパル データベースと同期しています。
ロール は、個々のサーバーの用途 (プリンシパルまたはミラーのいずれであるか) を示します。
ウィットネス は、プリンシパル サーバーおよびミラー サーバーの機能の実行を監視するインスタンスであり、自動フェールオーバーを開始する機能があります。
パートナー は、プリンシパル サーバーまたはミラー サーバーのいずれかにすることができます。
一般的な環境では、プリンシパル データベースはプリンシパル インスタンス上でバックアップされ、そのバックアップがミラー インスタンス上で復元されます (図 2 を参照)。データベースの復元が完了したら、SQL Server Management Studio (SMSS) のプリンシパル データベースのプロパティ ウィンドウまたは T-SQL スクリプトを使用して、ミラーリングをプリンシパル サーバーに設定する必要があります。
Figure 2** Database mirroring architecture **(画像を拡大するには、ここをクリックします)
ミラーリングの設定が完了し、ミラーリング セッションが確立されると、プリンシパル データベースとミラー データベースが同期されます。次に、プリンシパル データベースは、ミラー上で最後にバックアップが適用されて以後に発生したイベントのトランザクション ログを送信します。ミラーはログを受信するとすぐに適用を試行します。SQL Server 2005 Enterprise Edition を使用している場合、このプロセスはマルチスレッドで処理され、それ以外の場合はシングルスレッドで処理されます。ログがミラーに適用されるとデータベースは同期されたものと見なされ、ミラー セッションが切断されるまでその同期は維持されます。
クライアントが新しいトランザクションを実行すると、プリンシパル サーバーはプリンシパル データベースに対してトランザクションを実行し、その間にトランザクション ログの記録がプリンシパル データベースからミラー データベースの REDO ログまたはログ キューに配布されて、そこから取得したログがミラー データベースに適用されます。トランザクションの適用が完了し、ミラー データベース上でコミットされると、トランザクションがミラー上でコミットされたことを通知する応答がプリンシパルに送信されます。プリンシパルは、ミラーから確認応答を受信した後に新しいトランザクションの存在を確認します。
障害が発生した場合、ミラーは自動フェールオーバーを開始し、プリンシパル データベースが使用可能であるかどうかを判断して、ウィットネスでプロセスをサポートすることができます。障害が発生した場合、ミラー パートナーで発生している問題を解決するまでは、そのミラー パートナーをプリンシパル パートナーとして使用することはできません。ミラー パートナーの問題を解決した後、ミラー パートナー サーバーへの復帰が開始され、データベースが再同期されます。同期が完了したら、ミラーリング セッションを再開できます。
このミラーリング モードは、トランザクションの安全性オプションを有効にして同期トランザクション処理を行う高安全性モードですが、自動フェールオーバーを利用せず、すべてのフェールオーバーを手動で開始するため、ウィットネスは不要です。同期トランザクション処理を行う 2 つ目のミラーリング モードは、高可用性モードです。高可用性モードでは、トランザクションの安全性オプションを有効にすると共に、ウィットネスを使用して、障害が発生した場合に自動フェールオーバーが行われるようにする必要があります。
3 つ目のミラーリング モードは、高パフォーマンス モードです。高パフォーマンス モードでは、非同期処理をサポートするためにトランザクションの安全性を無効にし、トランザクション レコードがミラーに書き込まれるまで待機しなくてもプリンシパル パートナー上のトランザクションをコミットできるようにします。高パフォーマンス モードではウィットネスの構成は不要です。
ミラーリングでは、プリンシパルとミラーには SQL Server の同一エディションを使用する必要がありますが、ウィットネスのエディションは同じである必要はなく、SQL Server Express Edition を使用することもできます。また、プリンシパル データベースを完全復旧モードにすることが重要です。
ADO.NET 2.0 が SQL Server 2005 に統合されて、データベース ミラーリングがサポートされ、アプリケーションをミラー環境に透過的にフェールオーバーできるようになりました。これにより、プリンシパル データベースに接続できない場合に、新たにコーディングや構成を行わなくても、ADO.NET アプリケーションを自動フェールオーバーすることが可能です。構成は、2 つの環境間の共通ユーザーとフェールオーバー パートナーを接続文字列に指定する場合と同程度に簡単です。ミラー データベース環境のフェールオーバー パートナーを指定する ADO.NET 接続文字列の例を次に示します。接続文字列のすべてのキーワードの詳細については、「SQL Native Client での接続文字列キーワードの使用」を参照してください。
"Provider=SQLNCLI.1;Data Source=MirrorDB;Failover Partner=SQL03;
Initial Catalog=AdventureWorks;
Persist Security Info=True;User ID=TestUser; Password=TestPswd; Pooling=True;
Connect Timeout=5;Application Name=ADOMirrorTest"
データベース ミラーリングはアプリケーションおよびデータの要件によっては有効なオプションですが、パフォーマンスの最適化に関して検討を要する事項がいくつかあります。たとえば、システムのトランザクション レートや変更されるデータ量がどの程度であるかを考える必要があります。データベース ミラーリングを検討する場合、データ量およびトランザクションの処理レートに対して、帯域幅とネットワーク速度が十分であるかどうかを判断することが不可欠です。また、リンクの飽和についても検討してください。この点は、ミラーが遠隔地に存在する場合に特に重要です。システムを事前に監視することは、ミラーリングの効率的な処理を妨げる環境上の制限の有無を確認するのに不可欠です。
データベース ミラーリングの特長は、低コストな選択肢であるということです。データベース ミラーリングのアーキテクチャでは、共有ディスクが不要であり、環境の運用に高度なスキルや専門性を必要としません。また、クラスタリングと異なり、データベース ミラーリングではパートナー同士で同じハードウェアを使用する必要がありません。さらに、ミラーリングは、データベースのプロパティ ウィンドウのミラーリング タブにあるセットアップ ウィザードを使って簡単に実装できます (図 3 を参照)。詳細については、go.microsoft.com/fwlink/?LinkId=80897 に掲載されているホワイトペーパーの記事「Database Mirroring Best Practices and Performance Considerations」(英語) を参照してください。
Figure 3** Mirroring setup wizard **(画像を拡大するには、ここをクリックします)
データベース スナップショット
データベース スナップショットは SQL Server 2005 Enterprise Edition で登場した新しいテクノロジですが、高可用性オプションが考慮されていません。データベース スナップショットは、他のテクノロジと併用した場合の復元またはレポート オプションとして使用してください。スナップショットは、特定時点のデータベースの読み取り専用ビューです。
スナップショットの作成には、次のように CREATE DATABASE コマンドを使用します。
CREATE DATABASE SnapDB_20061028_2030 ON
(NAME = SnapDB_Data, FILENAME =
'C:\Program Files\Microsoft SQL Server\MSSQL.1\MSSQL\Data\SnapDB_20061028_2030.snp')
AS SNAPSHOT OF SnapDB;
GO
データベース スナップショットを作成する際は、通常のデータベースで使用されるデータ ファイルではなく、スパース ファイルと呼ばれる 1 つまたは複数のファイルが使用されます。これらのスパース ファイルとは、基本的に、最初はデータが存在しない仮想の格納場所です。ソース データベースのデータが変更または削除された場合にのみ、スパース ファイルにデータが格納されます。スパース ファイルにデータが書き込まれるのは一度に 1 データ ページずつであり、データベース スナップショットには、そのスナップショットを取得して以後に変更されたデータのみが表示されます。それ以外のデータは、ソース データベースのデータ ページから取得されます。
データベース スナップショットのファイルは、スナップショット取得時のデータベース サイズで割り当てられます。割り当てられたサイズでは、実際のデータ サイズはわかりません。データ サイズを取得するには、次のような T-SQL ステートメントを実行します。
SELECT *
FROM fn_virtualfilestats(DB_ID(N'SnapDB_20061028_
2030'), 1);
GO
スパース ファイルおよびソース データベースのデータの格納方法のため、データベース スナップショットにアクセスすると、元のデータベースのデータ ファイルのデータ ページとスナップショットのスパース ファイルのデータ ページが取得されます。スナップショットは、データ ページを共有する必要があるため、そのスナップショットの取得元のソース データベースが存在するサーバー上にのみ格納できます。このアーキテクチャでは、ソース データベースの I/O が軽減されないため、データベースの実態を表さないスナップショットは、レポート オプションとしては有効ではありません。
データベース ミラーリングとスナップショットの併用を検討してください。この場合、データのレポート、ミラー、スナップショット データベースの機能をプリンシパル データベースから物理的に切り離すことが可能です。SQL Server エージェントおよびカスタム スクリプトを使用してデータベース スナップショットをスケジューリングし、スナップショットが定期的に更新されるようにします。図 4 のサンプル スクリプトは、この機能を実行するストアド プロシージャを示しています。このスクリプトは、環境内の特定のデータベースのスナップショットの作成および削除を管理するジョブの内部で使用するように設計されています。これで、レポート データが実稼動データから切り離されるため、使用に耐えるレポート ソリューションになります。
Figure 4 スナップショットをスケジュールするストアド プロシージャ
use msdb;
GO
set nocount on
GO
CREATE PROCEDURE usp_snaprefresh
@database sysname = NULL --name of the database to snapshot
,@keepsnap int = 24 --# of hours to keep a snapshot
--after it was created
--use a value of '0' to keep all
--existing snapshots
,@fileloc sysname --location for snapshot
= 'C:\Program Files\Microsoft SQL Server\MSSQL.1\MSSQL\Data\'
AS
DECLARE
@dt datetime ,@cnt int
,@databaseid int ,@snap sysname
,@sql nvarchar(1000) ,@yy varchar(4)
,@mm varchar(2) ,@dd varchar(2)
,@h varchar(2) ,@m varchar(2)
,@lname sysname ,@pname sysname
,@file sysname ,@pos1 int
,@pos2 int
-- initialize variables
SELECT
@dt = getdate()
,@cnt = 0, @pos1 = 0, @pos2 = 0
,@databaseid = db_id(@database)
-- check if valid database was provided
IF @databaseid IS NULL
BEGIN
RAISERROR ('Missing database name. Rerun the procedure specifying a
valid database name.',16,1)
RETURN (0)
END
--determine if snapshots should be kept
IF @keepsnap <> 0
BEGIN
-- determine if other snapshots exist for this server older than @
-- keepsnap value hrs
SELECT ROW_NUMBER() OVER(ORDER BY name DESC) AS [RowNum],
name INTO #t1
FROM master.sys.databases
WHERE source_database_id = @databaseid
AND create_date < dateadd(hh,-(@keepsnap),getdate())
IF (SELECT max(RowNum) FROM #t1 where name is not null) > 0
BEGIN
WHILE @cnt <= (SELECT max(RowNum) FROM #t1)
BEGIN
SELECT @snap = name FROM #t1 WHERE RowNum = @cnt
PRINT 'Dropping snapshot ''' + @snap + ''''
SET @sql = 'DROP DATABASE ' + @snap
EXEC(@sql)
SELECT @cnt = @cnt + 1
END
END
END
-- break apart point in time date time information for file name
SELECT @yy = convert(varchar(4),year(@dt)),@mm = convert(varchar(2),
month(@dt))
,@dd = convert(varchar(2), day(@dt)),@h = convert(varchar(2),
datepart(hh,@dt))
,@m = convert(varchar(2), datepart(mi,@dt))
-- piece together the database snapshot name and the file name
SELECT @file = @database + '_' + @yy + @mm + @dd + '_' + @h + @m
-- identify logical file name of primary data file
SET @sql = 'SELECT name INTO tempdb..t1
FROM ' + @database + '.sys.database_files
WHERE file_id = 1'
EXEC(@sql)
--setting logical filename for the snap
SELECT @lname = name FROM tempdb..t1
-- making sure the file location ends with '\'
IF substring(@fileloc, len(@fileloc), 1) <> '\'
BEGIN
SET @fileloc = @fileloc + '\'
END
-- build sql statement to be run
SET @sql = N'CREATE DATABASE ' + @file + ' ON
(NAME = ' + @lname + ', FILENAME = ''' + @fileloc + @file + '.snp'')
AS SNAPSHOT OF ' + @database
EXEC(@sql)
-- cleanup
DROP TABLE tempdb..t1;
GO
ただし、スナップショットはバックアップできませんし、ソース データベースなしでは存在し得ないものですから、データベース スナップショットは一時的な存在であるということを忘れないでください。スパース ファイルの容量が不足すると、スナップショットは破損したものと解釈されて削除されます。
また、データベース スナップショットを使用すると、ソース データベースのデータ ファイルからのスナップショット 1 つごとにデータ ページがスパース ファイルに書き込まれるため、ソース データベースのデータを変更するときにシステムのパフォーマンスが低下する場合があります。つまり、書き込み回数はデータベースが所有しているスナップショットの数の倍数になるということです。
読み取りアクセス許可はスナップショットの取得時にソース データベースによって定義され、変更はできません。スナップショットはデータ ページおよび同一のバッファ キャッシュをソース データベースと共有しているため、ソース データベースと同じインスタンスに存在する必要があります。
スナップショットをレポート ソリューションに使用することを検討するのは、ミラーリングの場合のみにしてください。それ以外の環境では、パフォーマンス上のメリットはありません。システム上で問題のある処理が実行されないかぎり、データベース スナップショットはデータを保持する最速の方法になる可能性があります。データベースをスナップショットの状態に戻したり、スナップショットから取得したデータでソース データベースのデータを置換することができます。
スナップショット データベースの命名標準を決める必要があります。私は originaldatabasename_date_time.snp という標準を使用しています。これで、ソース データベースを最初に指定し、次にスナップショットを取得した日付と時刻 (24 時間形式) を指定します。
ログ配布
ログ配布は、バックアップと復元を利用した低コストのソリューションを実現する、制限された高可用性オプションです。ログ配布では、トランザクション ログのバックアップをスケジュールされた間隔で実行して、セカンダリ データベースを最新の状態に保ちます。
SQL Server 2005 のログ配布では、ウィザードを使用して、セットアップ、スケジューリング、初期化、監視のプロセスを操作します (図 5 を参照)。このプロセスは単純で、数分で完了します。
Figure 5** Log shipping setup wizard **(画像を拡大するには、ここをクリックします)
プライマリ データベースを指定すると、スケジュールが作成され、バックアップ ファイルのファイル経過時間が決まります。次に、バックアップ ファイルのファイル共有を設定する必要があります。ファイル共有の設定が完了したら、セカンダリ データベース ファイルの場所を設定し、プライマリ データベースの復元を完了することによってデータベースを初期化する必要があります。バックアップ ファイルのコピー、トランザクション ログのバックアップの復元、および各手順に必要なアラートや遅延をスケジューリングすることも必要です。
設定が完了すると、ログ配布によりスケジュールされた間隔でデータベースのトランザクション ログが共有ネットワークの場所にバックアップされます。ファイルが共有に送信された後、設定されたスケジュールでセカンダリ データベースにバックアップが適用されます。
ログ配布は単純であるという利点から、さまざまな場面で有効です。これは、低コストで高トランザクション システムに対処する場合に適した高可用性オプションです。ログ配布に使用するセカンダリ データベースは読み取り専用モードで使用することが可能であるため、レポート データベースに便利です。ログ配布はオーバーヘッドが小さい代わりに、エラー処理時にアラート ポリシーが必要になります。
環境内でのログ配布の使用を検討する場合に考慮すべき点は、セットアップおよび管理が簡単であることと、専門的なスキルがほとんど不要であるということです。ログ配布はリアルタイムの高可用性ソリューションではありませんが、データベース ミラーリングと組み合わせてリアルタイム ソリューションを実現することが可能です。ログ配布の機能は、スケジュールと、バックアップ、ファイル コピー、復元などの操作によって制約されます。また、手動フェールオーバーが必要です。これらの理由から、ログ配布は時間要件が重視されない環境に適した単純なソリューションといえます。
SQL Server のクラスタリング
サーバー クラスタリングは OS レベルで動作し、ハードウェアの二重化や、クラスタのディスク リソースの共有によるアクセスを行います。クラスタリングは、エンドユーザーに対する侵入の可能性が低い代わりに高コストなオプションです。最低でも非クラスタ化インスタンスの数の 2 倍のハードウェアが必要になります。
クラスタリングの内容は非常に複雑なので、ここでは詳細には立ち入らず、全体的な概要を説明します。クラスタリングでは複数のサーバーを使用し、そのすべてに同一バージョンの OS (Windows® 2000 Advanced Edition または Datacenter Edition、あるいは Windows Server® 2003 Enterprise Edition または Datacenter Edition) をインストールする必要があります。Microsoft® クラスタ サービス (MSCS) もインストールする必要があります。MSCS は、サーバー間の共有リソースの所有権を処理し、IP アドレス、共有ディスク、およびネットワーク名を管理します。クラスタリングには、共有ディスク リソースも必要です。一般的な共有ディスク リソースの形態は、ストレージ エリア ネットワーク (SAN) または SCSI 接続ストレージです。
SQL Server インスタンスもリソースと見なされ、SQL Server 2005 Standard Edition および Enterprise Edition のいずれでもクラスタ構成にインストールできます。SQL Server 2005 Standard Edition および Enterprise Edition でサポートされる機能の一覧については、「SQL Server 2005 エディション別機能比較表」(microsoft.com/japan/sql/prodinfo/features/compare-features.mspx) を参照してください。
リソースをクラスタに設定すると、クラスタのセカンダリ ノードは、クラスタの 2 つのノード間のプライベート ネットワーク上に設定されたハートビートを使用して、プライマリ ノードとの定期的な通信を維持します。ハートビートは、プライマリ ノードで障害が発生しているかどうかを確認する間隔的なチェックポイントです。
プライマリ ノードで障害が発生した場合、リソースはセカンダリ ノードに移動し、論理サーバーの状態はそのまま残ります。これにより、クライアントは、ほんの一時の中断だけで通信を続けることができます。フェールオーバーの全プロセスは、クラスタ内のハードウェア、ソフトウェア、ネットワーク コンポーネントに応じて 5 ～ 30 秒前後で完了します。
クラスタリングは高コストで、システムの障害を解決するには専門的なスキルを要する複雑なテクノロジですが、何らかの自動フェールオーバー オプションを選択しているエンドユーザーに対してきわめてスムーズなフェールオーバーを提供します。個々のアプリケーションは多様であり、クラスタに対応していない場合や、互換性がない場合があるため、最悪の場合にはアプリケーションの再接続が必要になります。
レプリケーション
SQL Server 2005 では、レプリケーションも高可用性アーキテクチャに使用可能です。レプリケーションには、スナップショット、トランザクション、ピアツーピア、マージの 4 種類があります。ピアツーピアは、トランザクション レプリケーションの一形態なので、ここでは説明しません。
レプリケーションには、プライマリ データベースと全く同様に機能するセカンダリ サイトとセカンダリ データベースを用意して高可用性を実現するオプションがあります。それには、マージ レプリケーションを使用します。マージ レプリケーションでは、プライマリ データベースとセカンダリ データベースからトランザクションを取得し、2 つのデータベースの差分を相互にマージします。ご想像どおり、この構成では競合を解決する処理が必要です。
トランザクション レプリケーションの論理設計はデータベース ミラーリングとよく似ています。プライマリ データベースに適用するトランザクションをセカンダリ データベースに配布して、環境の整合性を確保します。配布されたトランザクションはセカンダリ データベースに適用され、次のトランザクションがシステム上で適用されるまで待機します。
スナップショット レプリケーションは、スケジュールされた間隔で実行され、コミットされるたびに個々のトランザクションを 2 つのシステムに適用するのではなく、セカンダリ データベースを一括更新するという点でログ配布とよく似ています。スナップショット レプリケーションとログ配布の利用方法はほぼ同じです。
レプリケーションには専門知識が必要であるため、専門のデータベース管理者が不在の環境では、これが大きな課題になります。レプリケーションのトラブルシューティングは複雑になる傾向があり、高可用性オプションとして使用する場合には設計も複雑になります。
レプリケーションは、高可用性ソリューションの要件を適切な方法で満たすことができます。このテクノロジでは、トランザクション レプリケーションを使用して、データベース ミラーリングの機能をレコード レベルで実現することが可能ですが、自動フェールオーバーのためのオプションはありません。十分なリソースと多少の工夫があれば、自動フェールオーバー ソリューションのスクリプトを作成することも無理ではありません。
データベース ミラーリングとは異なり、ソース データベースおよびターゲット データベースにクライアント アプリケーションから完全にアクセス可能です。レプリケーションは、スナップショット レプリケーションを使用したログ配布と同様の機能を果たします。
ただし、レプリケーションは実践証明済みのテクノロジであり、ドキュメントも整備されているという点も考慮に入れてください。レプリケーションを高可用性ソリューションとして使用するには短所もあり、パフォーマンスが問題になりますが、この問題はデータベース ミラーリングも同様です。レプリケーションを使用した高可用性ソリューションの設計は、管理が複雑になる傾向があります。必ずしも高度になるとはいえませんが、確実に複雑になります。また、データベース テーブルの構造が変更された場合や、レプリケーションの対象となるテーブルを追加する場合に、2 つのデータベースに変更を反映させるためにパブリケーションを中断して再定義する必要があるということも重大な課題です。
まとめ
個別の環境に適した高可用性ソリューションを構築するには、多少の創造性が必要だということがおわかりになったと思います。SQL Server 2005 高可用性テクノロジのそれぞれに長所と短所があり、どの方法が適しているかは状況によって異なります。
プライマリ Web データベースがセカンダリ データベース環境と離れた場所にある場合には、高パフォーマンス モードのログ配布、スナップショト レプリケーション、およびデータベース ミラーリングが適しています。セカンダリ データをリアルタイムに使用可能にする必要がない場合は特にこれらのオプションが有効です。
一方、セカンダリ データベースのリアルタイム データが必要な場合には、トランザクション レプリケーションまたはデータベース ミラーリングを使用すると、プライマリ サーバーのトランザクション レートが低い場合に負荷を分散して 2 つの環境間のリンクを高速化し、かつ飽和しなくなるようにすることができます。
これらのテクノロジの快適性も検討してください。いずれかのテクノロジを既に使用した経験があれば、なおよいでしょう。専門のデータベース管理者が不在な場合、レプリケーションのように変更が多く、トラブルシューティングが煩雑になりがちな複雑なテクノロジを使用しないで済む方法を検討してください。または、経験豊富な SQL Server コンサルタントに設計および実装の支援を依頼し、場合によっては、環境に適した新しい高可用性を管理するための人材トレーニングを委託することを検討してもよいでしょう。
求められる高可用性がデータの高可用率のみで、ダウンタイムが重大な問題とされる場合は、クラスタリングが適しています。
大事なことは、SQL Server 2005 には各種の環境に応じて高可用性を実装する新しいオプションが複数あるということです。1 つのオプションで事足りる場合もあるでしょうし、複数のテクノロジを組み合わせることも可能です。豊富な選択肢が用意されています。
Zach NichterSQL Server の専門家として 10 年以上の経験があります。これまでに DBA、チーム リーダー、マネージャ、コンサルタントなど、SQL Server に関する数々のサポートの役割を果たしてきました。現在は Levi Strauss & Co. の DBA 設計者として、主に SQL Server のパフォーマンス、監視、アーキテクチャ、およびその他の戦略的構想に携わっています。
© 2008 Microsoft Corporation and CMP Media, LLC. All rights reserved; 許可なしに一部または全体を複製することは禁止されています.