主夫ときどきプログラマ

データベース、Webエンジニアリング、コミュニティ、etc

リモートワークで人と会わなくなると集中力が下がるかもしれない

f:id:masayuki14:20190307211535j:plain:w420
意識を整理しよう

この半年から1年くらいで感じること。それはなんだか集中力が落ちてきたんじゃないかなってこと。 仕事中に無駄にメールチェックしたり、SNSをのぞいてみたり、興味もないニュースみたりしてしまう。

いやいやそれくらい皆してるでしょうと思うけど、以前の自分と比べるとそういう時間が多くなっているように感じる。 日記などの記録を残しているわけでなく体感なので、単なる思い過ごしの可能性は捨て切れない。

しかし紛れもなく増えていると感じているのだ。

リモートワークによるコミュニケーション量の変化

リモートワーク中心になったはここ6年くらいだが、昨夏頃までは週に1~2回は顧客のオフィスへ行ったり、コワーキングスペースへ行ったりしていた。そのため直接コミュニケーションする機会はあったし、ランチなどで仕事以外の話もしていた。

リモートワークと言ってもそこそこ出歩いていたのだ。

  ところが昨年は「仕事減らそうキャンペーン」を行なっていたので(だれが応募してくるんだ)、顧客のオフィスへ行くこともほぼなくなってしまった。週1~2回から月1回程度への激減である。そもため誰かに自分の事を話す機会も激減した。いま自分がはまっていること、好きこのんでいること、困っていることなどいろんな事を誰かと共有したり、笑いあったり、楽しんだりすることも同時に減ってしまった。

コミュニケーションが減るとどうなるかの考察

f:id:masayuki14:20190307212139j:plain
www.pexels.com

人間にはいろいろな欲求がある。マズローの欲求説が有名ではあるが、これでいうところの「承認欲求」を得る機会も減っているのだろう。要は欲求不満が溜まってんじゃねーのっていう話だ。

何かしらの承認を他者から得るには、自分から何か行動を起こす必要がある。簡単なのは会話の中で「だよねー」とか「わかるわー」などの共感を得ること。この場合、承認欲求を満たせるとともに、意識の整理も行なっている。

 

意識の整理というのは「気になっている事が気にならなくなる事」である。例えば、ニュースやSNSで見聞きして気になった話題について話す事で、その後はその話題が気にならなくなる。欲しいものや行きたい場所があって、それについて誰かに語るうちに満足してしまう。といった具合だ。

これはプログラマーの世界で行われているラバーダッキングに似ている(やってる人みたことないけど)。アヒルのおもちゃに起こっている問題を説明することで、頭の中で問題が整理されて解決法が導かれるというものだ。要はアウトプットする事が大事だということである。

 

私たちは他者とのコミュニケーションを通して意識の整理を行っているのだろう。コミュニケーションが減ると意識の整理が行われず情報がどんどん積もっていき、集中力や思考力の低下を招くのではないだろうか。

私の場合はどうもこちらの影響が大きいように感じる。

 

んでどうすんの?

f:id:masayuki14:20190307212750j:plain
www.pexels.com

先の考察によれば、現状ではインプットが多くてアウトプットが少ない状態だ、 と言えるだろう。

つまりインプットを減らしてアウトプットを増やせばよいのだ。

 

インプットを減らすのは簡単で、インターネットから離れればよい。インターネットを主戦場に働いているのでなかなか難しいが、これは意識してインターネットメディアから離れるしかない。もしくはプロキシを置いてTwitter Facebook HatenaBookmark あたりをブロックすればかなり効果がでるだろう。

 

次にアウトプットを増やす方法。1番いいのは人に会ってコミュニケーションをしっかりとることだろう。ただ今のライフスタイルはけっこう気に入っているし、そう簡単に外出を増やせるものでもないので、現実的にはブログエントリを増やしアウトプットする事だろう。現にこのエントリを書いていることで頭がスッキリしていくのを感じられる。

