社内勉強会でMySQLの運用について喋ってきた | Ore no homepage
すでにMySQLの運用テクニックは多くのTipsが出回っているので、考え方を中心に喋ってきた。主に、負荷が高い、レプリが遅延する、などについて。 資料 文字多めの資料になっている。オンプレでの運用が多いので、物理レイヤーの話も少しある。自己紹介だけ中途半端に英語。「資料を英語で書こうと思ったけど諦めたので、この後は全部日本語です」で、とりあえず一笑い取れた(失笑)。 こんな話をした↓ 負荷対策 SQLのチューニングはちゃんとしましょう。 ハードウェアリソースの負荷の箇所によって適切な対応をしましょう。 MySQLの設定は勘所を抑えて適切にしましょう。ただし、単なる数字いじりには意味はない。 ファイルシステムやそのオプションは、高トラフィック時に差が見えてくるので、留意はしておきましょう。 レプリケーションの遅延 資料の通りだよ。 MySQLは非同期(準同期)レプリケーションなので遅延は避け
Google BigQueryにMySQLのデータを入れる | Ore no homepage
肋骨が折れたかもしれん。痛え。それは置いといて…BigQuery。処理能力を体感したかったのでとりあえずMySQLの本番データをつっこんだ。fluentdでログも突っ込んでるんだけど、そっちはデータが溜まってないからまだおもしろくないかな。それについてはまた別途。まあ、fluentdでデータ突っ込むのはいろんな人がqiitaとかブログに上げてるし書くまでもないかもしれないけどね。 0. 作業の流れ MySQLからダンプを抜く ダンプをCloud Storageにuploadする Cloud Storage からbigqueryにインポートする クエリ投げる という流れになる。この記事では深く言及しないが、Google Compute Platformのコンソールでプロジェクトの作成やら課金の登録やらが済んでいて、作業を行うマシンにはコマンドラインツールがインストール済みであるとする。 コマ
開発支援系のサービスが充実しすぎて転職か廃業を考えた | Ore no homepage
なんて表現したらいいかわかんなくて、開発支援系サービスって謎表現したけど…。なんつーか、開発支援向けのサービス？クラウドってやつ？ってかいわゆる外部がやってくれる系のサービス(モニタリング/ホスティング/etc)が充実してますよね。んで、一介のWebエンジニアのおれがこの先生きのこるにはどうするかを真剣に考えていたところだった。きのこ。何割かはネタ。 思いついたものを挙げてみる。AWSやGitHubは割愛。言うまでもねーだろ…。 New Relic http://newrelic.com/ 有名なNew Relic。これも説明するまでもないかな。今のチームでコレのお金払う版を使ってるんだけど、「外部APIとの通信個所とDBとの通信個所が遅いように思えるので調査しますわ」→「それNew Relicで見れるよ」とか「各テーブルへのアクセス頻度集計しますわ」→「それNew Relicで見れるよ」
MySQL 今更ながらonline-schema-changeについて | Ore no homepage
そういえば先日はハロウィンだったね。んで、今日スタバに行ってみたら早くもクリスマス仕様。残念ながら年末の予定は無え。 そんなこんなでオンラインスキーマチェンジを本番のオペレーションで使い始めたのでそのメモ。 0. online-schema-change オンラインスキーマチェンジは、percona社が出しているpercona-toolkitに梱包されている。その他有用なツールも入っているのでお世話になっている人も多いだろう。で、オンラインスキーマチェンジはその名のとおり、スキーマの変更、alter文をブロックなしで実行してくれるという代物。 私事なんだけど、今までは「ちょっと更新をブロックしちゃうけどアクセスの少ない時間帯にオンラインでalterを流す」みたいな運用をしてた。実行内容にもよるけどalter tableは意外と早いので、「更新をブロックされる時間がSLA的に許可できるならO
MySQL ibdata1が肥大化する理由(記事の意訳) | Ore no homepage
毎日暑い…。というか蒸し暑い。何年か前にベトナムとカンボジアをバックパッカー旅行したときを思い出す。日本の気候が亜熱帯ってか東南アジアっぽくなってきたような…昔はこんな頻繁にゲラリ豪雨とか降らなかったよねー？温暖化ってやつ？日本の植生とか変わるんじゃねーのかな…。 えーと、おれがよく見ている技術ブログの一つにPercona社のMySQL Performance Blogがある。そのブログに先日、「Why is the ibdata1 file continuously growing in MySQL?」という記事が投稿された。内容はInnoDBのibdata1の肥大化とその解消方法に関するもの。ibdata1の肥大化を解消する手段は、ダンプをとってDBを作り直してあげないと治らないということは多くのInnoDBユーザが知っていることだと思うけど、おれもInnoDBを触り始めたころは、「気
MySQL バイナリログを使ったデータリカバリ | Ore no homepage
目黒川の桜きれいですね〜(*^^*)…なーんてガラじゃないことを言いたくなるくらい良い咲きっぷりでしたよ、エエ。で、来週末、花見に行くんだけど、まだ散らないでほしいっすねー。 えーっと、久しぶりにMySQLの記事。binlogを使ったリストア手法について。ネットを漁るとMySQLの運用に関する記事は多くヒットするんだけど、障害からのデータリカバリ、特にロールフォワードを扱った記事が思ったより多くない。おれは運が良いのか悪いのかMySQLのデータリカバリをしなければならないような局面に何度か直面しているので、手順について書いてみようかな、と。ここではMySQL〜5.5を対象にしている。直近での最新のメジャーバージョンはMySQL5.6なんだけど、おれはまだ5.6について大して知らない。5.6ならもっとイケてるやりかたがあるかもしれない。あったらいいな。 0. 環境 次のような環境を前提として
MySQL DBマスタのDC間移設 | Ore no homepage
システムをデータセンターAからデータセンターBに論理移設を行うときのメモ。 肝になるのはDB、特にマスタDBだと思うので、主題の通りおもにDBマスタの切り替えに焦点を当てて手順を書く。 移設先であるデータセンターBではサーバ構築やアプリケーション/コンフィグのデプロイは完了していて、新マスタおよび全スレーブは現マスタにレプリを張っている状態からスタートする。新マスタにはバイナリログ出力など、DBマスタとして振る舞うための設定が入っているものとする。 手順の要約 現DBマスタへの更新クエリをすべてブロックする 全てのスレーブと新マスタでshow slave statusしてログとポジションが一致していることを確認する 新マスタと全てのスレーブでstop slaveする 新マスタと全てのスレーブでreset slaveする 新マスタでreset masterする 全てのスレーブでchange
1
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
