JAWS-UG 初心者支部#13 「AWS Night school」での発表資料です。 https://jawsug-bgnr.connpass.com/event/94301/
ネタ的には 発掘するたび書き溜めてきたブログ記事 から 笑いが取れそうなものを 大事そうなもののみをピックアップして紹介した感じです。 知らないと致命傷、でも知ってれば予防できる(はず) MySQL 5.7で不幸になる人が1人でも少なくなってくれることを願っています。 さて、今年のYAPC::Asiaはメイントラックもトークを応募していたのですが見事に落選したので、1日目は完全にリラックスして過ごしました。LTの採否、当日になるまでわかんないのか大変だなーとか、他人事だったんですが、 1日目のLT見るじゃないですか。 面白いじゃないですか。 俺もしゃべりたくなるじゃないですか。 なったんですよ!!1 が、翌朝になってLTの応募ページをたどってみると
11. I'm yoku0825 ● とある企業のDBA ● オラクれない ● ポスグれない ● マイエスキューエる ● 家に帰ると ● 嫁の夫 ● せがれの父 ● 馬鹿だからかわいいわけじゃなくて、かわいい イルカがたまたまバカだった 12. はじめに ● サンプルデータは MySQLのサンプルデータ ベース(worldデータベース)からインデック スを全て取っ払ったものです ● http://dev.mysql.com/doc/index-other.html ● コードはgithubに上げてあります ● https://github.com/yoku0825/yapc_2014 ● すごく…ウンコードです… 13. はじめに ● 原則、MySQLは1つのテーブルにつき同時に1 つのインデックスしか使いません ● Index mergeとかあるけどアレは例外だし狙って やっても速くなる
InnoDBにはデータの圧縮機能がありますが、パフォーマンスが低いことからあまり使われていません。ただ今年の Percona Live で Oracle MySQL, MariaDB, そして Percona Server が新しい InnoDB Compression を出してきました。これはFusion-ioの R&D チームがフラッシュストレージ向けの MySQL 高速化の一環で開発したパッチが元になっています。ちなみに私は Fusion-io の社員ですのでこの発表をワクテカして待っていたのですが、折角コードが一般にリリースされたので、ソースコードを眺めて動作を調べることにしました。 参考にしたのは MySQL Server Snapshots (labs.mysql.com) にあるMySQL with InnoDB PageIO Compression のソースコード、およびM
トランザクションとは 1つの作業単位として扱われるSQLクエリの集まりです。 複数のUPDATEやINSERTをひとつの集まりとして、 それらのクエリがすべて適用できた場合のみデータベースに反映します。 ひとつでも適用に失敗したクエリがあった場合は、そのまとまりすべてのクエリの結果は反映しません。 ACID特性 トランザクション処理に求められる4つの特性です。 原子性 (Atomicity) トランザクションに含まれる手順が「すべて実行されるか」「すべてされないか」のどちらかになる性質。 一貫性 (Consistency) どんな状況でもトランザクション前後でデータの整合性が矛盾なく保たれる性質。 分離性 (Isolation) トランザクション実行中は、処理途中のデータは外部から隠蔽されて他の処理に影響を与えない性質。 永続性 (Durability) トランザクションが完了したら、シス
Deployment Guide Introduction Expand section "Introduction" Collapse section "Introduction" 1. Document Conventions 2. Send in Your Feedback I. File Systems Expand section "I. File Systems" Collapse section "I. File Systems" 1. File System Structure Expand section "1. File System Structure" Collapse section "1. File System Structure" 1.1. Why Share a Common Structure? 1.2. Overview of File System
以前、ある環境のデータベースを作ったときは、忙しくて手が回らないという理由で ユーザやデータベースのセットアップは script リソースを作ってえいやと済ませてしまった tk0miya です。こんにちは。 今回はすべて community cookbook で環境を作る方法をまとめてみました。 やり方が分かってしまえばシンプルに実現できるので、泥臭く script リソースを作らずに済みそうです。 鍵は database cookbook ユーザやデータベースを作るレシピが mysql cookbook に入っていないため、 公式には提供されていないものといままで諦めていたのですが、 調べてみると mysqll cookbook ではなく database cookbook でリソースが提供されているようです。 以下、README の説明です。 The main highlight of
KLab Advent Calendar 2011 「DSAS for Social を支える技術」の2日目は、昨日に引き続き、MySQLを骨までしゃぶるためのテクニックです。 ソーシャルゲームは一般サイトよりもDBへの更新クエリの割合が多くなりがちです。更新クエリが多いMySQLでは、通常は有益なクエリキャッシュが無益どころか有害になります。 そもそもキャッシュヒット率が低い。20%以下なんてこともザラにある しかもクエリキャッシュの更新はグローバルなロックを取得する からです。特に後者は問題です。ただの参照クエリもクエリキャッシュを更新する上に、更新クエリはクエリキャッシュの全エントリをチェックして、更新したテーブルに影響がありそうな全キャッシュをdiscardしていくためです。たとえばユーザーの行動力のようなパラメータを格納した参照も更新も多いテーブルでクエリキャッシュが有効になって
https://github.com/rackerhacker/MySQLTuner-perl MySQLTunerはMySQLのチューニングを診断してくれるアプリケーションです。 基本的なパフォーマンスチューニングのヒントをわかりやすく表示してくれます。 MySQLのチューニング設定に不安な方や、はじめてMySQLをさわる方は試してみると良いでしょう。 ライセンスはGNU GPLで無料で使えます。 検証環境 CentOS 6.3(64bit) MySQL 5.5.28 MySQL 5.5をインストール MySQL 5.5をインストールします。 # wget http://rpms.famillecollet.com/enterprise/remi-release-6.rpm # wget http://ftp.jaist.ac.jp/pub/Linux/Fedora/epel/6/x86
ちょっと前まで DBI で非同期アクセスなエントリが各所で上がっていましたが皆さん如何お過ごしでしょうか? さてと、、、歴史的な経緯とか歴史的な経緯とかで生 DBI 相当を使ってる方もそれなりにいるでしょう。奥さん、大事な事なんで二度言いましたよ! DBI のインターフェースってまぁそんな使いやすい物じゃないんですが、工夫次第で出来る事もあります。 ちなみにサンプルデータベースとして、MySQL Documentation - Example Databases の world データベースを使っています。 fetchall_arrayref でデータ整形 まず以下のように使ってみます。 #!/usr/bin/perl use strict; use warnings; use Data::Dump qw(dump); use DBI; use Perl6::Say; my $dbh =
テーブルにカラムやインデックスを追加するといった、いわゆるスキーマの変更を行うときは、通常、サービスをメンテナンスに入れてから作業をしなくてはいけません。理由は、ALTER TABLE実行中は共有ロックがかかってしまうため、更新クエリを実行しても即座に完了しなくなるからです。そうすると、アプリからみればおそらく更新クエリを発行するページではHTTPタイムアウトになりますし、参照だけのページでもかなり遅くなることでしょう。 サービスの改良をすると必ずスキーマ変更が必要になりますが、しかしサービスは可能な限り24時間365日提供したいもの。Percona Toolkitの pt-online-schema-change はそんな悩みを払拭し、サービスを停止すること無くスキーマの変更を可能にしてくれます。 概要と仕組み Percona Toolkitは全てPerlスクリプトなので、/usr/bi
バグの話 近々ふぁぼったーDBのInnoDB化を企てているので、それに伴いMySQL5.0.67(Tritonn)から、先日リリースされたばかりのMySQL5.5.3-m3に乗り換えてみた。RC(リリース候補)版ということで、GA版とほぼ変わらない品質と聞いたので、割と軽い気持ちでインストールしたんだけど、いきなりバグにハマった。 バグとは、DATETIME, TIMESTAMP, DATE, TIME型と文字列定数との結合でインデックスが使われない、というもの。 以下のような、date(DATE型)の結合しかしていないクエリでも、dateインデックスが使われず昇順フルテーブルスキャンされ、20秒くらい掛かった。 select date from STATUS force index(date) where date='2010-01-19' limit 10; この現象は、5.5.3,5
クリアネオの特徴 無添加・無着色だから肌が弱い人でも安心 ワキガや嫌な臭いの原因となる菌を殺菌・消毒 お得な定期コースは、購入縛りなし!いつでも解約可能 体臭の悩みは老若男女問わず共通の悩みですが、他人には相談しにくいので1人で悩んでいる人が多いんです。 体臭って、自分でニオイが気になった時は、他の人はもっとクサイと思っています。 もしあなたが、自分でワキガかも…と思うのであれば、周りの人はあなたのニオイに気づいているかも… クリアネオは、そんなワキガ臭や足のニオイなど、イヤーな体臭全般を10秒でカットしてくれるんです。 クリアネオの効果や口コミを調査しましたので徹底解説します。 購入時に特典が付いてくるのでお得 公式サイトはコチラ ※特典は毎月変わるので公式サイトでご確認ください クリアネオはどんな人におすすめ? クリアネオの殺菌率は、なんと99.999%!体臭の悩みを解消してくれるクリ
2012年6月のエントリの続きです。前回は同期レプリケーションによるネットワーク遅延のある環境において、MySQLの性能がどの程度低下するのかということを確認しました。その中でも特にsync_binlogが1に設定されている場合、性能が大きく低下するということが分かりました。参考としてAmazon RDSのマルチAZデプロイメントにおいては、性能と信頼性のトレードオフを考慮した結果、sync_binlogがデフォルトで0に設定されているということを調査しました。 タイトルでネタバレしていますが、MySQLの次期バージョン、MySQL 5.6でこのsync_binlog=1の性能が大きく改善します。前回と同じ負荷テストをMySQL 5.5.25からMySQL 5.6.6-labsに差し替えて行った結果を、以下に示します。 前回のMySQL 5.5.25と異なり、sync_binlog=1にお
5. On-Demand WorkforceWorkforce On-Demand On-Demand Workforce On-Demand Workforce On-Demand Workforce Our Service (livedoor) Amazon MechanicalAmazon Mechanical Turk Mechanical Turk Amazon Mechanical Turk Mechanical Turk Turk Amazon Amazon t/ Workers Workers Requester Requester On-Demand WorkforceWorkforce On-Demand On-Demand Workforce On-Demand Workforce On-Demand Workforce Amazon MechanicalAmazon
どうも俺です。 昨日に引き続きMySQL関連のテーマをメモします。 mysqldumpでデータをダンプ&別サーバへリストアなんて事あると思います。 その時に文字化けで少しハマったのでメモしておきます。 色んなブログにも記されていますが、mysqldumpでデータを取得すると自動でutf8で取得されてしまいます。 利用しているデータベースがsjis(cp932)を利用しているとします。 mysql> show variables like '%char%'; +--------------------------+---------------------------------------+ | Variable_name | Value | +--------------------------+---------------------------------------+ | cha
NHNテクノロジーカンファレンスにいってきた。 DeNAでのMySQL運用の話。岩永さんが話をしてくれたおかげでこれから外で話せますありがとうございます! という具合。 実に実直で正直で手間をかけた運用で、なおかつその手間をなくすためのツールの開発、アプリケーションも一体となったとりくみのすばらしい実例だと思う。 このセッションではAWSならばの話は当然いっさいなかったのだが、AWSのMySQLサービスであるRDSならどうするのかを書いてみる。 サービスが縮小するときの話。スケールバック(スケールイン)時に2つあったマスターDBの数を減らす。その際にはosの上に二つ目のMySQLをたちあげる方法をとっている。二つ目のMySQLは違うIPアドレスで立ちあげて、それをbind-addressを指定している。 RDSを使っているならば、サービスを縮小するならば、大きなインスタンスから、小さなイン
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
処理を実行中です
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く