2.2.1   PostgresForestクラスタ環境

PostgresForestJDBCドライバがアクセスして、実際にデータを格納するのが PostgresForestクラスタ環境で、２台のPostgreSQLサーバで構成されます。 この２台のPostgreSQLサーバは、それぞれが以下に示す２つのデータベース を持っています。また２台のPostgreSQLサーバは、PostgresForestJDBCドラ イバの動作によって、常にレプリケーションされています。

ユーザデータベース:	PostgresForestを利用しているJavaアプリケーションが、実際に使用する データを格納するためのデータベースです。Javaアプリケーションが PostgresForestJDBCドライバで更新処理を行う場合、両方のPostgreSQL サーバのユーザデータベースに同一の更新を行うことで、常にユーザデータ ベースの内容をレプリケーションしています。
管理データベース:	PostgresForestJDBCドライバが動作するために必要なユーザデータベースの 整合性に関する情報や、設定情報など、各種メタデータを格納している データベースです。

2.2.2   PostgresForest-BackendUtility

PostgresForestクラスタ環境を運用する上で必要になるツール類です。この中 には、

• 管理情報作成用スクリプト
• PostgreSQL用ロック待ちタイムアウトパッチ
• オンラインリカバリツール

が含まれています。

2.2.3   PostgresForestJDBCドライバ

JDBC準拠のAPIを提供するライブラリ（JARファイル）として提供されている、 PostgresForest本体となるJDBCドライバです。このJDBCドライバは、上述した クラスタ環境にアクセスして適切に負荷分散やアクセスコントロールを行い ます。ユーザには縮退などを意識させることなく、容易に高可用性を得ること ができます。

サポートされるAPIの一覧は、API一覧のドキュメントを参照してください。

3.2.1   ノード間デッドロックとは

ユーザアプリケーションから更新SQLなどが実行された場合、PostgresForest JDBCは、PostgresForestクラスタを構成する2つのPostgreSQLサーバに、順序 性無くSQLを発行します。そのため、次のような問題が発生する場合があります。

App1とApp2の２つのアプリケーションが、ほぼ同時に「lock tableA」という SQLを発行したとします。確率的にですが、次のような動作順序になる可能性 があります

1. App1 が PostgreSQLサーバ1 のtableAのロックを取得
2. App2 が PostgreSQLサーバ2 のtableAのロックを取得
3. App1 が PostgreSQLサーバ2 のtableAのロックを取得待ち（App2が取得したロックの解放待ち）
4. App2 が PostgreSQLサーバ1 のtableAのロックを取得待ち（App1が取得したロックの解放待ち）

この場合、App1、App2共に、それ以降処理が進まなくなります。また、双方の PostgreSQLサーバにとって単純なロック待ちであり、デッドロックとは認識 されません。そのため、PostgreSQLの持つデッドロックの機構が働かず、２つ のアプリケーションは永久に互いのロック取得を待ち続けることになります。

PostgresForestで提供しているロック待ちタイムアウトパッチは、「長時間 ロック取得ができずに待つ状態」を異常状態とみなし、強制的にロックを解除 したうえで、エラーを返却するようにします。

3.3.1   待ち受けポート設定

PostgresForestJDBCは、PostgresForestクラスタ環境とTCPソケットにて通信を 行います。そのため、PostgreSQLに対してJDBCドライバを動作させるサーバから TCPソケットで通信できるように設定する必要があります。

postgresql.conf の listen_address のパラメータで、PostgreSQLが待ち 受けを行うインターフェースを指定します。

例:

listen_addresses = '*'

上記の例では全てのインターフェースで待ち受けを可能にします。

postgresql.conf の詳細については、PostgreSQLドキュメントを参照して ください。

3.3.2   アクセスコントロール設定

pg_hba.conf でホストのアクセス制御の設定をおこないます。以下の ユーザデータベースの作成 、 管理情報データベースの作成 で作成する データベースに、アクセス可能な設定とする必要があります。

例:

host    all         all         192.168.1.0/24      trust

上記の設定を行うと、「192.168.1.0/24」ネットワークからPostgreSQLサーバ へのアクセスを、無条件で許可することができるようになります。

postgresql.conf の詳細については、PostgreSQLドキュメントを参照して ください。

3.3.3   ロック待ちタイムアウトの設定

