MySQLからPostgreSQLにデータを移行する

ロリポップマネージドクラウドからrender.comにこのサイトを移設するにあたり、DBMSの変更が必要になったのでそのときに調べたことや手順などを残しておく。

データ量は大したことはないが、データの大半がmarkdownやHTMLであり、SQLの中にはいっているなかなか苦労しそうな文字達が多かった。

lanyrd/mysql-postgresql-converter: Lanyrd's MySQL to PostgreSQL conversion script のようなツールをつかうとほぼ一撃っぽいのだが、どういう違いがあるのかを知りたかったのでsedで置換してながせるようにしてみた。

1. mysqldumpをとる

mysqldumpにはcompatibleというオプションがあり、これをつけるとちょっとだけ他のDBMSでも読み込みやすいSQLを掃き出してくれる。ちょっとだけというのがポイントであり、これだけでは当然うまくいかないのだ。

また、このアプリはRailsでできてるので、スキーマはダンプしないように--no-create-infoをつける。

さらに、--skip-quote-namesでテーブル名やカラム名などがクオートされないようにしておく。これってDBMS依存なんだ……という発見があった。

mysqldump --compatible=postgresql --skip-quote-names --no-create-info --default-character-set=utf8mb4 2. 文字列中のシングルクォートを処理する

1で作成したdumpは文字列がシングルクオートで囲まれていて、中では\'と\でエスケープされているが、PostgreSQLではこれはだめ。シングルクォートは二つ重ねるらしい。

\'を''に変換してあげる。

sed "s/\\\\'/''/g" 3. 文字中にエスケープ文字が入っていることを伝える

文字列中に\nのように\がはいっていると、PostgreSQLはそのままではうまく読み込めない。

'\n'をE'\n'のように文字列リテラルの先頭にEをつけてあげる必要があるようだ。これをsedでやってあげる。余計に付けても問題なかったので、全ての文字列リテラルにつけてしまった。

sed "s/,'/,E'/g" 4 tinyint(1)をbooleanにする

mysqldumpはtrueを1、falseを0で出力するが、これはそのままでは取り込まれてない。これはかなり苦労しそうなところだったが、なんとintのカラムがprimary keyであるid以外にはなかったので、とりあえず雑に全部変換してから、だめだったところを個別に手直しした。

sed "s/,0,/,false,/g" | sed "s/,1,/,true,/g" まとめ

そんなこんなで、これくらい変換したらとりこめるようになったので、最終的にはこんなワンライナーで処理できた。めでたしめでたし。

sed "s/,0,/,false,/g" dump.sql | sed "s/,1,/,true,/g" | sed "s/\\\\'/''/g" | sed "s/,'/,E'/g" > dump_ok.sql

プロジェクトペースメーカー

会社のslackで@june29と話しているときに気付いた概念。頭につけるのが「プロジェクト」でいいかは一考の余地あり。

ソフトウェア開発プロジェクトにおいて、タスクやストーリーを進めるペースというのは何によって決まるのだろうか。もちろん個々の能力、およびその合計であるチームの力というのは無視できないが、実はプロジェクトチームの中にいる「ペースメーカー」によって作られているのではないか。

最近、会社のとあるプロジェクトが(私の)想像以上のスピードで進んでいるのを目の当たりにした。それにかかわっている個々のメンバーのそれまで見えていた力からするとかなりのスピードだ。もちろんチームメンバーの相性や、そこで採用されている技術スタックというのは大きな影響があるだろうが、それだけではないようにも感じたので少し考えてみた。

そのプロジェクトはCTOが舵を取るプロジェクトだった。そのプロジェクトでは、毎日の短いミーティングで不明点や不安を共有し、その場でCTOが決めている(ように見えた)。また、次に何をすればプロジェクトが進むのか、適切な手段を適切な締切で適切な人に割り振っていたようにも見えた。そのプロジェクトのペースメーカーはCTOだったのだ。

それに気付いたあとに自分の周りのチーム・プロジェクトを見回してみると、それぞれにペースメーカーがいるように見えた。あるプロジェクトはリードエンジニア、別のプロジェクトはプロダクトマネージャ、あるチームはデザイナーのリードかもしれないと、チームやプロジェクトの見え方が少し変わった。その人達に共通している1つの要素は「決める力」かなと思った。不安を解消する力とも言えるかもしれない。チームのスピードが鈍化するのは決まらないときだ。このまま進んでいいのかと不安に思うときに全力を出すことはできない。即断即決し、自ら先頭を走り、このペースで走って欲しいとチームを鼓舞する存在がプロジェクトペースメーカーだ。

ペースメーカーというメタファは今のところとても気にいっている。ペースメーカー (陸上競技) - Wikipediaでは、マラソンにおける役割や効果について以下のように書かれている。

陸上競技の中距離走・長距離走、特にマラソン競技でみられるペースメーカーとは、高水準かつ均等なペースでレースや特定の選手を引っ張る役目の走者のこと。ラビットと呼ばれることもある。 ペースメーカーを導入することにより、レース序盤でライバル選手を意識しすぎてペースを乱すことがなくなり好記録が期待できる(最先頭を走る競技者の負担が減る)。また、選手の風除けの役割も果たす。

プロジェクトにおけるペースメーカーも、ここに書かれていることそのままのようにも思える。ペースメーカーは、そのプロジェクトが期待通りまたは期待以上の成果をだせるスピードを理解し、そのスピードで他のメンバーをひっぱっていく。くわえて、実はプロジェクトのゴールまで先頭で走り続ける必要はない。そのペースでチームがゴール直前までいったなら、最後は他のメンバーが追い越していってよいし、そうであるべきだとも考えられる。

プロジェクトペースメーカーという語彙を獲得してからは、各チームのペース、開発プロジェクトであれば生産性やコードのクオリティを上げていくための新しい視点を得られたように思う。

また、これと似た概念として「リズム」というのもあるというのが次の考察ポイント。上であげた社内のプロジェクトの例で言えば、毎日のミーティングというやつ。スクラムであればデイリースクラムなどのスクラムイベントがプロジェクトのリズムを作る要素だろう。これに関して今あらためて見直しているのはkyon_mmさんの15分スプリントの話( 15分スプリントの具体的な進め方について動画で話した #15min_sprint - うさぎ組)。これについてはまたあとで整理できたら書こうと思う。