はい、ちゃんと人に会いに行く機会も増やします。

 

あとやっぱり一番いいのはたくさん寝ることだろうなぁ。

 

2019年の目標

f:id:masayuki14:20190109115022j:plain
この道を行けばどうなるものか

過去の目標の決め方を考えるとどうもうまくいったものは継続するし、出来なかったことは別の目標に変えてる感じだったので今回はそれらを分けて考えました。今年もよろしくおねがいします。

継続するもの

コミュニティ活動

OSS Gateは2018年には1回ワークショップを開催したのみで、他の活動はほとんどできていません。 2019年はより多くのワークショップを開催したいと思います。 はんなりPythonの会は運営メンバーも多く勉強会の定期開催もできています。先日のミートアップで2019年の方針がまとまったのですが、それをうまく推し進めていければ、OSS Gateの開催にも良い影響がでそうなので合わせて頑張っていきたいと思います。

勉強会での発表

コミュニティ活動の方は主に運営側での目標なので、参加側の目標となると発表することです。 2018年は10回の発表を行いました。2019年はそれ以上が目標で、新しいコミュニティや勉強会でも発表していきます。 ネタは使い回しても全然問題ないということがわかったので、今年はそれで行こうと思います。

ブログなどのアウトプット

2019年は個人のブログの他にスプーキーズのちょっとTech。はんなりPythonの会月報にも記事を書くことが増えそうなので、けっこう頑張らないといけなさそう。 月2くらいのペースで書ければと思っています。

Docker/Kubernetis

今年はKubernetesを使ってDockerコンテナをいい感じに使ってみます。 ただこれは仕事で使うわけではなくて、おそらく個人の検証用として使うことになると思います。 仕事でこういうことやりたい人がいたら、私に仕事としてやらせてください。 ノウハウはきっちりドキュメントにして残せますよ。

仕事しすぎない

仕事以外のことをやるには意識して時間を作らないといけないことが2018年の1年間でわかったので、今年も仕事しすぎないでいきます。 5万円/1日の単価で仕事したいので、オファーお待ちしております。

新しいチャレンジ

データベースを深める

DeveloperとしてSQLを使いこなしたり、DBAとしてデータベースの運用管理をしたり、今よりもデータベースエンジニアとしてワンランクアップを目指します。 対象のデータベースはMySQLになるとは思います。というかこれしかできない。 とりあえずMySQLで公開されてるPDF資料は全部読もう(主に2018年以降)。 関西DB勉強会でまた発表できるようにしたいし、中国地方DB勉強会にも足を運んでみたい。

チームビルディング/マネージメント的な何か

チームを作る予定もマネジメントする予定もないけど、今年はこの辺をちゃんと学んでみよう。

クリエイティブな活動

iPadProを買ったのでApple Pencilでお絵かきをしたい。今のところ子供がめっちゃ書いててあんまり使えない。 あと技術書典にサークルで参加して本を出す。4月にあるのは間に合う気がしないのでその次でお願いします。

筋トレ

運動不足すぎるので今年はこれを解消したい。ジョギングのほうが好きだけど、嫌いな筋トレを頑張る。つらいけど。
筋肉は裏切らない。落ち着いた筋肉、頭いい筋肉になる。

2018年のふりかえり

f:id:masayuki14:20190107165255j:plain
ふりかえっているひと

年内に書いてしまいたいと思いつつ、今回も年越ししてしまい結局年始に書くことになった。とはいえ去年よりは早く書いているのでよしとする。 さあ、2018年の1年について振り返ってみよう。

masayuki14.hatenablog.com

2018年にたてた目標

コミュニティ活動

コミュニティ活動 去年始めた2つのコミュニティ活動を今年も継続する。そしてRuby界隈にも参加する。

2018年の目標 - 主夫ときどきプログラマ

総じてコミュニティ活動はしっかりとできたと思う。

はんなりPythonについては1年のふりかえりがちゃんとできるほど継続して活動できた。

