|
| |
| Sun Java™ System Directory Server 5 2004Q2 管理ガイド | |
第 9 章
ディレクトリスキーマの拡張Directory Server には、数多くのオブジェクトクラスおよび属性を持つ標準のスキーマが付属しています。通常の作業では標準のオブジェクトクラスと属性で十分ですが、新しいオブジェクトクラスや属性の作成など、スキーマの拡張が必要となることもあります。標準スキーマの概要と、配備に合わせたスキーマの設計方法については、『Directory Server 配備計画ガイド』の第 3 章「Directory Server スキーマ」を参照してください。
この章では、スキーマの拡張方法について、次の項目ごとに説明します。
スキーマ検査スキーマ検査を有効にすると、インポート、追加、変更のすべての処理が Directory Server によって、次のように現在定義されているディレクトリスキーマに準拠するようになります。
デフォルトではスキーマ検査が有効になっています。Directory Server の起動中は、常にスキーマ検査を有効にしてください。多くのクライアントアプリケーションでは、スキーマ検査を有効にしておくことは、すべてのエントリがスキーマに準拠しているものと見なされます。しかし、スキーマ検査を有効にしても、ディレクトリ内の既存のコンテンツが検証されるわけではありません。ディレクトリのすべての内容がスキーマに確実に準拠するようにするには、エントリを追加する前、またはすべてのエントリを再初期化する前にスキーマ検査を有効にする以外に方法はありません。
スキーマ検査を無効にするのは、スキーマに準拠していることが確実な LDIF ファイルのインポートを高速で処理するときだけです。しかし、その場合、スキーマに準拠しないエントリがインポートされるリスクがあり、この違反は検出されません。
エントリがスキーマに準拠していない場合は、このエントリを検索することはできず、そのエントリに対する変更処理も失敗します。エントリがスキーマに準拠するようにするには、次の処理を行う必要があります。
- サーバーが運用環境にある場合は、サーバー全体を読み取り専用にして、スキーマ検査が無効の状態で変更が行われないようにします。「グローバルな読み取り専用モードの設定」を参照してください。
- 後述する方法でスキーマ検査を無効にします。
- エントリを検索し、そのエントリと現在定義されているスキーマを手動で比較して、準拠していない原因を特定します。「属性の表示」および「オブジェクトクラスの表示」を参照してください。
- スキーマに準拠するようにエントリを修正します。
準拠していないエントリが多い場合に、それらのエントリにパターンがあったり、新しいデータ形式が採用されているときは、エントリではなくスキーマの変更を検討します。ただし、スキーマへの変更を最小限にするために、配備前にスキーマを計画する必要があります。詳細については、『Directory Server 配備計画ガイド』の第 3 章「Directory Server スキーマ」を参照してください。
- 後述する方法でスキーマ検査を有効にします。
- グローバルな読み取り専用モードを有効にしていた場合は、これを無効にします。
コンソールからのスキーマ検査の設定
コマンド行からのスキーマ検査の設定
cn=config エントリの nsslapd-schemacheck 属性を使用して、スキーマ検査の有効/無効を切り替えることもできます。
新しいスキーマ検査ポリシーは、サーバーによって直ちに適用されます。
スキーマ拡張の概要スキーマに新しい属性を追加する場合は、それらの属性を持つオブジェクトクラスを新しく作成する必要があります。必要な属性のほとんどが含まれている既存のオブジェクトクラスに対して、新たに必要となった属性を追加すると、LDAP クライアントとの相互運用性が低下するためです。
Directory Server と既存の LDAP クライアントとの相互運用性は、標準の LDAP スキーマに依存しています。標準スキーマを変更すると、サーバーのアップグレード時にも問題が発生します。同様の理由から、標準スキーマの要素を削除することはできません。
オブジェクトクラス、属性、およびディレクトリスキーマと、スキーマ拡張のガイドラインについては、『Directory Server 配備計画ガイド』の第 3 章「Directory Server スキーマ」を参照してください。標準の属性とオブジェクトクラスについては、『Directory Server Administration Reference』の第 9 章「Object Class Reference」および第 10 章「Attribute Reference」を参照してください。
Directory Server スキーマは、cn=schemaエントリの属性内に格納されます。設定エントリと同様に、これは、サーバーの起動中にファイルから読み取られる、スキーマの LDAP ビューです。スキーマ ファイルは、次の場所にある LDIF ファイルです。
このディレクトリには、Directory Server が使用する標準のスキーマと、Directory Server に依存するその他の Sun Java System サーバーのファイルが含まれます。これらのファイルについて詳細は、『Directory Server Administration Reference』の第 9 章にある「Schema Supported by Directory Server 5.2」を参照してください。標準のスキーマ自体は、『Directory Server Administration Reference』の第 9 章「Object Class Reference」および第 10 章「Attribute Reference」で説明しています。
スキーマファイルの変更
サーバーは、起動時に 1 回だけスキーマファイルを読み取ります。スキーマのメモリ内の LDAP ビューの cn=schema 内にファイルの LDIF の内容が追加されます。スキーマ定義の順序には意味があるため、スキーマファイルの名前の先頭には番号がつけられ、英数字順に読み込まれます。このディレクトリに含まれるスキーマファイルには、インストール時に定義されたシステムユーザーだけが書き込み処理を実行できます。
ファイル内のスキーマ定義を変更するには、該当するファイルを作成または変更し、サーバーを再起動する必要があります。スキーマファイル内の定義の構文については、RFC 2252 (http://www.ietf.org/rfc/rfc2252.txt) を参照してください。
スキーマを LDIF ファイルに直接定義するときは、X-ORIGIN フィールドの値として 'user defined' を指定することはできません。この値は、cn=schema の LDAP ビューで定義されるスキーマ要素用に予約されており、これは 99user.ldif ファイルに表示されます。
99user.ldif ファイルには、cn=schema エントリと、コマンド行またはコンソールから追加されたすべてのスキーマ定義の追加 ACI が含まれます。新しいスキーマ定義を追加すると、99user.ldif ファイルは上書きされます。このファイルを変更するときは、変更が永続的に適用されるように、サーバーを直ちに再起動する必要があります。
他のスキーマファイルに定義されている標準のスキーマを変更することはできません。ただし、新しいファイルを追加して、新しい属性やオブジェクトクラスを定義することはできます。たとえば、複数のサーバーに新しいスキーマ要素を定義するには、98mySchema.ldif という名前をファイルにその要素を定義し、このファイルをすべてのサーバーのスキーマディレクトリにコピーします。次にすべてのサーバーを再起動して、新しいスキーマファイルを読み込みます。
コマンド行からのスキーマの変更
スキーマは cn=schema 内の LDAP ビューによって定義されるため、ldapsearch ユーティリティおよび ldapmodify ユーティリティを使用してスキーマをオンラインで表示、変更することができます。しかし、変更できるスキーマ要素は、X-ORIGIN フィールドに 'user defined' という値が設定されている要素だけです。サーバーは、その他の定義に対するすべての変更処理を拒否します。
attributeTypes 属性と objectClasses 属性の値を個別に追加、削除するには、ldapmodify を使います。これらの属性は複数の値をとるので、1 つの値を変更するには、その値を削除してから新しい値を追加する必要があります (「複数値属性の 1 つの値の変更」を参照)。スキーマ要素は、RFC 2252 (http://www.ietf.org/rfc/rfc2252.txt) で説明されている構文で定義します。
新しい要素の定義とユーザー定義の要素に対する変更は、99user.ldif ファイルに保存されます。
コマンド行からのスキーマ定義の変更は、正確な入力が必要な値が長いため、エラーを生じがちです。しかし、ディレクトリスキーマの更新が必要なスクリプトにこの機能を指定することができます。
コンソールからのスキーマの変更
ディレクトリスキーマをカスタマイズするときは、ここで説明する Directory Server コンソールを使う方法をお勧めします。コンソールには標準スキーマが表示され、グラフィカルインタフェースを使用して新しい属性やオブジェクトクラスを定義したり、定義した要素を編集することができます。
新しい要素の定義とユーザー定義の要素に対する変更は、99user.ldif ファイルに保存されます。
ディレクトリスキーマを拡張するには、次の手順を実行します。
- 「属性の作成」で説明している手順に従って新しい属性を作成します。
- 次に、オブジェクトクラスを作成し、そのオブジェクトクラスに新しい属性を追加します。詳細は、「オブジェクトクラスの作成」を参照してください。
属性定義の管理Directory Server コンソールでは、スキーマに含まれるすべての属性を表示し、ユーザー独自の属性定義を作成、編集、削除します。
属性の表示
現在ディレクトリスキーマにあるすべての属性に対して、その関連情報を表示するには、次の手順を実行します。
- Directory Server コンソールの最上位の「設定」タブで、設定ツリーの「スキーマ」ノードを選択します。次に、右側のパネルで「属性」タブを選択します。
このタブには、スキーマ内のすべての標準属性 (読み取り専用) およびユーザー定義属性のテーブルが含まれています。テーブルの行の上にマウスを置くと、属性についての説明が表示されます。
次の表は、属性テーブルのフィールドを示しています。
表 9-1 「属性」タブのテーブルの列
列の見出し
内容
名前
属性の名前。属性のタイプと呼ぶ場合もある
OID
属性のオブジェクト識別子。OID はスキーマオブジェクトを一意に識別する文字列で、通常は小数点で区切られた数値
OID や、企業のプレフィックスの取得依頼については、IANA (Internet Assigned Number Authority) のアドレス iana@iana.org 宛てにメールを送るか、または IANA の Web サイト http://www.iana.org/ を参照
構文
構文はこの属性値に使用できる形式を示す。属性の構文は、表 9-2 に示す
複数値
この列のチェックボックスで、属性に複数の値を指定できるかどうかを指定する。複数値属性は、エントリ内に何回でも現れるが、単一値属性は 1 回しか現れない
表 9-2 属性の構文の定義
構文名
定義
Binary (以前は bin)
属性値がバイナリデータとして扱われることを示す
Boolean
属性値が True または False のどちらか一方であることを示す
Country String
属性値が、ISO 3166 に定められている 2 文字の国コード (たとえば FR) に限定されていることを示す
DN (以前は dn)
属性値が DN (識別名) であることを示す
DirectoryString
(以前は cis)属性値が UTF-8 方式で符号化された文字を含み、大文字と小文字が区別されないことを示す
GeneralizedTime
属性値が印刷可能な文字列として符号化されることを示す。タイムゾーンを指定する必要がある。GMT を使用するのが望ましい
IA5String (以前は ces)
属性値が ASCII 文字のサブセットだけを含み、大文字と小文字が区別されることを示す
INTEGER (以前は int)
有効な属性値が数字であることを示す
OctetString
Binary と同じ
Postal Address
属性値が次のように符号化されていることを示す
dstring[$ dstring]*
各 dstring コンポーネントは DirectoryString 構文の値と同様に符号化される。dstring 内の円記号とドル記号は、行区切り文字と間違えられることがないように、引用符で囲む。多くのサーバーで、postal address は最大 30 文字の 6 行に制限されている。たとえば、次のようにする
1234 Main St.$Anytown, CA 12345$USA
TelephoneNumber (以前は tel)
属性値が電話番号の形式であることを示す。国際形式の電話番号を使用することを推奨する
URI
属性値が URL を含み、オプションとして http://、https://、ftp://、ldap://、ldaps:// などのプレフィックスを持つことを示す。URI 値は、IA5String と同じように動作する。RFC 2396 (http://www.ietf.org/rfc/rfc2396.txt) を参照
属性の作成
ユーザー独自の属性定義をスキーマに追加するときは、次の手順を実行します。
- Directory Server コンソールの最上位の「設定」タブで、設定ツリーの「スキーマ」ノードを選択します。次に、右側のパネルで「属性」タブを選択します。
- 「作成」をクリックして「属性の作成」ダイアログを表示します。
- テキストフィールドに次の情報を指定して、新しい属性を定義します。必須項目は、属性名と構文だけです。
- 属性名 : 属性を一意に識別する名前を入力します。属性タイプとも呼ばれます。属性名はアルファベットから始まる必要があり、ASCII 文字、数字、ハイフンだけが有効です。
注
属性名に大文字を使うこともできますが、LDAP クライアントでは区別されません。RFC 2251 (http://www.ietf.org/rfc/rfc2251.txt) のセクション 4.1.4 にも定められているように、属性名の大文字と小文字は区別されません。
- 属性の OID (オプション): 属性のオブジェクト ID を入力します。OID については、表 9-1 を参照してください。OID を指定しない場合、Directory Server は自動的に attributeName-oid を使用します。LDAP v3 に厳密に準拠するには、有効な数値 OID を指定する必要があります。
- 属性のエイリアス (オプション): 属性の別名をコンマで区切って入力します。
- 属性の説明 (オプション): 属性の目的を示す短い説明を入力します。
- 構文 : 属性に保持させるデータを記述するための構文を、ドロップダウンメニューから選択します。使用可能な構文については、表 9-2 を参照してください。
- 複数値: デフォルトでは、属性は複数の値をとります。属性がエントリごとに 1 つの値だけを持つように設定するときは、チェックボックスの選択を解除します。
- 「属性の作成」ダイアログの「了解」をクリックして、新しい属性を定義します。この属性は、ユーザー定義の属性のテーブルに表示されます。
ディレクトリエントリ内のこの属性に値を定義する前に、「オブジェクトクラス定義の管理」で説明している手順に従って、その属性を必要とする、またはその属性を許可するオブジェクトクラスを作成または編集する必要があります。
属性の編集
編集できる属性は、ユーザー定義の属性だけで、コンソールを使う必要があります。属性の名前、構文、または複数値の設定を変更する前に、ディレクトリ内のどのエントリも現在この属性を使用していないことを確認します。使われている属性を変更すると、クライアントはそのエントリにアクセスできなくなります。
属性のスキーマ定義を変更するには、次の手順を実行します。
属性の削除
削除できる属性は、ユーザー定義の属性だけで、コンソールを使う必要があります。属性の定義を削除する前に、ディレクトリ内のどのエントリも現在この属性を使用していないことを確認します。使われている属性を削除すると、クライアントはそのエントリにアクセスできなくなります。
属性のスキーマ定義を削除するには、次の手順を実行します。
オブジェクトクラス定義の管理Directory Server コンソールでは、スキーマに含まれるすべてのオブジェクトクラスを表示し、ユーザー独自のオブジェクトクラス定義を作成、編集、削除します。
オブジェクトクラスの表示
現在定義されているすべてのオブジェクトクラスに関する情報を表示するには、次の手順を実行します。
- Directory Server コンソールの最上位の「設定」タブで、設定ツリーの「スキーマ」ノードを選択します。次に、右側のパネルで「オブジェクトクラス」タブを選択します。
このタブには、スキーマ内のすべての標準 (読み取り専用) およびユーザー定義のオブジェクトクラスがリスト表示されます。
- 表示するオブジェクトクラスをリストから選択します。
このタブのその他のフィールドには、選択しているオブジェクトクラスに関する次の情報が表示されます。
表 9-3 「オブジェクトクラス」タブのフィールド
フィールド
内容
必須属性
このオブジェクトクラスを使用するエントリ内の必須属性のリスト。リストには継承された属性が含まれる
許可された属性
このオブジェクトクラスを使用するエントリ内の許可された属性のリスト。リストには継承された属性が含まれる
親
親オブジェクトは、あるオブジェクトクラスの属性と構造の継承元であるオブジェクトクラスを識別する。オブジェクトクラスは、必要な属性と許可される属性を自動的に親オブジェクトクラスから継承する
OID
オブジェクトクラスのオブジェクト識別子。OID はスキーマオブジェクトを一意に識別する文字列で、通常は小数点で区切られた数値
OID や、企業のプレフィックスの取得依頼については、IANA (Internet Assigned Number Authority) のアドレス iana@iana.org 宛てにメールを送るか、または IANA の Web サイト http://www.iana.org/ を参照
オブジェクトクラスの作成
別のオブジェクトクラスから継承する複数のオブジェクトクラスを作成するときは、最初に親オブジェクトクラスを作成する必要があります。新しいオブジェクトクラスがカスタム属性を使用するときは、その属性も事前に定義しておく必要があります。
注
コンソールからは、構造化オブジェクトクラスだけを作成できます。これらのオブジェクトクラスは、親から継承する必要があります。auxiliary および abstract オブジェクトクラスを定義するには、コマンド行ユーティリティを使用します。
ユーザー独自のオブジェクトクラスの定義をスキーマに追加するときは、次の手順を実行します。
- Directory Server コンソールの最上位の「設定」タブで、設定ツリーの「スキーマ」ノードを選択します。次に、右側のパネルで「オブジェクトクラス」タブを選択します。
- 「作成」をクリックして「オブジェクトクラスの作成」ダイアログを表示します。
- テキストフィールドに次の情報を指定して、新しいオブジェクトクラスを定義します。
- 名前 : オブジェクトクラスの一意の名前を入力します。
- 親 : 親となる既存のオブジェクトクラスを選択します。デフォルトでは、「トップ」が選択されます。他のオブジェクトクラスから継承しないオブジェクトクラスでは、これを選択する必要があります。親から継承される必要属性と許可される属性、および親は、対応するリストに表示されます。
一般に、ユーザーエントリに対して属性を追加する場合、親オブジェクトは inetOrgPerson オブジェクトクラスになります。企業エントリに対して属性を追加する場合、親オブジェクトは通常 organization または organizationalUnit になります。グループエントリに対して属性を追加する場合、親オブジェクトは通常 groupOfNames または groupOfUniqueNames になります。
- OID (オプション): オブジェクトクラスのオブジェクト ID を入力します。OID については、表 9-3 を参照してください。OID を指定しない場合、Directory Server は自動的に objectClassName-oid を使用します。LDAP v3 に厳密に準拠するには、有効な数値 OID を指定する必要があります。
- 新しいオブジェクトクラスを使用するエントリに含まれる属性を定義します。
- 「オブジェクトクラスの作成」ダイアログの「了解」をクリックして、新しいオブジェクトクラスを定義します。定義したオブジェクトクラスは、ユーザー定義のオブジェクトクラスのテーブルに表示され、これを使用してエントリを定義できるようになります。
オブジェクトクラスの編集
編集できるオブジェクトクラスは、ユーザー定義のオブジェクトクラスだけで、コンソールを使う必要があります。オブジェクトクラスの定義を変更する前に、ディレクトリ内のどのエントリも現在このオブジェクトクラスを使用していないことを確認します。使われているオブジェクトクラスを変更すると、クライアントはそのエントリにアクセスできなくなります。
オブジェクトクラスのスキーマ定義を変更するには、次の手順を実行します。
- Directory Server コンソールの最上位の「設定」タブで、設定ツリーの「スキーマ」ノードを選択します。次に、右側のパネルで「オブジェクトクラス」タブを選択します。
- 「ユーザー定義のオブジェクトクラス」リストから編集するオブジェクトクラスを選択し、「編集」をクリックします。
- 「オブジェクトクラスの編集」ダイアログのフィールドを修正し、オブジェクトクラスを再定義します。
オブジェクトクラスの名前や OID を変更することはできません。これらの情報を変更するには、そのオブジェクトクラスを削除し、新に作成する必要があります。
- 親 : 親となる既存のオブジェクトクラスを選択します。親から継承される必要属性と許可される属性、および親は、対応するリストに表示されます。
- 必須属性を定義するときは、「利用可能な属性」リストから属性 (1 つまたは複数) を選択し、「必須属性」ボックスの左にある「追加」ボタンをクリックします。
- 許可された属性を定義するときは、「利用可能な属性」リストから属性 (1 つまたは複数) を選択し、「許可された属性」ボックスの左にある「追加」ボタンをクリックします。
- すでに追加されている属性を削除するときは、いずれかのリストで属性を選択して強調表示し、対応する「削除」ボタンをクリックします。親オブジェクトクラスから継承された必須属性および許可された属性は、どちらも削除できません。
- オブジェクトクラスの編集が完了したら「了解」をクリックして変更を保存します。
オブジェクトクラスの削除
削除できるオブジェクトクラスは、ユーザー定義のオブジェクトクラスだけで、コンソールを使う必要があります。オブジェクトクラスの定義を削除する前に、ディレクトリ内のどのエントリも現在このオブジェクトクラスを使用していないことを確認します。使われているオブジェクトクラスを削除すると、クライアントはそのエントリにアクセスできなくなります。
オブジェクトクラスのスキーマ定義を削除するには、次の手順を実行します。
スキーマ定義のレプリケーション2 つのサーバーの間で 1 つまたは複数のサフィックスのレプリケーションを設定するたびに、スキーマも自動的にレプリケートされます。これにより、コンシューマにレプリケートされる可能性のあるすべてのオブジェクトクラスと属性を定義する、完全で同一のスキーマがすべてのレプリカに提供されます。このため、マスターサーバーもマスタースキーマを持ちます。
すべてのレプリカにスキーマを適用するには、すべてのマスターでスキーマ検査を有効にする必要があります。スキーマは、LDAP 処理が行われるマスターで検査されるため、コンシューマの更新時は検査の必要はありません。パフォーマンスを向上させるために、レプリケーションメカニズムではコンシューマレプリカでのスキーマ検査を行いません。
注
ハブと専用コンシューマでは、スキーマ検査を無効にすべきではありません。コンシューマでは、スキーマ検査を行なってもパフォーマンスには影響しないので、レプリカの内容がスキーマに準拠していることを確認するため、常に有効にしておく必要があります。
マスターサーバーは、コンシューマの初期化時と、コンソールまたはコマンド行ツールを使用してスキーマを変更するたびに、スキーマを自動的にコンシューマにレプリケートします。デフォルトでは、スキーマ全体がレプリケートされ、コンシューマ側にまだ存在しないスキーマ要素があれば、コンシューマ側に作成され、99user.ldif ファイルに保存されます。
たとえば、マスターサーバーの起動時に 98mySchema.ldif ファイルにスキーマ定義が含まれ、その後でマスター、ハブ、専用コンシューマのいずれかのサーバーとのレプリケーションアグリーメントを定義したと仮定します。このマスターからレプリカを初期化すると、レプリケートされたスキーマには 98mySchema.ldif からの定義が含まれますが、レプリカサーバー側の 99user.ldif にもこの定義が格納されます。
コンシューマの初期化時にスキーマがレプリケートされた後で、マスター側の cn=schema でスキーマを変更すると、マスターはスキーマ全体をコンシューマにもレプリケートします。このように、コマンド行ユーティリティまたはコンソールからマスタースキーマに加えた変更は、コンシューマにレプリケートされます。これらの変更はマスター側の 99user.ldif に保存され、上記メカニズムによって、コンシューマ側の 99user.ldif にも格納されます。
レプリケートされたスキーマファイルの変更
レプリケーションメカニズムでは、スキーマを含む LDIF ファイルに直接加えた変更は検出されません。このため、「スキーマファイルの変更」で説明した方法でスキーマを更新した場合は、マスターの再起動後もコンシューマにはレプリケートされません。
スキーマファイル内の変更をコンシューマに強制的に適用するために、Directory Server 5.2 には次のスクリプトが用意されています。
マスターサーバー上でスキーマファイルを修正するときは、次の手順を実行します。
- 次のスキーマディレクトリに新しいスキーマファイルを追加するか、既存のスキーマファイルを編集します。
ServerRoot/slapd-serverID/config/schema
このディレクトリに含まれるスキーマファイルには、インストール時に定義されたシステムユーザーだけが書き込み処理を実行できます。詳細は、「スキーマファイルの変更」を参照してください。
- 前述のように schema_push.pl スクリプトを実行します。このスクリプトは、実際にレプリカにスキーマを送信するわけではありません。このスクリプトを実行すると、スキーマファイルに特別な属性が書き込まれ、ロードとほぼ同時にスキーマファイルがレプリケートされます。
- サーバーを再起動します。サーバーはすべてのスキーマファイルをロードし、レプリケーションメカニズムによって、新しいスキーマが各コンシューマにレプリケートされます。
スキーマレプリケーションの制限
デフォルトでは、レプリケーションメカニズムによってスキーマがレプリケートされるたびに、スキーマ全体がコンシューマに送信されます。次の 2 つの状況では、この処理は望ましくありません。
- コンソールまたはコマンド行から cn=schema に加える変更は、ユーザー定義のスキーマ要素だけに対象が限定され、すべての標準スキーマは変更されません。スキーマを頻繁に変更する場合、未変更のスキーマ要素を含む大規模な要素セットを毎回送信することはパフォーマンスに影響します。ユーザー定義のスキーマ要素だけをレプリケートすることで、レプリケーションとサーバーのパフォーマンスを向上できます。
- Directory Server 5.2 のマスターから Directory Server 5.1 のコンシューマにレプリケートする場合、これらのバージョンの設定属性のスキーマに違いがあるため、競合が発生します。この場合、次の方法でユーザー定義のスキーマ要素だけをレプリケートする必要があります。
ユーザー定義のスキーマだけがレプリケートされるようにスキーマレプリケーションを制限するには、次のコマンドを使います。
必要に応じてデフォルト値の off を使うことで、スキーマ全体をレプリケートできます。