© 2014 aegif

第24回 Alfresco勉強会

2014年10月15日

コンテンツのライフサイクル

Jun Terashita

© 2014 aegif

発表の内容

2

Alfresco上にコンテンツ（ノード）が作成されてから完全に消えてなくなるまで、裏側で何が起こっているかをご説明します。

基本的には以下のBlogの翻訳になりますが、一部変わっている部分もあります。http://www.ixxus.com/blog/2011/09/alfresco-node-lifecycle

今回使用するバージョンAlfresco Community 4.2.f

© 2014 aegif

（準備）Alfrescoのリポジトリを構成する要素

3

ファイルシステム（FS）ファイル実体。デフォルトでは以下のディレクトリに保存される。・<install_dir>/alf_data/conetntstore

データベース（DB）コンテンツの属性情報やアソシエーション等、詳細情報が記録される。今回の内容で関係があるのは主に以下のテーブル。 ・alf_node・alf_node_properties・alf_content_data・alf_content_url

Luceneインデックス（IDX）検索用のインデックス。なくなっても上記の2つからリビルドすることが可能。デフォルトでは以下のディレクトリに保存される（Solrを選択した場合）。・<install_dir>/alf_data/solr/workspace/SpacesStore/index/ ・<install_dir>/alf_data/solr/archive/SpacesStore/index

© 2014 aegif

ライフサイクルの全体像

4

1

1. コンテンツ作成2. コンテンツ削除

3. ごみ箱から削除4. FSのクリーニング

5. DBのクリーニング

2 3 4 5

FS contentstore contentstote contentstore contentstore.deleted contentstore.deleted

DBalf_node

alf_node.properties alf_content_data alf_content_url

alf_node alf_node.properties alf_content_data alf_content_url

alf_node alf_node.properties alf_content_url

alf_node alf_node_properties

ー

IDX workspace/SpacesStore

archive/SpacesStore

ー ー ー

（※）関連レコードが存在するテーブルは他にもありますが主なテーブルのみ記載しています。

（※）

14日（default）30日（default）

© 2014 aegif

1. コンテンツ作成

5

ブラウザでAlfresco Shareを開き、適当なフォルダにコンテンツを作成する。

ノードブラウザで確認すると以下のようにファイル実体のパスやUUID、DBIDが確認できる。

DBID

ファイル実体のパスUUID

ストア

© 2014 aegif

1. コンテンツ作成

6

FS<install_dir>/alf_data/conetntstore 以下に日付で区切られたフォルダが作成され、そこにリネームして保存される（リネーム後のファイル名とノードのUUIDは別物である点に注意）。

© 2014 aegif

1. コンテンツ作成

7

DBalf_nodeテーブルから、alf_node_properties → alf_contente_data → alf_content_urlとたどり、ファイル実体のパスまで確認できる。

alf_node

alf_node_properties

qname_idがcm:contentのレコード

© 2014 aegif

1. コンテンツ作成

8

alf_content_data

alf_content_url

ファイル実体のパス

© 2014 aegif

1. コンテンツ作成

9

IDX Lukeでインデックスの内容を確認すると、workspace/SpacesStore/indexの中にDBIDが一致するインデックスが見つかる。

© 2014 aegif

2. コンテンツ削除

10

Alfresco ShareのUIから1で作成したコンテンツを削除する。

1と同様にノードブラウザから確認できる（ただし、ストアがarchiveになっている）。

DBID

ファイル実体のパス

UUID

ストア

© 2014 aegif

2. コンテンツ削除

11

FS変化なし。同じディレクトリに存在する。

© 2014 aegif

2. コンテンツ削除

12

DBalf_nodeテーブルのレコードが以下の2つになる。・store_idが「archive/SpacesStore」で、type_qname_idが「cm:content」・store_idが「workspace/SpacesStore」で、type_qname_idが「sys:deleted」

alf_node

alf_node_properties、alf_content_dataの関連レコードはidが変わる。 ただし、alf_content_urlの関連レコードはidもそのまま。（スクリーンショットは割愛します）

© 2014 aegif

2. コンテンツ削除

13

IDX archive/SpacesStore/indexの中にDBIDが一致するインデックスが見つかる（workspace/SpacesStore/index の中には見つからない）。

© 2014 aegif

3. ごみ箱から削除

14

ユーザプロファイルページからごみ箱を開き、コンテンツを削除する。

FS変化なし。同じディレクトリに存在する。

※この時点でノードブラウザからは確認できなくなる。

© 2014 aegif

3. ごみ箱から削除

15

DBalf_nodeテーブルのstore_idが「archive/SpacesStore」だったレコードのtype_qname_idが「sys:deleted」に変わる。

alf_node_propertiesにはoriginal idを保持するレコードがそれぞれ1つずつ。alf_content_dataの関連レコードは削除される。 alf_content_urlの関連レコードはorphan_timeにごみ箱を空にした時刻が記録される。

alf_node

alf_content_url

© 2014 aegif

3. ごみ箱から削除

16

IDX このタイミングでインデックスから完全に削除される。

