CasualにMySQLリプレイス
この記事はMySQL Casual Advent Calendar 2014の8日目の記事です。
MySQL系のブログや投稿は初めてなので、軽く自己紹介。
Oracleで育ってMySQLやPostgreSQLもいじっている節操の無いDBAです。
現在はMySQLばっかりです。
10月にMySQLサーバーをリプレイス＆5.5から5.6へのバージョンアップしたのでつらつらと書いてみます。
MySQL5.6が出てだいぶ立ち、参考になるようなブログや資料はたくさんあったので苦労はしませんでした。
ありがたやーありがたやー。
・Casualにmy.cnf
Casualだし、有名な方々の資料がググればいっぱいあるのでパラメータの意味までは書きません。
注意してたのはこのへんくらい。
sql_mode=''
explicit_defaults_for_timestamp=true innodb_online_alter_log_max_size = 1024M
sql_modeはデフォルト通りにしたかったけど、結局開発側の調整ができず断念。
innodb_online_alter_log_max_sizeは見積もりがちょっとわかんないけど、
コンシューマ向けサービスにデフォルトの128Mbyteは小さいかと思い
1Gbyteにしてみました。
後はこのへん。
binlog_format=ROW
binlog_rows_query_log_events = on
以前の設定がROWになっていたものの、オペミスなどの調査ができないしという事でmixedにする予定でした。
でも、binlog_rows_query_log_eventsが5.6から追加された事を知って
お、ROWでもいけるじゃーんとこちらにしてしまいました。
弊社、負の遺産triggerの管理やらいろいろとあって
definerを意識しなくて良いROWフォーマットにできたのはラッキーでした。
他にもいけてない設定修正やパフォチューなどはやったものの、
リプレイスに影響しそうなパラメータはこのくらいでした。
・CasualにMroonga
リプレイスする理由の一つは全文検索でした。
って事でMroonga入れちゃおうという事に決めました。
でもでも、旧サーバーはMySQL Enterprise契約していて、
新サーバーどうするか決めきれてなかったわけです。
んで困ったのがMySQL Enterpriseはsource公開していないというorz。
まあでも、MySQLのEnterpriseとCommunityってコアな部分はほとんど差が無いみたいだし
MySQLはbinary版若しくはRPMを使い、Mroongaのインストール時に指定するsourceは
対応するバージョンのCommunity版sourceを使えばできるんじゃないかなーと思って実施してみました。
インストールはbinary版。
Mroongaインストールのために同バージョンのMySQL sourceを用意する。
そしてMroogaインストール時にはそのsourceを指定する。
./configure PKG_CONFIG_PATH=/usr/local/lib/pkgconfig --with-mysql-source=/usr/local/src/mysql-5.6.20 --with-mysql-config=/usr/local/mysql/bin/mysql_config
結果は問題無し。
一応、Mroongaのマニュアルの2.7.13にはパッケージを使う事はできませんと書いていますが
この方法だと現状は使えるようです。
MySQL Enterpriseでも使えましたので自己責任の範疇で使用すれば良いかと思います。
ちなみに、Mroongaを入れたからと言って、
MySQLの機能に関してはMySQL Enterpriseの保障外にはならないそうです。
・Casualに実行
旧サーバー(5.5)から新サーバー(5.6)へ事前にレプリケーションを張っておいて
当日はSlaveはLVSの振分け、Masterはkeepaivedの設定で完了です。
5.6のMasterとなるサーバーについてはmysqldumpで作りました。
このタイミングじゃないとできない巨大テーブルの圧縮などが必要であったため
mysql_upgradeだと要件満たせなかったという理由があります。
はい、Casualにリプレイスとバージョンアップ完了です。
実際にはbackup環境の調整とかバージョン違いの比較テストとか
Casualじゃなくて面倒な作業や泥臭い作業もありましたけどね。
Calendar書いているような人が試した事無いかもしれないのはCasualにMroongaくらいですかね。
これからリプレイスなどが必要な人にお役に立てれば嬉しいです。
明日は・・・。あれ、明日書く人が決まってない。誰かよろしくお願いいたします。
12c
最近、モチベが上がらないのですが、Oracle新バージョン出たから少し書いてみる。
なんか、ラリーが以前のイベントで一ヶ月以内のリリースがどうとか…。消されたくないからやめておこう。
私もすぐにインストールを試したんですが、何故かzipのDLがうまくいかず、
結局できたのは今週の月曜7/1でした。
マニアな方々は既にRAC組んだりしてますからね。皆さん、すごいパワーですよね。
とりあえず使った感じは…、まあ普通にOracleですよね、sqlplusで繋ぐ限りは。
9iに繋げなくなったのは嬉しい。これで、レガシーシステムへのDBリンクなどが減るに違いない！
EM expressはまだ慣れない…。見た目は綺麗。慣れたら使いやすいかもね。
11gからの変更点などはまだ読み途中です。英語辛い…。
コンテナもまだよく理解せず。
まあ、適当に弄ってみます。
取り留めの無い文章で失礼しましたー。
もう一つSQL
昨日、ひどいSQLの話をしたけど、
あれはOracleのバグかなければパフォーマンスにたいした影響は無し。
なので、今日はもう一つひどかった例にいってみる。
select count(*) from aaa
where (:1=1 and :1=status) or (:1<>1 and :1<>status)
…まず、書き方から非常にわかりにくかった。
多分、プログラム側からの視点でデータを見るから
変数=statusって書き方なんでしょうね。
SQLの内容は変数が1ならstatusが1のカウントを取るし、
1以外であればstatusが1以外の全てのカウントを取るという処理。
昨日と同じく、変数チェックはAPでやって、
DBには単純な処理をさせるべきですね。
更に今回は昨日のSQLと違い、
orを使ってるためパフォーマンスは劣化します。
インデックスやレコード数などの状況によっては相当な差が出ます。
常識的な作りならAP側で引数が1かどうかをチェックして
where status=1もしくはstatus<>1の2つのSQLどちらを使うか
判断させるべきですね。
外注さんなんかに頼むと、
WASでいろいろ作りこむのが面倒だからって
パフォーマンスを完全に無視したこういうSQLを作ってきたりします。
レコード数が増えた時の運用など考えなければ
DB側に処理させるのが開発は楽ですからね。
気をつけましょー。
変なSQL動作みっけ
外注がひどいSQLを書いてた事をきっかけに
下記のSQL、旧バージョンだと実行計画バグってんのね。
where data=nvl(:1,:2)
サポートページに行くと既に情報があったから、
詳細は書けないけど。
問題はバグじゃなくこんなSQLを平気で作る人だよね。
引数はAP側でチェックしてからDBに引き渡す。
WASは簡単に台数増やせるけど、
DBはそうはいかない。
これ、基本ですね。
気をつけましょー。
ちなみにサポートページの文書番号は135240番でっす。
nvlはOracle使いしかわからないから親切じゃなかったので追記。
mysqlで言うifnullですね。
引数なんだからAP側で引数の変換処理をして、
DBにはできるだけ単純な処理をさせましょうね。
備忘録sqldeveloper
developerはide.conf、datamodelerはdatamodeler.confのXmxを書き換える、と。
中途採用面接する際の質問
最近、友人から中途採用面接する際にどんな質問するか聞かれて
「困った時にどんな対応をして対応したか」はだいたい聞くって答えた。
この質問、どこかのブログに
「こんな質問じゃエンジニアの能力はわからん」
って書かれてたんだよね。
ソニックガーデンの伊藤さんのブログ
(http://junichiito.hateblo.jp/entry/20120620/1340148114)などを見て
言ってたようなんだが、
このやり方は一定数以上の社員がいる企業でやるのはほぼ無理。
んで、さっきの質問だけど、
この質問って技術力を知るための質問じゃないんだよね。
どういうアプローチで問題を解決するかを知りたいんだよね。
その時点で技術や知識が足らなかった時に
どんな対応をする人かってのは会社側としてはとても知りたい事。
ちなみに、僕はその質問で間が空いた場合は
「困った事じゃなくて工夫して成功した事でもいいですよ」って付け加える。
エンジニアの能力がわからんなんて頑なになるくらいなら
「困った事が思い浮かばないので、工夫して成功した事でいいですか？」
などと逆に聞き返せばその人の株が上がり、
コミュニケーション能力も評価されるのになと思う。
普通は転職活動の時って
前の企業に所属した状態でやってるから、
ソニックガーデンさんみたいな事は転職する側も厳しいだろうしね。
会社側も短い時間の中で
なんとかしようとしているわけですよね、うん。
転職
12月末付けで会社退職で、1/4から新しい会社。
これまで３回の転職をしたわけだが
多分、今回が一番楽な転職活動だった。
今までの転職は間違ってはなかったのかなーと思った。
１度めの転職理由はもっと専門的な事やらせてほしいって理由。
一社目はNがつくとこの孫請け仕事が多かったから
やりたい事やらせてくれなかったんだよね。
２度目の転職理由は会社の方向性が変わった事と
BtoCのトラフィック量をさばいたり、OSS知識が欲しかった事。
後はちょっと責任者的な立場も欲しかったかな。
一応、今までは自分が欲しいものを補うように転職できたと思う。
３度目の転職は年齢的にもあれだし、
権限も今まで以上にもらえそうな感じだし、
今までの集大成とするよう頑張ろう！
