Plexは同時変更中に一貫性をどのように維持するか

Plexはデータベーストランザクションとファイル更新を調整することで状態を保護しますが、大量の同時変更が発生すると、競合や待ち時間の増加につながることがあります。

ライブラリのスキャン、メタデータの更新、視聴状態の更新、メンテナンスタスクは、それぞれ単独では正しい処理であっても重複して実行される場合があります。目的は同時実行をなくすことではなく、状態管理の経路を信頼できる状態に保ち、書き込み中に一貫性のないコピーを取得しないことです。同時実行そのものが破損の原因だと決めつける前に、ロック待ちとバックアップのタイミングを監視してください。

トランザクションは一貫性のために同時実行性を犠牲にする

2つの処理が競合するデータベース状態を必要とする場合、データベースが順序付けられた結果を保持できるよう、一方が待機しなければならないことがあります。目に見える症状は、必ずしもデータの誤りではなく、遅延やデータベースがビジー状態であるというメッセージです。

トランザクションが同じ状態をめぐって競合すると、ロック競合によってスループットが低下することがあります。保護されたデータに対する処理が、独立して進む代わりに待機しなければならないためです。

Plexのデータベースビジーメッセージと、スキャン、取り込み、ユーザー操作の発生状況を照合してください。待機が高負荷の書き込み処理中だけに発生する場合は、データベースが破損したと判断する前に、処理の重複を減らしてください。

WALと遅延書き込みによってタイミングは分かりにくくなる

トランザクションは論理的にコミット済みでも、ストレージ側では関連するキャッシュやライトバック処理が続いていることがあります。その状態を理解せずに稼働中のファイルをコピーすると、信頼性を判断しにくい一式を取得する可能性があります。

アプリケーションによる書き込みと物理的なフラッシュ処理の分離は、Linuxのライトバック動作に表れます。そのため、一見アプリケーションが静止していることだけでは、ファイルレベルのコピーの一貫性を保証する条件になりません。

バックアップでは、可能であればアプリケーションを認識した方法、または処理を静止させた時間帯を使用し、復元したデータベースを検証してください。「コピーコマンドが完了した」ことを「一貫性のある復旧ポイントが得られた」ことと同一視しないでください。

取り込みは、CPU全体が飽和していなくても競合を引き起こす

大量の項目を追加すると、ホスト全体の負荷が低く見える場合でも、データベースやメタデータへの書き込みが大量に発生することがあります。ボトルネックはCPU使用率ではなく、状態へのシリアル化されたアクセスである可能性があります。

取り込みが高負荷になっている間は、ホストのCPUやディスク使用率が全体として飽和していなくても、データベースビジー待ちが発生することがあります。

取り込み処理を一時停止し、影響を受けたクエリやナビゲーション操作を再実行してください。待機が解消する場合は、書き込み量の多いタスクを、インタラクティブ操作が最も多い時間帯から外してスケジュールしてください。

Featured

ZimaCube 2 パーソナルクラウドホームNAS

ZimaCube2

$799.00 - $2,499.00

Buy Now

復旧対象の状態と再構築可能なデータを分ける

データベースと永続的なメタデータは、一時的なトランスコードファイルやキャッシュファイルよりも厳格にバックアップを扱う必要があります。これらを区別せず1つのボリュームに混在させると、一貫性の確認や復元テストが難しくなります。

信頼できる復旧ポイントには、サーバーを再起動するために必要な永続的なデータベースとメタデータの状態が保持されていなければなりません。一時的なキャッシュやトランスコードファイルには、同じ復旧クラスは必要ありません。

本番環境ではないインスタンスで、取得した状態コピーからの復旧をテストしてください。永続的なコンテナデータの配置により、Plexのランタイムを置き換える際にも、永続データの境界を保ちやすくなります。