PostgresForest-BackendUtilityに含まれるロック待ちタイムアウトパッチを PostgreSQLに対して適用した場合、何秒間ロック待ちをした場合にエラーと するかを設定する必要があります。

postgresql.conf に、独自パラメータを追加します。

設定例:

lock_timeout = 30s

上記設定により、PostgreSQL内部でロックが取得できない場合に、ロックを取得 できるまで待つ時間を30秒間だけ許容し、それを経過するとエラーを返却する ようになります。

この設定値はクラスタを構成する各系で異なる値とすることを推奨します。 ロック待ちとなっている片方のトランザクションがエラーとなり、 もう一方のトランザクションはロック待ちから解放されて処理が継続されます。

3.3.4   リカバリツール用設定

オンラインリカバリツールを使用する場合、次の設定をすべて施している必要 があります。

PostgreSQLをアーカイブモードで動作させるように、 postgresql.conf の 下記の設定を変更します。

archive_mode = on

アーカイブモードをONとした場合、アーカイブコマンドを設定する必要があり ます。平常時（リカバリ実行時以外）にアーカイブログを取得する必要がなけ れば、「true」コマンド（常に0を返却するLinuxコマンド）を設定しておけば アーカイブログのローテーションなどを考慮する必要がなくなります。

archive_command = 'true'

PostgreSQLのアーカイブログを取得するような運用設計となっている場合、 この設定変更は必要ありません。（その場合はリカバリコマンド使用時のコン フィグレーションを変更する必要があります）

アーカイブログを保存するためのディレクトリを、PostgresForestクラスタの データベースディレクトリ以下に作成します。

$ mkdir ~/forestdata/pg_archive

3.6.1   PostgresForestJDBCが動作していない場合

データ移行時やメンテナンス時などで、PostgresForestJDBCドライバを使用する アプリケーションが動作していない場合、 psql などのPostgreSQL標準の ユーティリティを使用して、テーブル・データの作成・更新を行うことができ ます。但しこの場合、必ず双方のPostgreSQLサーバに対して同様の操作を行い、 全てのデータを同一にする必要があります。

3.6.2   PostgresForestJDBCが動作している場合

PostgresForestJDBCドライバが１つでも動作している場合、 psql などの PostgreSQLのコマンドでユーザデータベースに対して更新を行うことはできま せん。

PostgresForestJDBCドライバを使用したサービス（アプリケーション）が動作 している中でデータを操作（バッチ処理等）をしたい場合、それらもPostgres ForestJDBCドライバを使用したアプリケーションとして作る必要があります。

5.1.1   正常状態

このPostgreSQLサーバ上のユーザデータベースに対して、問題なく更新が 行われており、整合性が取れている状態です。管理情報データベース中の server_info テーブルの udb_validity の値が 1 となっている 場合が該当する状態です。

5.1.2   不整合発生状態

このPostgreSQLサーバ上のユーザデータベースは異常があると判断されて います。そのため、PostgresForestJDBCはこのPostgreaSQLサーバ上のユーザ データベースをアクセスする対象とはしていない状態です。管理情報データ ベース中の server_info テーブルの udb_validity の値が -1 となっている場合が該当する状態です。

5.1.3   処理抑制状態

オンラインリカバリツールを動作させている際に発生する状態です。正常状態 のPostgreSQLサーバからデータを取得し、不整合発生状態のPostgreSQLサーバ にそのデータを適用している際に、アプリケーションがトランザクションを 開始するのを一時的に停止させていることを意味する状態です。管理情報 データベース中の server_info テーブルの udb_validity の値が 0 となっている場合が該当する状態です。（これはオンラインリカバリ 中のみのステータスです）

PostgresForestクラスタ環境では、ユーザデータベースへのアクセス中に、双方 のPostgreSQL間で整合性が崩れる問題が発生すると、問題が発生したPostgreSQL サーバ上にあるユーザデータベースへのアクセスを自動的に停止します。

「不整合発生状態」となった場合には、すみやかに何らかの対応を行わなくて はなりません。そのため、PostgresForestクラスタ環境を監視している必要が あります。

8.2.1   オンラインリカバリの必須前提条件

オンラインリカバリツールは、以下のような条件を満たしている場合にのみ使用 することができます。

• リカバリ用設定が施されている

  リカバリツール用設定 に記載されたアーカイブモードの設定をして いる必要があります。

