docker composeでMySQLのデータ領域をローカルにマウントする
この記事は12/1のDocker2 Advent Calendar, 12/3のHamee Advent Calendarの記事です。 こんにちは。 docker composeめちゃくちゃ便利ですよね。 Chef, Vagrant, Puppet, Ansible, Fabric…とプロビジョニングツールとか仮想化ツールを色々触ってきましたが、 それらよりずば抜けて扱いやすいと思っているツールです。 で、ローカルで開発している時に困るのが、 MySQLをはじめDBにデータを持ってもコンテナを破棄するとデータがすっ飛ぶ 問題です。 軽量なアプリの場合ならDB破棄してシード流して、、、という構成でもイケるかも知れませんが、多くの場合オーバーヘッドが大きすぎてまともに開発できなくなると思います。 Docker for Macを使用している場合はこの問題は難なく解消できるのですが、 docker
pt-online-schema-changeと5.6 InnoDBのオンラインALTER TABLE使い分け
この記事は MySQL Casual Advent Calendar 2015 の9日目です。 MySQL 5.6から InnoDBのオンラインDDL が導入されて久しいですが、一方で pt-online-schema-change (以下pt-osc）もまだまだ元気です。MySQL 5.5とそれより前ではpt-osc一択になりますが、MySQL 5.6とそれ以上の場合はInnoDBさんに任せるかpt-oscを使うかを選択することができます。 MySQL 5.6でもpt-osc一択にしても構わないといえば構わないんですが、いくつかのケースではInnoDBさんに任せた方が速くなったり安定したりするので、そのあたり解説していきます。 TL;DR ウチの使い分け。 原則 pt-osc スレーブの台数が多すぎない かつ データ容量が馬鹿でかくてストレージ食いつぶしそう または INSERT大杉で2
無停止でALTERできるPercona-Toolkitのonline-schema-change - FAT47の底辺インフラ議事録
MySQL5.5をまだまだ絶賛利用中な私です。 サービスを運用しているとINDEX追加やカラム追加を行いたい要望が多々発生します。 それも無停止で。 MySQL5.6からは無停止でINDEX追加やカラム追加ができるオンラインDDLが実装されました。 カラム追加はまだ色々制約があるみたいですが…。 http://dev.mysql.com/doc/refman/5.6/en/innodb-create-index-overview.html pt-online-schema-change MySQL5.5でも似たようなことをやりたいので、 有名な「Percona-Toolkit」に同梱されているpt-online-schema-changeを利用しています。 http://www.percona.com/software/percona-toolkit 通常はロックが掛かってしまうALTER
シンプルで移行しやすいデータベースシャーディング - クックパッド開発者ブログ
技術部の小野(taiki45)です。クックパッドではこれまで様々なデータベースの負荷対策を行ってきましたが、シャーディングは行われていませんでした。しかし先日クックパッドの認可サーバーが利用している MySQL サーバーの負荷分散のためにクックパッドで初めてのシャーディングを行ったので、Rails アプリケーションでのシャーディングの事例のひとつとしてその際の手法をご紹介したいとおもいます。 構成 Before データベースは1マスター、1ホットスタンバイ、バッチ用の1リードレプリカで構成されています。Read オペレーションのほとんどはキャッシュ層に逃しています。 After データベースの各ロールにつきそれぞれ1台ずつマシンが増えています。 シャーディングが必要になった背景 認可サーバーのアクセストークンの作成・削除時の Write オペレーションが急増し、レコード数自体も急増していて
MySQL Spiderエンジンを使ってみた。〜データベースシャーディング(sharding)とは〜 - 気ままに書いてみました日記
もしかしたら使うかもしれないので調べてみた。 shard 日本語に訳すと(ガラスや貝殻の) 「破片」といったような意味 データベースをshardに分解して複数のサーバに分散して運用するのがDB sharding データベースパーティショニングとも言えるのかしら？ 単一のサーバのDBテーブルを複数のファイルに分割するのをパーティショニングとも呼ぶが、「パーティショニング」という言葉を使ってDB shardingのことを言っているブログ等もちらほら見かけます。 より突っ込んでみたい人は「shared nothing」でぐぐってネ。 なぜデータベースを分散処理するのか 横軸にはサービス運用開始からの時間経過を設定し、縦軸には「DBの応答時間」、「DBへの問い合わせ数」、「DBサイズ」の各数量をとります。サービスが順調に利用されていっているものとし、「DBサイズ」や「DBへの問い合わせ数」は時間経
クエリキャッシュは切ったほうがいいんじゃなイカ？ : DSAS開発者の部屋
KLab Advent Calendar 2011 「DSAS for Social を支える技術」の2日目は、昨日に引き続き、MySQLを骨までしゃぶるためのテクニックです。 ソーシャルゲームは一般サイトよりもDBへの更新クエリの割合が多くなりがちです。更新クエリが多いMySQLでは、通常は有益なクエリキャッシュが無益どころか有害になります。 そもそもキャッシュヒット率が低い。20%以下なんてこともザラにある しかもクエリキャッシュの更新はグローバルなロックを取得する からです。特に後者は問題です。ただの参照クエリもクエリキャッシュを更新する上に、更新クエリはクエリキャッシュの全エントリをチェックして、更新したテーブルに影響がありそうな全キャッシュをdiscardしていくためです。たとえばユーザーの行動力のようなパラメータを格納した参照も更新も多いテーブルでクエリキャッシュが有効になって
MySQL - InnoDBのロック関連まとめ - Qiita
メモ開放。InnoDBの行ロック関連について、それぞれの項目が必ずしも並列関係にあるわけではないが、以下のようにまとめていく。 排他ロックと共有ロック SELECT ~ FOR UPDATE SELECT ~ LOCK IN SHARE MODE 排他ロックと共有ロック 読み取りを許すかどうかの違い。排他ロックは対象行を全てのクエリからロックするため、UPDATEやDELETEなどの更新クエリはもちろん、SELECTなどの読み取りクエリも通さない。共有ロックは更新クエリを通さないが、読み取りクエリは通す。 （追記：排他ロックは分離レベルによってはSELECTを通すとのこと。 公式 ） 排他ロックは全てのクエリを通さず、共有ロックは排他ロックを伴うクエリを通さない、と言い換えたほうがいいかもしれない。 公式では共有ロックは同トランザクション内のselectを許し、排他ロックは同トランザクショ
無料サービスを使え！ – 役立つ無料サービスのレビュー、まとめ、比較記事を紹介
コンテンツへスキップ 無料で使える！HubSpotの顧客リストの活用法 無料のアンケート作成ツール 比較／まとめ 無料「Excel」 テンプレート 比較／まとめ 無料で使えるノートアプリ比較 (Evernote / OneNote / Google Keep) おすすめの無料Web会議システム5選 WebP Converter 徹底解説！初心者でも直ぐに使える HubSpot は、マーケティング、セールス、サービスのためのCRM（Continue reading 多くの人の声を聞くことで改善できることも多い 企業や団体など運営していContinue reading 就職・転職には必須となる履歴書・職務経歴書 これから就職活動をスタートContinue reading 便利なノートアプリで効率的な仕事をしよう いつの時代も仕事をしていてメContinue reading 近年、リモートワーク
MySQLのダンプデータに書いてあった「SET SQL_MODE="NO_AUTO_VALUE_ON_ZERO"」について - メメメモモ
これが書いてあるか書いてないかで、ダンプした後のAUTO_INCREMENTのカラムの挙動が変わるらしい。 たとえば、mysqldump コマンドでテーブルにダンプして、リロードする場合に、MySQL は, 0 という値に遭遇すると、新たなシーケンスン番号を生成し、テーブルにダンプしたものとは異なる内容になるという結果を生む。ダンプ ファイルをリロードする前に NO_AUTO_VALUE_ON_ZERO を有効にすると、この問題を回避できる。 http://dev.mysql.com/doc/refman/5.1/ja/server-sql-mode.html:title=MySQL :: MySQL 5.1 リファレンスマニュアル :: 4.2.6 SQL モード
InnoDBのREPEATABLE READにおけるLocking Readについての注意点
本日は、MySQL Casual Advent Calendar 2013の20日目である。というわけでカジュアルに小ネタを紹介しよう。 MVCC - Multi Version Concurrency Controlご存知の通り、InnoDBはMVCCを実装している。そのため、分離レベルがREPEATABLE READの場合には、行にロックをかけることなく、一貫した読み取りが可能になっている。 もし、あるトランザクションT1開始後に、別のトランザクションT2によって同じ行が書き換えられてしまった場合には、T1はロールバックセグメントにある古いバージョンの値を読み取ることができるので、T1内で実行したSELECTは常にT1開始時点のデータを参照することができるのである。大事なのでもう一度言うが、REPEATABLE READにおける単純なSELECTでは行ロックは必要ない。 Lost Up
トランザクションの分離レベルを実装する - きしだのHatena
データベースの勉強に、最初はかわいかったけどだいぶゴツくなったデータベースを作っています。 http://d.hatena.ne.jp/nowokay/20120817#1345197962 前回で、なんとなくトランザクションがちゃんと動いたんですけど、 id:kiwanami に「隔離レベルとかの検討とか。」と言われて、そのときはちょっと難しいから後回しかなーと思ったんだけど、案外簡単に実装できそうだったので、ちょっとやってみました。 トランザクションの分離レベルというのは、他のトランザクション内での変更がどのように見えるかというレベルです。 次のような４つのレベルがあります。 READ UNCOMMITTED 未コミットの操作も見えちゃう READ COMMITTED コミットした操作は見えちゃう REPEATABLE READ コミットした追加・削除は見えちゃう。更新は見えない SE
1
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
AndroidのNFC機能でFeliCaの読み書きをする | −ゆめログ− | ゆめみスタッフブログ