データベースとデータ

Web スタックは、その下にあるデータの質を超えることはできません。FrontierStack はデータベースを一級のサービスとして扱います。インストールして実行し、中身を閲覧し、AI 管理者がサイトのデータベースを平易な言葉で点検・修復し、そして — 多くの構成が忘れがちな部分ですが — 実際に復元できる検証済みのスケジュールですべてをバックアップします。本章では、リレーショナルエンジン、インメモリキャッシュ、新しいベクトル・分析ストア、そしてそれらすべてを守るバックアップの仕組みを扱います。

5.1MySQL／MariaDB ペイン

サイドバーの Databases セクションから MySQL を開きます。ペインはサーバが未導入なら Homebrew でインストールし、Server.app がかつて備えていた操作を提供します。Start・Stop とライブ状態ランプ、リッスンポート（既定 3306）、サーバ上のデータベース一覧です。MySQL 互換のフォークである MariaDB も同じように管理でき、ペインはインストールされている方を認識します。

ローカル開発は意図的な 1 つの慣習に従います。ローカルの root アカウントはパスワードなしです。これは MAMP／XAMPP の慣行であり、ワンクリック構築と AI の SQL ツールが資格情報の入力なしに動作する理由です。安全なのは、Mac 上の MySQL が 127.0.0.1 のみでリッスンし、そのマシンからしか到達できないからこそです。パスワード付きアカウントや連携サーバ上のデータベースなど、外部から到達する必要が生じた瞬間に、後述の秘密情報ボールトへ切り替えます。

5.2Database Ops と SQL の実行

Database Ops ペインは、データベースがブラックボックスでなくなる場所です。Replication セクションは、設定済みサーバが MySQL レプリカか PostgreSQL スタンバイかを検出し、遅延を表示します。MySQL は SHOW REPLICA STATUS（IO・SQL スレッド、Seconds_Behind_Source）を読み、PostgreSQL は pg_is_in_recovery() と再生タイムスタンプを使います。レプリケーションの停止やしきい値超過の遅延は、選んだチャネルにアラートを出します — Database Slave 監視プリセットの基礎です。

データの点検や修正には、AI 管理者の run_sql ツールがあります。「この注文の合計がなぜ間違っているのか」「元の重複ユーザより古い重複を削除して」のように平易な言葉で頼むと、ローカルサーバに対して SQL を実行し、結果を表として表示します — MAMP の Claude 連携によく似ています。文がデータを変更し得るため、run_sql は変更の有効化を必要とします。読み取り専用のクエリはアシスタントが有効になった時点で動作します。既定はパスワードなしのローカル root で、設計上ローカル専用です。

5.3パスワード付き・リモートのデータベース

ローカル root のショートカットは、ネットワークが始まるまさにその境界で止まります。パスワードが必要なデータベースや、リモート・連携サーバ上のデータベースでは、パスワードをプロンプトやツールに貼り付けることは決してしません。代わりに、AI 管理者の Script secrets (.env) バーに DB_PASSWORD や MYSQL_PWD という名前付き秘密として一度だけ追加し、アシスタントは run_script 経由で mysql クライアントを実行し、値を $DB_PASSWORD として参照しながら、名前付きサーバに対して SSH 経由で実行します。実際の値は Mac に留まり実行時に注入され、クラウドモデルが見るのは名前だけで秘密は見ません。

5.4PostgreSQL

高度な SQL・リッチな JSON・全文検索・GIS を求めるプロジェクトには Postgres を開きます。ペインは PostgreSQL（既定ポート 5432）をインストールして実行し、MySQL と並んで同じ開始／停止／状態の操作を備えます。アプリやフレームワークが前提とするなら PostgreSQL を、それ以外なら MySQL／MariaDB が手軽な既定です。両エンジンとも、後述のバックアップジョブと AI ツールの一級の対象であり、PostgreSQL は後述の特化型ストアのいくつかの土台にもなります — 埋め込み用の pgvector、時系列の TimescaleDB、Postgres データベース上に即席 REST API を載せる PostgREST です。

5.5Redis とその他のキャッシュ

セッション・キュー・レート制限・ホットパスのキャッシュは通常、リレーショナルテーブルよりインメモリストアを求めます。FrontierStack は Caching カタログから 2 つの標準を実行します。インメモリのキーバリューストアであり Redis Streams も支える Redis（ポート 6379）と、シンプルな分散キャッシュ用の Memcached（ポート 11211）です。他のサービスと同様にインストール・起動・監視できます。多くの CMS やフレームワークの構成は Redis を MySQL または PostgreSQL と組み合わせます。すべての選択肢はサービスカタログ（第 6 章）に並びます。

5.6ベクトル・分析データベース

2 つの新しいストアの系統が、独自のカタログカテゴリを持ちます。ベクトルデータベースは、検索拡張生成（RAG）や意味検索のための埋め込みを保持します。AI スタック（第 15 章）がモデルに自分のドキュメントへのアクセスを与える方法です。分析データベースは、トランザクション的な読み書きではなく、大規模データの高速な集計のために作られた列指向・時系列エンジンです。

完全にインプロセスのベクトル検索には FAISS（ライブラリ、ポートなし）もあります。フレームワークが前提とするエンジンを選んでください。各ペインは同じカタログの仕組みで一つひとつをインストール・実行します。

5.7データパイプラインと ETL

