Plexはアップグレードを壊さずに外部データベースを使用できますか？
Plex がそのランタイムパスとアップグレード時の移行を明示的にサポートしていない限り、本番環境で Plex のネイティブデータベースを外部エンジンに置き換えないでください。
PostgreSQL や MySQL に行を移行することは分析に役立つ場合がありますが、インポートが正常に完了したからといって、Plex がそのエンジンを安全に読み取り、書き込み、移行、修復、アップグレードできるとは限りません。アプリケーションは、独自のスキーマ動作と同梱ツールを前提としています。ネイティブデータベースを運用上の正本として維持し、レポートには外部コピーを使用してください。ランタイムの置き換えは、完全なロールバック手順を用意した使い捨ての実験として扱いましょう。
外部データベースをサポート対象外のアーキテクチャ変更として扱う
Plex は同梱データベースの動作とアプリケーションデータの配置を前提に設計されているため、ライブラリデータベースを PostgreSQL や MySQL に移すことは、通常のサポート対象設定への切り替えではありません。コミュニティプロジェクトによってデータを移行できることが示されていても、将来のリリースを通じて Plex サーバーが外部エンジンを安全に使用できることを意味するわけではありません。
SQLite から Postgres への移行は分析や検証に役立つ場合がありますが、実行中の Plex アプリケーションが PostgreSQL を運用データベースとしてサポートしていることの証明にはなりません。
安全な初期設定は、Plex を想定されているデータベースエンジンとスキーマの経路で運用することです。ブラウジングの遅さ、破損、バックアップ時間が実際の問題である場合は、まずその症状を診断してください。データベースエンジンを置き換えると、ボトルネック以外の部分まで大きく変更されます。
スキーマの動作とアップグレードは Plex の管理下に置く
Plex は、エンジン固有のプラグマ、トランザクションのセマンティクス、インデックス、照合順序、拡張機能、移行スクリプト、同梱ツールに依存する場合があります。テーブルと行を一度変換しただけでは、そのランタイム契約を再現できません。
別のデータベースエンジンのサポートは、Plex 自身が管理する必要があります。リリースごとにスキーマや移行の動作が変わる可能性があるためです。管理者が保守する変換処理は、あるバージョンでは動作しても、次のアップグレードで失敗する可能性があります。
Plex が明示的にサポートしていない限り、外部データベースの実験は読み取り専用または使い捨てにしてください。アップグレード前には、ネイティブデータベースへ戻すテスト済みのロールバック手順と複製環境を用意します。そのリハーサルを現実的に実施できないのであれば、そのアーキテクチャは本番環境には脆弱すぎます。
Plex がサポート対象の外部データベース統合を公開し、継続的に保守する場合にのみ、この境界を見直してください。それまでは、管理者が保有する互換レイヤーは別個のアプリケーションであり、あらゆるスキーマ変更とアップグレード変更を吸収する必要があります。
Plex の状態を置き換えずに分析用の外部データベースを使う
Plex のデータを別のデータベースへ移す安全な理由の一つは、分析です。ダッシュボードやレポート用に必要なデータだけをエクスポートまたは複製すれば、Plex が読み書きするデータベースを変更せずに SQL の柔軟性を得られます。外部システムはランタイム依存先ではなく、派生コピーになります。
レポート用途では、外部分析が低リスクなパターンです。Plex が運用データベースを想定された場所に保持している間に、必要なデータをコピーまたはエクスポートできます。
ライブデータベースをロックしたり変更したりしないようにエクスポートをスケジュールし、分析用コピーは再構築可能なものとして扱ってください。レポートシステムに障害が発生しても、Plex は通常どおり動作する必要があります。この独立性こそが、有用な統合とサポート対象外の中核サービス置き換えを分ける重要な境界です。
エンジンを変更する前に、実際の SQLite の症状を解決する
ライブラリの遅さや不調が動機である場合は、まずデータベースサイズ、クエリエラー、アプリケーション状態の保存先におけるストレージ遅延、破損の兆候を測定してください。多くの障害は、SQLite がライブラリに対して本質的に小さすぎることではなく、ストレージ、不適切なシャットダウン、増加し続けるデータ、またはデータベースの破損に起因します。
大規模なライブラリによって大規模ライブラリのデータベース上限が明らかになる場合でも、サポート対象外のデータベース交換を最初の修復手段にしてはいけません。エンジンを変更する前に、ネイティブデータベースが再現性のある限界点であることを確認してください。
サービスの起動とデータベースのアップグレードを復旧可能な状態に保つ必要がある場合、アプリケーションが所有するスキーマ移行は、中心となる移行管理パターンです。
おすすめ商品
サポートとヒント
もっと読む
Plexは別のDockerコンテナとGPUを共有できますか？
Plexと別のコンテナは同じGPUにアクセスできることが多いですが、ドライバーのサポート、デバイスマッピング、ビデオエンジンの負荷、メモリ、復旧動作をテストする必要があります。
Plexのエラーがクライアント側とサーバー側のどちらに起因するかを見分ける方法
別のクライアントで同じ項目を再現し、セッションパスを比較してから、スコープによって障害の実際の所在が特定された後にのみサーバーの証拠を収集してください。
Plexのキャッシュとトランスコード用一時ストレージを設定する方法
永続的な Plex の状態を保護しつつ、トランスコードの一時ファイルを適切なローカルストレージに配置し、クリーンアップ、空き容量、再起動時の動作を確認します。
