全部は運ばないほうが、きれいに移るデータ移行を保守コンソールのワンクリックにするまで
現行の Mac＋MySQL 5.7 から、新しい Linux＋MySQL 8.4 へデータを移す。全部を書き出して全部を読み込む。それで詰まった。新しい土台は古い書き方を受けつけない。答えは、運ぶものを減らすこと。そして「エラーが出なかった」ではなく「全部移った」を件数で確かめること。その一連を保守コンソールのワンクリックに畳んだ。
引っ越しは「動いた」では終われない
少し前、NGW に次の10年に備えた Linux の土台を建てた。その上で本体を回し、保守コンソールを載せ、隠れていた遅さを直した。
土台が固まれば、次は決まっている。いま現場で動いているデータを、新しい土台へ移す。 現行は Mac の上の MySQL 5.7。移り先は Linux の MySQL 8.4。バージョンが一つ上がるだけだ。そう思っていた。
やることは単純に見えた。現行のデータベースを丸ごと書き出す。新しいほうで丸ごと読み込む。何百というテーブルを、そっくりそのまま。引っ越しなのだから、家財は全部運ぶ。
全部を運ぼうとすると、つまずく
丸ごと書き出したファイルを新しい MySQL に流し込んだ。途中で止まる。
新しいバージョンは古いバージョンより行儀に厳しい。前の世代がゆるく受け入れていた書き方を、新しい世代は正しくないと突き返す。
つまずく場所は決まっていた。表そのものではない。その周りに付いてくるものだ。 表から組み立てられる二次的な定義。作られた当時の作成者情報の埋め込み。日々ふくらむログの類。移行の主役であるデータ本体はきれいだった。付随物が、新しい土台の作法に合わない。
ここで気づいた。全部を運ぶ必要は、そもそも無い。 二次的な定義は移り先で作り直せばいい。当時の作成者情報は剥がせばいい。運用のログは移った先で貯め直せばいい。運ぶべきは、表と、その中身だけだ。
運ぶものを、あえて減らす
移行専用の荷造りを用意した。方針は引き算でできている。
- 表と中身だけを書き出す。 二次的な定義は運ばない。移り先で作り直す（その手順はコンソール側がもう持っていた）。
- 付いてくる作成者情報は、荷造りの段階で剥がす。 これが新しい土台での突き返しの主犯だった。
- 日々ふくらむログ系は、器だけ運んで中身は空にする。 移った先で新しく貯め直せばいい。転送も軽くなる。
- 荷造りで元のデータには一切触らない。 「不要なログを消してから書き出す」と一瞬考えた。それは現行の本番データを削ることになる。荷造りは、原本を汚さずに写しを作る作業だ。
書き出したファイルは圧縮する。数 GB が数百 MB に縮む。あとで出てくる転送が段違いに軽くなる。
荷造りをやり直した。新しい土台への読み込みは、すっと通った。運ぶものを減らしたら、きれいに移った。 引っ越しの極意が捨てることなのは、データでも同じらしい。
「エラーが出なかった」は「全部移った」ではない
ここで一度止まった。読み込みがエラー無しで終わった。それは本当に「全部移った」なのか。
途中で一つの表だけ取りこぼしても、残りが入っていれば画面上は何事もなく終わる。バックアップの回と同じ構図だ。「ある」と「本当に使える」は違う。 移行なら、「動いた」と「全部揃った」は違う。
だから荷造りのときに、それぞれの表が何件あったかの一覧を一緒に持たせた。マニフェストだ。移り終わったら、移り先の各表を数え直し、この一覧と一件単位で突き合わせる。全部一致すれば完全に移ったと言える。ずれていれば、どの表が何件足りないかが名指しで出る。
「たぶん大丈夫」を「数えたから大丈夫」に変える。移行を繰り返すには、この一手が要る。
運び屋は、目の前にいた
荷造り（書き出し）と、荷ほどき（読み込み・作り直し・数え合わせ）が揃った。残るは、その荷物を現行機から移り先へ運ぶところだ。
当初は共有フォルダを噛ませるか、手でコピーコマンドを打つかと考えていた。それで小一時間、共有の設定方法を調べていたのである。で、ふと気づいた。保守コンソールは手元の Mac の上で動いていて、移り先のサーバへの接続をもう握っている。 その接続に、荷物をそのまま流せばいい。別の通り道も、手打ちのコマンドも要らない。
コンソールは手元の移行ファイルを見つけ、握っている接続に載せて向こう側へ送り込む。共有フォルダの設定も、コピー先の打ち間違いも、まるごと消えた。運び屋を外に探していたが、運び屋は目の前にいた。調べていた小一時間は何だったのか。
ワンクリックで、数分で、数えて
バラバラだった手作業が、一枚のタブに畳まれた。
移行ファイルを見つけて、接続に載せて送り、向こうで読み込む。このとき二次的な定義の作り直しも、メニューの整え直しも、必要な索引の用意もまとめて走る。最後に数えて突き合わせる。押すのは実質ボタンひとつだ。
いちばん大きな一団体分——展開すると数 GB になるデータ——で通した。数分。取りこぼしゼロ。全部の表の件数が一致。 オンライン経由で、共有フォルダも手コピーも無い。以前は手順書を見ながら何本もコマンドを打っていた作業が、画面ひとつの中で終わる。
引っ越しは、まだ実際の最新データでは回していない。それは現場から新しい荷物が届いてからだ。だが道具はもう据え付いた。届いたら、見つけて、送って、読み込んで、数える。それだけでいい。
AIとの協働作業での学び
この一連で AI がいちばん効いたのは、素朴な最初の案を早めに手放せたところだ。
「引っ越しなら全部運ぶ」は人間にとって自然な発想だ。実際に流して、新しい土台が突き返してくる場所を一つずつ見ていくと、運ぶべきでないものがはっきりしてくる。AI と一緒だと、この「まず素直にやって、詰まったところから設計を引き算する」の回転が速い。詰まりの正体が付随物であって本体ではないと切り分け、方針に翻訳するまでが、対話のなかで一気に進んだ。
もう一つ。「動いた」で満足しないための問いを、相手が持っている。
エラーが出なかったとのことですが、それは全部移ったことと同じですか。
この一言があったから、件数の突き合わせが入った。道具は、作った時点では道具にならない。信じられると確かめた時点で、はじめて道具になる。
全部を運ばないほうが、きれいに移る。そして、数えて初めて「移った」と言える。次は現場から届く最新の荷物で、この道具を本番に試す番だ。共有フォルダを調べていた小一時間のことは、そのときまでに忘れているだろう。