• 管理情報の読み込み設定が有効になっている

  管理情報読み込み間隔 に記述している、管理情報の定期更新が行われ ている必要があります。

• 片系縮退の状態であること

  片方のPostgreSQLサーバ上のユーザデータベースのみが不整合発生状態と して認識されている場合以外は使用できません。

• アプリケーションがオンラインリカバリに対応した作りになっていること

  開発者ガイドの「SET句などを使用した場合のオンラインリカバリの制限」 に記載したように、SET句などのコネクションの状態を変更するSQLを使用 していないアプリケーションである必要があります。

pgha_recovery.conf の設定次第で、様々な環境でのリカバリが可能です が、以下で解説する設定内容（下記手順）は、次の条件を満たしている場合に のみ有効に動作します。

• 両系のPostgreSQLサーバが別の物理マシン上で動作している
• 両系のPostgreSQLサーバが同一の設定で動作している (ポート番号設定やアクセスコントロールの設定などを含む)
• 両系のPostgreSQLのバイナリ(pg_ctlなど)が同一パスに存在する
• 両系のPostgresForestクラスタのデータディレクトリ、アーカイブログディレクトリが同一パスに存在する
• 両系のPostgreSQLが同一のシステムユーザ名で起動されている

これ以外（例えば、双方のPostgreSQLが同一筺体内で動作している等）の場合、 下記の設定ではオンラインリカバリはできません。

8.2.2   想定リカバリ環境

server_infoテーブルが以下に定義されるような環境で、オンラインリカバリを 実施することとします

 serverid |          udb_url          | udb_validity
----------+---------------------------+--------------
        0 | 192.168.1.100:5432/userdb |            1
        1 | 192.168.1.101:5432/userdb |           -1

serverid=1 側のPostgreSQLサーバ上のユーザデータベースが、不整合発生 状態となっているため、 serverid=0 側のユーザデータベースの内容を もとにして、 serverid=1 側のユーザデータベースを復旧する、という リカバリを実施します。

8.2.3   事前設定

PostgresForest-BackendUtilityに含まれるrecoveryツールの設定ファイルを 環境に合わせて編集します。双方のPostgreSQLサーバ上で、設定ファイルの 書き換えが必要です。

デフォルトのpgha_recovery.conf:

# directory definition
pg_dir="/home/forest/pg831-lt"
dbcluster_dir="/home/forest/forestdata"
archivexlog_dir="${dbcluster_dir}/pg_archive"

# access definition
pg_user="forest"
pg_db="template1"
pg_port="5432"
src_pg_host="192.168.1.101"
dst_pg_host="192.168.1.102"

# server configuration
#  - size of archived wal file must be 16MByte
archive_command="cp %p ${archivexlog_dir}/%f"
restore_command="cp ${archivexlog_dir}/%f %p"

# timeout definition
#  - max time[sec] for transaction(s) to idle
idle_wait_timeout=20
archive_wait_timeout=10

# command for base recovery
base_recovery_command="/usr/bin/scp -24qp -r ${dbcluster_dir} ${dst_pg_host}:${dbcluster_dir%/*}"

# command for sync recovery
sync_recovery_command="/usr/bin/scp -24qp -r ${archivexlog_dir} ${dst_pg_host}:${dbcluster_dir}"

# command for startup instance at recovery node
instance_startup_command="/usr/bin/ssh -24q ${dst_pg_host} ${pg_dir}/bin/pg_ctl start -w -D ${dbcluster_dir} -l ${dbcluster_dir}/pgsql.log"

環境に合わせて、各変数値を変更します。 オンラインリカバリの必須前提条件 を全て満たしている環境で使用する 場合、以下の項目のみを編集することで動作します。

続いて、必要に応じてPostgreSQLのログインパスワードをファイルに記述します。 オンラインリカバリツールは、その動作中に何度もPostgreSQLに接続し、データ ベースの内容を参照・更新します。 アクセスコントロール設定 で、無条件に ログイン可能としている場合は必要ありませんが、パスワード認証などを選択 している場合、頻繁にPostgreSQLへのログインパスワードの入力を求められる ことになるため、オペレーションミスをすることでリカバリを失敗することを 防ぐためにも、用意をすることが望ましいです。