はんなりPythonを1年間続けてきて思うこと - 主夫ときどきプログラマ

2018年に公開したスライドも6つになるし、勉強会で発表する機会も2017年よりも多かった。特に関西DB勉強会で発表するという出来事が一番大きい成果だったと思う。続けていると思ってもみないことが起こるんですね。

Ruby界隈で、、、っていうのはコミュニティ活動を目標にしたときから言ってたけど、僕の見える範囲のRuby界隈はあんまりRubyやってないので、もうRubyにこだわる必要はないなぁという思いに至った。一方で自分はやっぱりDBが面白いと思っているということを再確認できた1年だったので、2019年はこれまでと少し違う路線でコミュニティ活動を続けていこうと思う。

OSS開発

去年は微力ながらもOSS開発に参加したので今年も微力ながら参加しますよ!! でもできれば回数を増やしたいし、コードにもコミットしたい。

2018年の目標 - 主夫ときどきプログラマ

全然してない。

一応GitHubMySQL Routerにプルリク送ったけど、やはりちゃんとしたMySQL Bugsに報告すべきなんだという知見は得られた。

OSS開発ってのは「OSSを使う」→「困る」→「報告する」→「自分で直す」→「良くなったOSSを使う」というサイクルに入らないと参加するのは難しくて、今は「OSSを使う」の部分があまり多くないので、もうちょっと視点を変える必要があるなぁというところ。

ブログ/Qiita

これも継続案件で月1ペースで何かしらのアウトプットを続けていく。

2018年の目標 - 主夫ときどきプログラマ

いろいろ合わせて月2ペースでアウトプットできていたので、これは花丸の結果ですね。少しずつ習慣化してきている。

本を読み返す

今年は新しい技術書はもちろんだけど、蔵書を読み返すようにする。

2018年の目標 - 主夫ときどきプログラマ

前半はわりと蔵書を読んでいたけど、後半はDBやインフラ関連の本を買って読んでいた。ただあまり「本を読む」→「アウトプットする」という流れはできていないので、目標達成した感はあるけどモヤモヤしている。気づきは得られたかなぁ。。。

Docker

最近少しずつ使うようになってきたので、無理矢理にでも使っていくのを続ける。

2018年の目標 - 主夫ときどきプログラマ

わりと1年通して使ってこれたと思う。初めはコンテナ1つでやってたけどDocker Composeを使うようになったし、いろいろわかってきた。次はKubernetesを使うという一手につなげたい。 一方でECSを使ってやってみたいことはあったけど実現できなかった。ここは改善すべき結果になった。

Machine Learning

Pythonのコミュニティを始めたのでPtyhonを学ぼうと思っているけど、今更Webで使う理由はないので機械学習系をやろうと思う。

2018年の目標 - 主夫ときどきプログラマ

なんというか、やはりあんまり興味もてなかった。できなかった。

ネットワーク

基礎体力を鍛えるためにネットワークスペシャリストになろう。

2018年の目標 - 主夫ときどきプログラマ

これも全然だめで、勉強もしてないし、試験の申込みもしてない。本を読んでいた時期はあったけど全然頭に入らなかった。

仕事しすぎない

コミュニティ活動とかOSS開発をやろうと思うと時間の確保が必要なので主夫の良識の範囲で仕事をしようと思う。 とはいえ信頼残高を増やしつつ、つきあいは大事にしていこう。

2018年の目標 - 主夫ときどきプログラマ

これは記録があるのでグラフにするとこんな感じでした。

f:id:masayuki14:20190107122010p:plain

2017年と比較して年間で127時間の労働時間が減っている。この時間でブログを書いたりスライドを作ったりしているので、インプットとアウトプットの時間を意図的に確保できた。アウトプットの量も2017年より増えている。この目標を達成するために動くことで時間の余裕が生まれ、他の目標が達成されている、という関係になっていった。

信頼残高はたぶん減ってはいないと思う。

目標以外のこと