これらのストアの間でデータを移動・整形することは、それ自体が一つの分野です。Data Pipelines & ETL カタログカテゴリが概観レベルでこれを扱います。数百のコネクタを持つ抽出・ロードの Airbyte と Meltano、SQL ベースの変換・モデリングの dbt、そして作業をスケジューリングする Dagster・Prefect・Kestra などのオーケストレーターです。これらは本格的なプラットフォームで、FrontierStack はインストール・実行して Web UI を提示しますが、パイプラインのロジックは各ツールの中にあります。プログラマブルなデータパイプライン DAG には、Workflow Orchestration カテゴリの Apache Airflow もあります。

5.8バックアップ：ダンプ・概要ペイン・CCC

テスト済みバックアップのないデータベースは、未来の障害です。FrontierStack はこれに 2 方向から取り組みます。Database Ops では、サーバごとに検証済みのダンプスケジュールを定義します。名前、エンジン（MySQL か PostgreSQL）、ホスト、ポート、ユーザ、データベース（空欄＝すべて）、バックアップディレクトリです。期限の来たジョブはアプリ起動中に自動実行され、Run Now は即座に 1 回実行します。各実行はダンプ以上のことを行います — mysqldump は一貫した InnoDB スナップショットのため --single-transaction で実行され、続いて Verify が gzip の整合性とダンプが完了マーカーで終わっていること（切り詰められた・書きかけのファイルを検出）を確認し、.md5 サイドカーを書き、保持数にローテートし、鍵ベースの SSH で結果をオフサイトへ rsync します。

AI 管理者は同じ操作をツールとして公開します。db_dump はデータベースをターゲット上の .sql ファイルにダンプし（mysqldump または pg_dump を使用）、backup_now は設定・サイト・データフォルダのタイムスタンプ付き tar.gz を作成します。どちらも変更を伴うため、承認と変更の有効化が必要です。DB パスワードには $NAME のボールト秘密を参照し、貼り付けた値は決して使いません。

Backups 概要ペインは、すべての仕組みをまとめ、古さがひと目で分かるようにします。Time Machine の状態、Carbon Copy Cloner のタスク、アプリ管理の Apache 設定スナップショット、Git による設定のバージョン履歴、スケジュール済み自動エクスポートです。Carbon Copy Cloner ペインは CCC のタスクと履歴をその ccc コマンドラインツール経由で読み取り、タスクを必要に応じて Run できます。Time Machine と CCC はどちらも Alerts エンジンに供給されます — しきい値内に実行されていないバックアップや、失敗した CCC タスクは、選んだチャネルにアラートを出します（第 11 章）。

5.9復元 — そして復元の安全性

バックアップは復元のために存在し、復元こそが危険な半分です。AI の restore ツールは .tar.gz アーカイブを展開するか、.sql ダンプをデータベースにインポートします。ダンプのインポートは稼働中のデータベースを上書きし、アーカイブの展開はその場でファイルを上書きするため、restore は変更を伴い、破壊的になり得ます。常に変更の有効化付きの明示的な承認が必要で、SQL インポートは DB パスワードを $NAME のボールト秘密として参照します。

5.10壊れたデータベースのリカバリ

データベースが単に停止するより悪い状態——起動しない、テーブルが破損している——になることがあります。FrontierStack は AI 管理者（第 13 章）に、手作業で使うのと同じツールを、いつもの承認カードのうえで与えます。mysql_check_tables と pg_check_tables は mysqlcheck／pg_amcheck を実行して破損・クラッシュしたテーブルを見つけます。repair をオンにすると先に mysqldump／pg_dump でバックアップを取ってから修復（--auto-repair／REINDEX）するので、修正は取り消し可能です。mysql_service_control と pg_service_control は、systemd・launchd・Homebrew・service(8) をまたいで、ローカルでも SSH 経由でも、サーバの起動・停止・再起動・状態確認を行います。

難しいケースにはガイド付きのスキル——「Recover Broken MySQL」と「Recover Broken PostgreSQL」——があり、手順全体をたどります。エラーログを読み、原因を診断し、読めるものをすべてダンプし、新しいデータディレクトリに再構築し、壊れたテーブルを修復または作り直し、再起動します——常に古いデータディレクトリはコールドバックアップとして名前を変えて退避し、決して削除せず、破損を伴う各ステップの前に確認します。リモートホストでは、サーバペインのデータベース行にある赤い Emergency ボタンが最短の入り口です。そのホスト向けの適切なリカバリスキルを読み込んだ状態でアシスタントを開きます。

5.11ORM とアプリネイティブのツール：Drizzle と Convex

最後に、2 つのツールがアプリケーションのスキーマ定義の場であなたを迎えます。Drizzle ORM ペインは Drizzle プロジェクト（そのテーブル・マイグレーション・バックエンドの方言）を検出し、drizzle-kit タスクを代行します — スキーマから SQL を Generate、Migrate、スキーマを直接 Push、既存データベースを Pull（イントロスペクト）、そしてデータ閲覧用に Drizzle Studio を開きます。Convex ペインは、組み込みデータベースを備えるリアクティブバックエンドの Convex を管理します。npx convex dev で関数を監視・プッシュするか、Docker でセルフホストのバックエンドを立ち上げます。どちらも Node.js を必要とし、未導入ならペインが Homebrew でインストールします。これらはアプリケーション自身のデータ層を扱います。上記のダンプとバックアップは、それらが書き込むものを引き続き守ります。