記述するファイルは .pgpass というファイル名で、OSユーザのホームディ レクトリ直下に配置します。今回の例では、 /home/forest/.pgpass に配置 します。

設定例:

$ echo '*:*:*:forest:forest_pass' > ~/.pgpass
$ chmod 600 ~/.pgpass

これにより、PostgreSQL内部ユーザ「forest」でPostgreSQLにアクセスしよう とした場合、自動的に「forest_pass」というパスワードで接続処理が行われる ことになります。

.pgpass の詳細については、PostgreSQLドキュメントを参照して ください。

また、 pgha_recovery.conf に記述した内容からもわかる通り、２つの PostgreSQLを動作させているホスト間で、SSHやSCPなどによる通信を何度も 実行することになります。そのため、その都度SSHやSCPのログインパスワード を入力する必要が出てくることから、オペレーションミスをすることで リカバリが失敗することを防ぐためにも、SSH/SCPでパスワード入力をせずに 済むよう、ログイン用鍵交換を実施しておくことが望ましいです。 （あるいはSSH/SCPなどのログインが必要な方式ではなく、rsh/rcpなどの ログインの必要がないコマンドを選択するという方法もあります）

SSHの鍵交換の方法については、本ドキュメントでは省略します。

上記のデフォルトの設定ファイルでは、 両系で全く同じ postgresql.conf ファイルにより 稼働させている場合に利用できますが、異なる postgresql.conf ファイルを 利用している場合にも対応したサンプル設定ファイルも用意しています。

8.2.4   リカバリの実施

1. 障害を取り除く

リカバリを開始する前に、縮退が発生した原因を取り除く必要があります。 （例えば、ディスクが溢れた状況であればディスク使用量を減らす、ネット ワークが断線したのであれば、それを修正する、等）

2. 復旧対象のPostgreSQLを停止

復旧対象（serverid=1 側）のPostgresForestクラスタを構成するPostgreSQL が起動しているかを確認し、起動しているようであれば、停止します。

停止例:

$ ~/pg831-lt/bin/pg_ctl stop -m f -D ~/forestdata

3. 復旧対象のPostgreSQLのデータディレクトリ削除

復旧対象（serverid=1 側）のPostgresForestクラスタを構成するPostgreSQL のデータディレクトリを削除します。（あるいは別の場所に退避するなどして データディレクトリを配置する場所に何もない状態にしておきます）

$ rm -rf ~/forestdata

4. 復旧元でオンラインリカバリコマンドを実施する

正常状態のPostgreSQL側で、復旧のためのコマンドを実行します。 PostgresForest-BackendUtilityに含まれる、 PGHARecovery.sh コマンド を実行します。

書式:

./PGHARecovery.sh [ -all | -base | -closevm | -sync | -recovery | -openvm | -cleanup | -cancel ] [CONFIGFILE]

通常は、 -all 、 -cleanup のみ（失敗時には -cancel ）を使用し ます。各オプションの詳細については、オンラインリカバリツールのドキュ メントを参照してください。

復旧元では -all オプションを使用してリカバリを実行します。

実行例:

$ ./PGHARecovery.sh -all ./pgha_recovery.conf
----------------------------------------
online recovery (base) started
----------------------------------------
- reloading postgresql.conf for recovery...
- reloading postgresql.conf for online...
current configuration : archive_mode = on
current configuration : archive_command = true

(... 省略 ...)

[ OK ]
- removing archived WAL file(s)...
[ OK ]
----------------------------------------
online recovery (cleanup) successful
----------------------------------------

----------------------------------------
execute -cleanup for recovery node
----------------------------------------

このメッセージが出た段階で、復旧元から復旧対象へのデータの転送、JDBCの 更新抑制、データ差分是正、復旧対象へのJDBCコネクション復活、更新抑制解除 が完了しており、リカバリはほぼ完了しています。

5. 復旧対象側でのオンラインリカバリコマンドの実施

復旧対象側で、オンラインリカバリ実施用の不要データを収集する設定になって いるためその解除を行います。

実行例:

$ ./PGHARecovery.sh -cleanup ./pgha_recovery.conf

6. （必要あれば）パスワードファイルを削除

事前設定 で記述した .pgpass ファイルを削除します。このファイル が存在している場合、PostgreSQLに無条件にログインできることになって しまうため、リカバリの際以外は削除しておくことが必要です。

実行例:

$ rm ~/.pgpass

8.2.5   リカバリに失敗する場合

前項4.の、復旧元でオンラインリカバリコマンドを実行する、の際に、エラー が発生した場合、一旦リカバリの実施をキャンセルし、エラーが発生した原因を 排除した上で再度リカバリを実施します。

キャンセル:

$ ./PGHARecovery.sh -cancel ./pgha_recovery.conf

キャンセル後、エラーが発生する原因を取り除いた後に、再度 リカバリの実施 の 手順2より実行してください。

リカバリに関する手順のミスや設定のミス以外で、リカバリツールが実行に 失敗する原因として、リカバリ実行中のアプリケーションからのSQL実行 （トランザクション）の関係があります。リカバリツールは、アプリケーション からの新規トランザクションを抑制し、既存のトランザクションが全て処理 し終わるのを待ちます。そのため、仮に時間内にトランザクションが全て終了 しなかった場合には、リカバリの実行に失敗します。この場合も上記の方法で 再度リカバリを行ってください。

但し、開発者ガイドの「トランザクション時間によるオンラインリカバリの制限」 に書かれているように、長時間のトランザクションばかりのアプリケーション や、トランザクションをプーリングするアプリケーションの場合、オンライン リカバリツールは成功しません。

9.3.1   初期状態における設定値

9.4.1   初期状態における設定値

10.2.1   管理情報読み込み間隔

global_configテーブル の mngdb_read_duration 列の値によって、 管理情報の定期更新時間間隔が設定できます。この時間間隔で、管理情報の 定期読み込みが行われるため、管理情報データベース上の各種設定を変更した 場合には、最低限この時間が経過した後に、PostgresForestJDBCドライバが 変更後の設定値で動作するようになります。

この設定値が0となっている場合、PostgresForestJDBCドライバは管理情報の 定期読み込みを実施しません。

注意：PostgresForestJDBCドライバが動作中に、1度でもこの設定値を0 （あるいは負数）とした場合、そのPostgresForestJDBCドライバは管理情報 の定期読み込み処理を完全に停止します。一度アプリケーションを停止する などしてPostgresForestJDBCドライバの動作を停止しない限り、管理情報の 再読み込みは行われなくなります。

以下の制限が許容できる場合、この設定値を0とすることができます。

• PostgresForestJDBCドライバが動作しているJava Virtual Machine がただ １つのみであることを保障できる環境であること
• オンラインリカバリ機能を使用する必要がないこと
• PostgresForestJDBCドライバが動作中に設定値を動的に変更する必要がない こと

10.2.2   縮退対象エラーの設定

PostgresForestJDBCドライバは、双方のPostgreSQLに対してアクセスをする中 で縮退させるべきエラーが発生した場合に、そのエラーが発生したユーザデータ ベースに不整合が発生したとして、縮退処理を行います。

どのエラーを受け取った時に縮退とするかを決定するのが、 global_configテーブル の broken_error_prefix です。

デフォルト（管理情報データベースを作った直後）の値は 08,53,57P,3D となっています。この値は、PostgreSQLから返されるエラーコードの値の うち、縮退としたいエラーコードの先頭部分をカンマ区切りで列挙したもの です。