PostgreSQL

PostgreSQLを使う機会があって、もう少し詳しくやりたいって感じになった。今のところPLSQLでデータ処理をやるのがメインなのでアーキテクチャとかユーザー管理とかパフォーマンス関連の部分は全然わかっていないけど、この辺を詳しく知りたい。 そして、ストアド・プロシージャの管理方法(バージョン管理、マイグレーション、デプロイなど)のノウハウがなさすぎて、これから作っていかないといけない。 この手のノウハウってあまりWeb開発周辺では聞かないので、誰か助けて欲しいしなんでも良いから情報ください。

Symfony

とあるアプリのAPISymfonyで作っているけど、この案件はなんだかんだで1年以上続いていてゴタゴタしてるので収束することを祈っている。

やっぱりDBが好き

DBを設計したりアーキテクチャを知ったりSQLでいろいろやったり、っていうのはやっぱり楽しいし好きなんだと再認識した。今年1番の発見かもしれない。

総括

目標に関しては達成できたという感じなので良かった。 目標を達成することはもちろん良いことだと思うけど、できなかったからといって悪いわけではなく、自分の興味や関心をあぶり出してくれるので、それはそれで良いことだと思う。 「目標を立てる」→「ふりかえる」という作業をセットでできたらなんか達成できた、できなかった、はあんまり関係ないなと思った。 なので2019年も継続したいことは少しハードルを上げた目標にして、それにチャレンジしたかったり興味ありそうな目標を加える、というスタイルにしていく。

一方で仕事どうやったんか?という部分は楽しんでできていない期間のほうが長かったので、ここは変えないとつまらない人生になってしまう。危機感を持っていきたい。

はんなりPythonを1年間続けてきて思うこと

https://connpass-tokyo.s3.amazonaws.com/thumbs/5a/48/5a48909c9047a419355930bc429aab2f.png

先日はんなりPython#12が開催され、めでたく1周年を迎えました。
その時の様子はこちらの記事で簡単に紹介しています。

当日のLTのスライドを作るためにいろいろ振り返っては見たものの、MySQLアドベントカレンダーの参加日と被っていたのでそれほどちゃんと考える時間を取れませんでした。なので改めて1年間のことを振り返って書き出したいと思います。

きっかけ

2017年に「ルービーの会LT大会」というイベントに参加したとき、帰り際にたまたま会って言葉を交わしたマザヲさんとekuniさんが同じく京都の人で「京都って勉強会少ないですよね〜」という話から後日はんなりPythonの会を結成するに至りました。

その頃は「これからは勉強会に参加するんじゃなくて運営する側にならんとなぁ」と考えていた時期で、そこに「京都でPythonの勉強会を作りたい」と考えていたマザヲさんと、いろんな勉強会(主にRuby界隈)に参加してるekuniさんとの出会いがあったので、すぐに動き出して「はんなりPython#1」を開催したと思います。そこにくないさんがジョインして今に至ります。 何かの縁が働いたのでしょう、すばらしい共催者に恵まれてはんなりPythonの会はこの1年、毎月開催を続けられました(8月は夏休み)。

運営に関して得た知見

運営をやってきて気づいたことをつらつらと書いていきます。だいたいのことはスライドにも書いてあります。
はんなりPython2018ふりかえり - Speaker Deck

運営者は2人以上いないとつらい

便宜上2人で話を進めますが、2人いることでたとえ参加者が1人もいなくても開催の体を保つことができます。 2人いることで開催にかかる負担が分散され、場所の確保やイベント情報の公開など作業が半減します。 また、定期開催をするとどうしても都合が悪い日というのがあるわけで、そうなると1人だと開催自体ができなくなってしまいます。 今回都合悪くて行けない、となった時に2人なら開催することができるんですね。 他に任せられる人がいることで、心理的にも負担が少なくなります。