© 2014 aegif

4. FSのクリーニング

17

contentStoreCleanerが定期的に実行され、alf_content_urlテーブルのorphan_timeから一定期間経過しているファイル実体を、contentstoreからcontentstore.deletedに移動する。

… # # Decide if content should be removed from the system immediately after being orphaned. # Do not change this unless you have examined the impact it has on your backup procedures. system.content.eagerOrphanCleanup=false # The number of days to keep orphaned content in the content stores. # This has no effect on the 'deleted' content stores, which are not automatically emptied. system.content.orphanProtectDays=14 # The action to take when a store or stores fails to delete orphaned content # IGNORE: Just log a warning. The binary remains and the record is expunged # KEEP_URL: Log a warning and create a URL entry with orphan time 0. It won't be processed or removed. system.content.deletionFailureAction=IGNORE # The CRON expression to trigger the deletion of resources associated with orphaned content. system.content.orphanCleanup.cronExpression=0 0 4 * * ? …

repository.properties

contentStoreCleanerのbean定義は、content-services-context.xmlを参照。 これを発火するのがcontentStoreCleanerTriggerとcontentStoreCleanerJobDetailで、scheduled-jobs-context.xmlに定義されている。

また、実行タイミングとorphan_timeからの保持期間はrepository.propertiesで設定されている。

（補足）

© 2014 aegif

4. FSのクリーニング

18

FSファイル実体がcontentstoreからcontentstore.deletedに移される。以降、contentstore.deletedの中身は自由に削除してよい。

DBalf_nodeおよびalf_node_propertiesは変化なし。alf_content_urlから関連レコードが削除される。

IDX「3. ごみ箱から削除」の時点でインデックスから削除されているため変化なし。

© 2014 aegif

5. DBのクリーニング

19

DeletedNodeCleanupWorkerが定期的に実行され、alf_nodeその他のテーブルのレコードを削除する。ここでは、alf_nodeでsys:deletedになっているレコードに対応するalf_transactionテーブルのcommit_time_msが一定期間経過しているものを抽出している。

… # Index tracking information of a certain age is cleaned out by a scheduled job. # Any clustered system that has been offline for longer than this period will need to be seeded # with a more recent backup of the Lucene indexes or the indexes will have to be fully rebuilt. # Use -1 to disable purging. This can be switched on at any stage. index.tracking.minRecordPurgeAgeDays=30 # Unused transactions will be purged in chunks determined by commit time boundaries. 'index.tracking.purgeSize' specifies the size # of the chunk (in ms). Default is a couple of hours. index.tracking.purgeSize=7200000 …

repository.properties

scheduled-jobs-context.xmlにnodeServiceCleanupJobDetailとnodeServiceCleanupTriggerのbean定義があり、cronExpressionはbean定義に直接書かれている。

また、ごみ箱を空にしてからの保持期間は、repository.propertiesに設定されている。

（補足）

© 2014 aegif

5. DBのクリーニング

20

FS「4. FSのクリーニング」の時点でファイル実体がcontentstoreからcontentstore.deletedに移されているため変化なし。

DBalf_node、alf_node_properties、alf_transaction等から関連レコードが削除される。

IDX 「3. ごみ箱から削除」の時点でインデックスから削除されているため変化なし。

© 2014 aegif

（再掲）ライフサイクルの全体像

21

1

1. コンテンツ作成2. コンテンツ削除

3. ごみ箱から削除4. FSのクリーニング

5. DBのクリーニング

2 3 4 5

FS contentstore contentstote contentstore contentstore.deleted contentstore.deleted

DBalf_node

alf_node.properties alf_content_data alf_content_url

alf_node alf_node.properties alf_content_data alf_content_url

alf_node alf_node.properties alf_content_url

alf_node alf_node_properties

ー

IDX workspace/SpacesStore

archive/SpacesStore

ー ー ー

（※）関連レコードが存在するテーブルは他にもありますが主なテーブルのみ記載しています。

（※）

14日（default）30日（default）

© 2014 aegif

すぐに削除しない理由

22

「4. FSのクリーニング」までファイルをcontentstoreに保持する理由・ファイルを一定期間contentstoreに保持することによって、DBとインデックスをバックアップからリストアする際に、ファイルシステムのリストアをする必要がなくなるため。・コンテンツ数が増えてくるとファイルシステムのリストアには時間がかかるため、時間の節約になる。・当然、DBとインデックスのバックアップは（デフォルトでは）14日以内のものである必要がある。

「5. DBのクリーニング」までalf_node等のレコードを保持する理由 ・インデックスの差分リビルドの際に、インデックスのバックアップ作成時点から削除されたコンテンツのインデックスを削除するため。・インデックスの差分リビルドにはalf_transactionテーブルに記録されたトランザクションを参照しており、alf_transactionとalf_nodeが繋がっているため、レコードが消えているとインデックスの更新ができなくなる。・当然、インデックスのバックアップは（デフォルトでは）30日以内のものである必要がある。

© 2014 aegif

おわり