インメモリ OLTP データベースにおける高可用性のサポートHigh Availability Support for In-Memory OLTP databases

適用対象: ○SQL Server XAzure SQL Database XAzure SQL Data Warehouse XParallel Data WarehouseAPPLIES TO: yesSQL Server noAzure SQL Database noAzure SQL Data Warehouse noParallel Data Warehouse

メモリ最適化テーブルを含んだデータベースは、ネイティブ コンパイル ストアド プロシージャの有無に関係なく、AlwaysOn 可用性グループで完全にサポートされます。Databases containing memory-optimized tables, with or without native compiled stored procedures, are fully supported with Always On Availability Groups. インメモリ OLTPIn-Memory OLTP オブジェクトを含んでいる場合とそうでない場合とでデータベースの構成とサポートに違いはありません。There is no difference in the configuration and support for databases which contain インメモリ OLTPIn-Memory OLTP objects as compared to those without.

インメモリ OLTP データベースが AlwaysOn 可用性グループ構成で配置されていると、再実行が行われたときに、プライマリ レプリカ上のメモリ最適化テーブルへの変更がメモリ内でセカンダリ レプリカ上のテーブルに適用されます。When an in-memory OLTP database is deployed in an Always On Availability Group configuration, changes to memory-optimized tables on the primary replica are applied in memory to the tables on the secondary replicas, when REDO is applied. つまり、データが既にメモリ内にあるため、セカンダリ レプリカへのフェールオーバーをすばやく実施できます。This means that failover to a secondary replica can be very quick, since the data is already in memory. これらのテーブルは、読み取りアクセス用に構成されたセカンダリ レプリカでのクエリにも利用できます。In addition, the tables are available for queries on secondary replicas that have been configured for read access.

AlwaysOn 可用性グループとインメモリ OLTP データベースAlways On Availability Groups and In-Memory OLTP Databases

インメモリ OLTPIn-Memory OLTP のコンポーネントを使ってデータベースを構成する利点を次に示します。Configuring databases with インメモリ OLTPIn-Memory OLTP components provides the following:

  • 完全に統合された環境 A fully integrated experience
    メモリ最適化テーブルを含んだデータベースは、同期と非同期のどちらのセカンダリ レプリカに対しても同じウィザードを使用して構成でき、同じサポート レベルが適用されます。You can configure your databases containing memory-optimized tables using the same wizard with the same level of support for both synchronous and asynchronous secondary replicas. 加えて、使い慣れた SQL Server Management Studio の AlwaysOn ダッシュボードを使用して、正常性の監視を行うことができます。Additionally, health monitoring is provided using the familiar Always On dashboard in SQL Server Management Studio.

  • 同等のフェールオーバー時間 Comparable Failover time
    持続性のあるメモリ最適化テーブルのインメモリ状態がセカンダリ レプリカで維持されます。Secondary replicas maintain the in-memory state of the durable memory-optimized tables. 自動フェールオーバーまたは強制フェールオーバーが発生した場合に復旧の必要がないため、新しいプライマリへのフェールオーバーにかかる時間はディスク ベースのテーブルと変わりありません。In the event of automatic or forced failover, the time to failover to the new primary is comparable to disk-bases tables as no recovery is needed. この構成では、SCHEMA_ONLY として作成されたメモリ最適化テーブルがサポートされます。Memory-optimized tables created as SCHEMA_ONLY are supported in this configuration. ただしそれらのテーブルに対する変更はログに記録されないため、セカンダリ レプリカ上の該当テーブルにはデータが不在となります。However changes to these tables are not logged and therefore no data will exist in these tables on the secondary replica.

  • [読み取り可能セカンダリ] Readable Secondary
    セカンダリ レプリカが読み取りアクセス用に構成されている場合、セカンダリ レプリカ上のメモリ最適化テーブルにアクセスしてクエリを実行することができます。You can access and query memory-optimized tables on the secondary replica if it has been configured for read access. SQL Server 2016 (13.x)SQL Server 2016 (13.x)では、セカンダリ レプリカ上の読み取りタイムスタンプは、プライマリ レプリカ上の読み取りタイムスタンプと同期に近い状態で保たれます。そのため、プライマリ レプリカへの変更はセカンダリに瞬時に反映されます。In SQL Server 2016 (13.x)SQL Server 2016 (13.x), the read timestamp on the secondary replica is in close synchronization with the read timestamp on the primary replica, which means that changes on the primary become visible on the secondary very quickly. この同期に近い動作は、 SQL Server 2014 (12.x)SQL Server 2014 (12.x) のインメモリ OLTP とは異なる点です。This close synchronization behaviour is different from SQL Server 2014 (12.x)SQL Server 2014 (12.x) In-Memory OLTP.

フェールオーバー クラスタリング インスタンス (FCI) とインメモリ OLTP データベースFailover Clustering Instance (FCI) and In-Memory OLTP Databases

共有記憶域構成で高可用性を実現するには、メモリ最適化テーブルを含んだ 1 つ以上のデータベースを管理するインスタンスに対してフェールオーバー クラスタリングを設定します。To achieve high-availability in a shared-storage configuration, you can set up failover clustering on instances with one or more database with memory-optimized tables. FCI を設定する際、次の要素を考慮する必要があります。You need to consider the following factors as part of setting up an FCI.

  • 目標復旧時間 Recovery Time Objective
    フェールオーバーの所要時間は長くなる可能性があります。データベースを使用可能な状態にするためには、メモリ最適化テーブルをメモリに読み込む必要があるためです。Failover time will likely to be higher as the memory-optimized tables must be loaded into memory before the database is made available.

  • SCHEMA_ONLY テーブル SCHEMA_ONLY tables
    フェールオーバー後、SCHEMA_ONLY テーブルは、データ行の存在しない空の状態になるので注意してください。Be aware that SCHEMA_ONLY tables will be empty with no rows after the failover. これは仕様であり、アプリケーションで定義された動作です。This is as designed and defined by the application. 1 つ以上の SCHEMA_ONLY テーブルを含む インメモリ OLTPIn-Memory OLTP データベースを再起動したときもまったく同じ動作となります。This is exactly the same behavior when you restart an インメモリ OLTPIn-Memory OLTP database with one or more SCHEMA_ONLY tables.

インメモリ OLTP におけるトランザクション レプリケーションのサポートSupport for transaction replication in In-Memory OLTP

トランザクション レプリケーションのサブスクライバーとして機能するテーブルは、ピア ツー ピア トランザクション レプリケーションを除き、メモリ最適化テーブルとして構成できます。Tables acting as transactional replication subscribers, excluding Peer-to-peer transactional replication, can be configured as memory-optimized tables. その他のレプリケーション構成はメモリ最適化テーブルとは互換性がありません。Other replication configurations are not compatible with memory-optimized tables. 詳細については、「 メモリ最適化テーブル サブスクライバーへのレプリケーション」を参照してください。For more information see Replication to Memory-Optimized Table Subscribers.

参照See Also

AlwaysOn 可用性グループ (SQL Server) Always On Availability Groups (SQL Server)
AlwaysOn 可用性グループの概要 (SQL Server) Overview of Always On Availability Groups (SQL Server)
アクティブなセカンダリ:読み取り可能なセカンダリ レプリカ (AlwaysOn 可用性グループ) Active Secondaries: Readable Secondary Replicas (Always On Availability Groups)
メモリ最適化テーブル サブスクライバーへのレプリケーションReplication to Memory-Optimized Table Subscribers