人数が多くなるとこの心理的な負担がどんどん軽くなるので「運営作業とかぜんぜんしないけどいつも主催者側で参加してくれる」っていうだけでも仲間として非常に助かります。 もし「自分は何もできないから運営に加わるのはちょっと。。。」と思っている人は、ぜひ運営に加わってほしいと思います。いるだけで全然違うので。ほんとに。

私は他にもOSS Gateというコミュニティにも参加しいて京都で活動していますが、こちらは運営しようというモチベーションがあるのは私しかいません(大阪や東京は複数人います)。OSS Gateの方もワークショップを開催したいと思っているのですが、1人しかいないとどうしても自分が動かないと活動自体が止まってしまうし、負担も大きい。結果、今年は1回しか開催できませんでした。東京、大阪の方は定期的に開催しているし、開催回数と運営人数は比例していると思います。

OSS Gateはワークショップの開催なのでなおさら負担が大きいってのはありますが。)

HRTをもって取り組む

運営に関しては各メンバーがわりと主体的に行っています。各メンバーでモチベーションも違うと思いますし、何かをやろうと思った時には自分から動かないと何も起こりません。 それに有志で集まっているので他のメンバーに何かを強要することはできません。 その中で「自分にできることをやる」「できないことはメンバーに頼る」「お互いに助け合う」ということを心がけてやってきました。そのおかげかはわかりませんが、トラブルなく続けられたと思います。

ソフトウェアエンジニアがチームでうまく働くためにはどうしたら良いのか、が書かれている「TeamGeek」という書籍があります。 このなかにHRT(ハートと読みます) という概念がでてきます。
Humility - 謙虚Respect - 尊敬Trust - 信頼 の頭文字で、この3つを大事にすることで成功するチームを作ろうというものが主な内容です。 (むかし勉強会をした時にGitHubにあげてました。 TeamGeek.md )

これはコミュニティの運営にも役立つ概念で、報酬が無いぶん、より重要なことのようにも思います。

コミュニティの目的を設定するとなんか役に立つ

チャットのログをたどると3回目をやる時に「目的を決めよう」という会話が出てきていました。その後アップデートを重ね、現在の4つに落ち着いたようです。

  • はんなり交流しましょうYouTube
  • オープンでフラットなコミュニティ
  • 初心者からエキスパートまで参加できる
  • 交流のハブになる

この時から勉強会の冒頭にコミュニティの説明と目的なんかを説明しアイスブレイクをした後に発表をするという流れができて定着していきました。 目的を設定することで、何かの相談事をする時も考えのベースにすることもできるし、勉強会や懇親会での態度も自然とそうなっているような気がします。 参加者から見ても自分に合うか合わないかを考える材料にもなるんじゃないでしょうか。

やりたいようにやったらいい

勉強会だからちゃんとやらなきゃ!とか、すごい発表をしてやろう!とかあんまり気負いすぎると心が疲れてくるので、気負わずにやったほうがいいです。 一時の活発な活動よりも、肩の力を抜いて細く長く継続していくことのほうが重要に思います。 それに自分たちがやりたくて始めた勉強会なので、好きにやってやりたいようにやることが大事だと思います。

雰囲気作りは運営者がやらないと良くならない

勉強会は個人で参加する人が多いですし、毎回はじめての方もいらっしゃいます。そうなると参加者同士ではなしかけたり、発表へ質問したりするのって簡単じゃないですよね。 私もはじめて参加する勉強会で誰とも話さず、質問もせず、ただ話を聞いて帰っただけのことが何度もあるので、そういうふうにはしたくないなと思っていました。

そこではんなりPythonでは交流も目的にしているし、毎回はじめにアイスブレイクということをやっています。5〜6人くらいでグループになって自己紹介をしていきます。 なるべく各グループに運営者が入って話をふったり広げたりするようにしていて話しやすい雰囲気を作ることを心がけています。 はじめての人にもちろん効果があって、2回以上参加している人は同じように話しやすい雰囲気を作ってくれるようになっていると思います。