デフォルト値の場合であれば、``08xxx`` （接続の異常）、 53xxx （リソース不足）、 57Pxx` （外部コマンドによる接続拒否）、 ``3Dxxx （データベースが存在しない） といった場合に縮退処理を行います。

この値は、基本的に変更する必要はありませんが、特定の問題が発生しやすい 環境であり、その場合には縮退をさせたくない、あるいは縮退をさせたい、 といった場合にカスタマイズが可能です。但しその場合には、影響について 十分に考慮する必要があります。

例えば、テーブルが存在しない場合に返るエラー 42P01 を縮退対象に 含めた場合と含めない場合の影響について考えてみましょう。

• 含めた場合

  この場合、仮にあるテーブルにアクセスできなかった場合には、その PostgreSQLサーバ上のユーザデータベースに不整合があると判断して縮退を 行うことになります。オペレーションミスなどで、片方のPostgreSQLサーバ 上のテーブルのみを削除してしまった場合、そちら側のPostgreSQLサーバ にはそれ以降アクセスしなくなり、もう片方のサーバのみで処理を継続する ため、アプリケーションには影響が出ません。

  しかしながらアプリケーションの開発中などは、テーブル名を間違えてアク セスするなどケースが考えられます。。また、テーブルを動的に変更する アプリケーションの場合、動作最中にテーブルが無くなることは十分考え られます。こういった事態が発生するたびに、縮退が発生してしまいます。

• 含めない場合

  この場合、仮にあるテーブルにアクセスできなかった場合に、それ自体には 問題ないと判断して縮退処理を行いません。動的にテーブルを変更しうる アプリケーションなどの場合には、この設定にしないと頻繁に縮退が発生 してしまいます。

  しかし、オペレーションミスなどで片方のPostgreSQLサーバ上のテーブルを 削除してしまった場合などには問題が発生します。テーブルが無い方の ユーザデータベースにアクセスし続けるものの、削除してしまったテーブル には当然アクセスできないため、アプリケーションはエラーを返されること になってしまい、アプリケーションとして処理継続ができなくなってしまう 可能性があります。

10.2.3   APIの実行タイムアウト

ネットワーク回線が経路の途中で物理的に切断された場合や、通信対象のマシン が突然電源断した場合など、その検出に非常に時間がかかります。これは、OS のソケット実装仕様・設定によります。``RedHat Enterprise Linux5``の標準 状態では、検出までに数十分かかります。

PostgreSQLのJDBCドライバの場合、アプリケーションからのAPI実行時にネット ワークの無応答が発生した場合、OS側で検出するまで完全に応答がなくなって しまい、アプリケーションが停止します。

PostgresForestの場合、OS側でのネットワーク異常の検出機構だけでなく、 PostgresForest独自にタイムアウトの設定を設けることによって、より迅速に ネットワーク無応答に対応できるようになります。この時間設定が、 local_configテーブル の、``query_exec_timeout`` パラメータです。

この設定値は、PostgreSQLにアクセスする全てのAPI実行時に同一のタイムアウ ト時間を設定します。

11.1.1   SQL実行時間が非常に長い環境でのネットワーク障害

ネットワークの切断などに対して、OSが異常を検知するまでには時間がかかり ますが、PostgresForestの場合は独自のタイムアウトをもうけることによって より迅速にネットワーク障害を検出して縮退処理を行うことができる、という ことは APIの実行タイムアウト に記述したとおりですが、SQLの実行時間が 非常に長い場合、あるいはSQLの実行時間が全く見積もれないようなデータ内容 の場合、このパラメータによってネットワーク無応答に類する障害への対応 時間を短くすることが困難になります。APIの実行時間の設定値よりも実行に 時間がかかると、異常が発生したと認識して縮退するためです。

そのため、このような場合にはAPIの実行時間の設定を行わず、OS側でネット ワーク障害を検知させます。OS側で障害を検知するまで、PostgresForestは 無応答になってしまいます。

OSのレイヤでネットワークの障害をより早く検知するためには、カーネルの パラメータを変更する方法がありますが、そのホスト上の全てのネットワーク アプリケーションに影響が出ることを認識する必要があります。

11.1.2   スプリット

下図のようなネットワーク構成で、HUB1とHUB2を繋ぐネットワークが故障した 場合には、PostgresForestクラスタはデータベース全体として不整合を発生 させることになります。

┌───┐        ┌───┐
│Host1 │        │Host2 │
│(App1)│        │(App2)│
└─┬─┘        └─┬─┘
    │                │
┌─┴─┐        ┌─┴─┐
│ HUB1 ├────┤ HUB2 │
└─┬─┘        └─┬─┘
    │                │
┌─┴─┐        ┌─┴─┐
│Host3 │        │Host4 │
│(PG1) │        │(PG2) │
└───┘        └───┘

HUB1とHUB2の間のネットワークが故障した場合、Host1上のアプリケーション （PostgresForestJDBC）は、Host3のPostgreSQLのみにアクセス可能なため、 Host3のPostgreSQL上のユーザデータベースにのみアクセスし続けます。 対して、Host2上のアプリケーション（PostgresForestJDBC）は、Host4の PostgreSQLのみにアクセス可能なため、Host4のPostgreSQL上のユーザデータ ベースにのみアクセスし続けます。結果として、双方のアプリケーションが 各々に孤立した情報を参照・更新し続けてしまい、データベースとしての 整合性がなくなってしまいます。