これはOSS Gateで得た知見なんですけど「はじめに自分から声を出しておけばその後は話しやすくなる」というのがあってOSS Gateのワークショップでははじめにやっています。動画で見ると何をしているかわかりやすいです。

01. 準備 〜 アイスブレイク - YouTube

懇親会でのはなしやすさは勉強会の雰囲気で決まるぽい

勉強会でうまく交流のきっかけを作れているので、懇親会でも話しやすい雰囲気がいつもできているように感じます。 次回の会場利用申請などで少し遅れて懇親会に合流することもありますが、5〜10分しか経ってないのにすでに盛り上がってる、みたいなこともしばしばあります。 Pythonの勉強会とはいえいろいろな分野の人が参加しているので、新しい発見や知見を得られることもあるし、こっちが本番なんじゃないかという空気すらあります。 毎回半数以上の人が参加するので全体として交流しやすい雰囲気を作れているのかなぁと思います。

来年に向けて

ひょんなことからはじまったはんなりPythonの会ですが1年間継続することができました。 すばらしい共催者、参加者、機材協力してくれるスプーキーズのみんな、他のコミュニティの方々、そして好き勝手やらせてくれている家族に感謝したいと思います。 ありがとうございました。 2周年を迎えられうように2019年も細く長く続けていきたいと思います。

運営に興味がある人がいたら はんなりPythonの会 #サイゼリヤミートアップ - connpass に参加してみてください。

hannari-python.connpass.com

共催者のマザヲさんもブログ書いてるのでついでに見てもらえると僕らの考えていることがわかってもらえると思います。

www.mazarimono.net

これからは mysqlpump を使っていくことにする

この記事は「MySQL Casual Advent Calendar 2018」21日目の記事です。

qiita.com

9日目の記事としてこちらも書きました。

masayuki14.hatenablog.com

今回は mysqlpump に関する記事です。

mysqlpump って? mysqldump の typo じゃないよ

mysqlpump は MySQL5.7.8から追加された新しい論理バックアップツールです。 複数のMySQLデータベースをダンプすることができます。 mysqldump の拡張ツールではなく1から新しく設計・開発されたもので、高速化のためにデータベース、テーブルなどのを並列処理でダンプすることができます。 また出力を圧縮したり、進捗を表示するなどの機能もあります。

MySQL5.7で導入された機能を使用しているので、MySQL5.7以上で利用することを前提としています。

バージョン

$ mysqld --version
/usr/sbin/mysqld  Ver 8.0.13 for Linux on x86_64 (MySQL Community Server - GPL)

$ mysqlpump --version
mysqlpump  Ver 8.0.13 for Linux on x86_64 (MySQL Community Server - GPL)

基本的な使い方

mysqlpump -uroot -p > all-database.pump.sql

デフォルトですべてのデータベースを出力しますが、sys performance_schema information_schema は出力しません。

以降、Tips的にオプションの使い方などを並べていきます

データベースを指定して出力する

mysqlpump -uroot -p --databases db1 db2 ...

複数のデータベースを指定する場合は --databases オプションを指定します。 オプションの後に空白区切りでデータベース名を並べます。 = で指定する方法は使えないので気をつけましょう。

テーブルを指定して出力する

mysqlpump -uroot -p database_name table_1 table_2 ...

最初の引数をデータベース、2番目以降をテーブルと解釈します。

mysqlpump -uroot -p --include-tables 'table1, table2, ...'
mysqlpump -uroot -p --include-tables=table1,table2,...

--include-table オプションでテーブルを指定することができます。 オプションには一つの値が渡るようにします。クオートでくくる場合は空白が入ってもいいですが、くくらない場合は空白が入るとエラーになります。 同じテーブル名が複数のデータベースにある場合はどちらも出力されます。

mysqlpump -uroot -p --include-tables='db1.table1, table2'

table1db1にあるもののみとなり、table2は複数のデータベースのものが出力されます。

mysqlpump -uroot --databases db1 db2 \
    --exclude-tables='db1.table3, table4' 

--exclude-tables で除外するテーブルを指定できます。

DROP ステートメントを追加する

デフォルトでは DROP XXXステートメントが出力されません。

mysqlpump -uroot -p --databases db1 db2 \
    --add-drop-database \
    --add-drop-table

オプションを指定すると DROP DATABASE IF EXISTS db1 DROP TABLE IF EXISTS db1.table1 が出力されます。

一貫性のあるバックアップを取得する

mysqlpump -uroot -p --single-transaction

STAER TRANSACTION を発行して一貫性のあるバックアップを出力しますが、対象となるストレージは InnoDB のみで MyISAMMEMORY ストレージの一貫性は保証しません。 トランザクションの分離レベルは REPEATABLE READ になります。

また、バックアップの取得中に ALTER TABLE CREATE TABLE などテーブルに変更を加える操作を実行してはいけません。

キューやスレッド数を指定して取得する

mysqlpump -uroot -p --default-parallelism=3

デフォルトでは2つのスレッドを持つ1つのキューを設定し処理を実行します。 --default-parallelism オプションで並列処理キューのスレッド数を指定します。 この場合、1つのキューを3つのスレッドが処理します。

mysqlpump -uroot -p --parallel-schemas=db1,db2,db3

db1 db2 db3 を処理するキューを設定し処理を実行します。それ以外のデータベースは別のキューで処理されるので、この場合は2つのキューで処理を行います。 スレッド数はデフォルトの2になりますが --default-parallelism で指定することもできます。

mysqlpump -uroot -p \
    --parallel-schemas=db1,db2 \
    --parallel-schemas=db3

db1 db2 を処理するキュー、db3 を処理するキュー、それ以外を処理するキューを設定し処理を実行します。合計3つのキューで処理します。

mysqlpump -uroot -p \
    --parallel-schemas=db1,db2 \
    --parallel-schemas=db3 \
    --default-parallelism=4

前の例とおなじキューを設定し、各キューのスレッド数を4として実行します。

mysqlpump -uroot -p \
    --parallel-schemas=6:db1,db2 \
    --parallel-schemas=db3 \
    --default-parallelism=3

db1 db2 を処理するキューをスレッド数を6で、db3 を処理するキュー、それ以外を処理するキューのスレッド数を3に設定し処理を実行します。

mysqlpump -uroot -p --default-parallelism=0

この場合はシングルスレッドプロセスとして実行されます。

並列処理は mysqldump にはない機能なので、ダンプするデータが大きい状況ではうまく利用したいですね!

出力を圧縮する

mysqlpump -uroot -p --compress

クライアントとサーバーの両方が圧縮に対応している場合に、クライアント、サーバー間で送信されるデータを圧縮します。クライアントに出力される結果は圧縮されていません。

mysqlpump -uroot -p --compress-output=lz4 > database.lz4

# 解凍
lz4_decompress database.lz4 database.sql

出力を圧縮します。 LZ4ZLIB が指定可能で、結果はそれぞれのコマンドで解凍できます。

進捗を表示する

mysqlpump -uroot -p --watch-progress

処理中の進捗状況を定期的に標準エラーに出力します。デフォルトで有効なのでオプションで指定する必要はありません。 表示したいくない時は --skip-watch-progress を指定します。

テーブル定義とデータを別に出力する

mysqlpump -uroot -p --skip-dump-rows
mysqlpump -uroot -p -d

テーブルのデータを出力せず、 CREATE TABLE のテーブル定義だけになります。

mysqlpump -uroot -p --no-create-info
mysqlpump -uroot -p -t

テーブル定義を出力せず INSERT INTO によるデータの出力だけになります。 前の例と合わせることで、テーブル構造とデータを分離することができます。

mysqlpump -uroot -p --no-create-db

CREATE DATABASE ステートメントを出力しません。

これらのオプションは --add-drop-database--add-drop-table と組み合わせると面倒なことになります。