MySQLを割と一人で300台管理する技術2017/09/05 db tech showcase Tokyo 2017 http://www.db-tech-showcase.com/dbts/tokyo
MySQLを１〜２時間でスケールアウトする - クックパッド開発者ブログ
最近、Elastic BeanstalkやECSと戦っているSREチームの菅原です。 P5をやりたいのにPS3もPS4も持っていないので指をくわえて羨ましがっている毎日です。 この記事では、突然のアクセス増に備えるために、MySQLのスレーブを１〜２時間でスケールアウトできるようにした話を書きます。 MySQL on EC2 クックパッドは周知の通りAWSを利用していますが、主要なデーターベースについてはAmazon RDSではなくMySQL on EC2を使っています。 これは以下のような理由によるものです。 歴史的な経緯: AWS移行当時、RDSが無かった。また、移行後もしばらくはTritonnを使っていたため、RDSを使うことができなかった オンラインメンテナンスの実現: VPCルートテーブルを使った仮想IPとMHA for MySQLを使ってダウンタイムゼロのマスタDBの切り替えを
Designing Schemaless, Uber Engineering's Scalable Datastore Using MySQL
While all three systems are able to scale linearly by adding new nodes online, only a couple systems can also receive writes during failover. None of the solutions have a built-in way of notifying downstream dependencies of changes, so we would need to implement that at the application level. They all have indexes, but if you’re going to index many different values, the queries become slow, as the
100Mにスケーリング：Key-ValueストアとしてMySQLを使い、NoSQL以上のパフォーマンスを出す | POSTD
100Mにスケーリング：Key-ValueストアとしてMySQLを使い、NoSQL以上のパフォーマンスを出す MySQLはNoSQLよりも優れています。Key-ValueストアといったNoSQLのユースケースを考えてみると、パフォーマンスや使いやすさ、安定性の点でMySQLの方が合理的です。MySQLには、オペレーションや障害に関することからレプリケーションや異なる使用パターンまでと、多くのオンラインマテリアルが用意されおり、堅実なエンジンです。こういった理由から、比較するまでもなく、MySQLは最近のNoSQLエンジンよりも優れていると言えます。 ここ最近では、NoSQLエンジンが主流になってきています。多くの開発者が、MongoDBやCassandra、Redis、HadoopといったNoSQLエンジンをアプリケーション構築の第一候補としており、それらが全て昔からのSQLエンジンを上回
[MySQL]INT型の最大値(IntegerのMAX値2147483647)を覚える方法 · DQNEO日記
「2147483647」は、「２１億」と覚えます。 「２１億」を分割して、「１０億＋１０億＋ちょっと」と覚えます。 １０億という数字、身近で聞いたことありませんか？ １０億人。そう、中国の人口とインドの人口です。 ２００９年時点で、中国の人口は１３．４億、インドの人口は１１．９億です。 中国＋インドは２５億人です。INT型の最大値を超えました！ 例えば、あなたがTwitterのようなすごいサービスを開発したとします。 その際、会員テーブルのIDをINT型で定義したとします。 サービスが大人気になって会員が激増しました。 すると何が起こるでしょうか？ インド人と中国人の全員が会員登録し終わる前に不具合が発生して、あなたは対応に追われます。 ※ ちなみにPostgresでもそうなります。 http://www.postgresql.jp/document/current/html/dataty
ルーク！MySQLではkamipo TRADITIONALを使え！ | おそらくはそれさえも平凡な日々
よくMySQLはゆるふわだから 値が勝手に切り詰められる エラーが起きずに変な値/日付が入る 不正なスキーマが入ってしまう など言われることがあります。ただそれは、そもそもの設定が悪いのです。(確かに昔デフォルトがゆるふわなのはいけなかったんですが) ということで、データベースには不正な値が入らないように設定はとにかく厳しくしておくのがオススメです。 じゃあどうするか。 MySQLはSQL Modeによって、その辺りの制約をコントロールすることができます。以前、MySQLのsql-modeで一番厳しいやつはTRADITIONAL、というのを書いたのですが、実はそれだけでは不十分で、TRADITIONAL,NO_AUTO_VALUE_ON_ZERO,ONLY_FULL_GROUP_BYとするのがより安心なようです。 これはkamipoさんに教えてもらいました。 @songmu TRADITI
Mysqldump complains about chosen databases regardless of command line
Mysqldump complains about command line options I have never specified. I don't have shell aliases nor a custom .my.cnf file set. What am I doing wrong? Using the --database long option: $ mysqldump --user cloud -p --database cloud > backup.mysqldb Warning: Using unique option prefix database instead of databases is deprecated and will be removed in a future release. Please use the full name instea
MySQL Casual Talks vol.8で喋ってきた | Ore no homepage
先日行われたMySQL Casual Talks #8で登壇してきた。会場を貸してくださったテコラスさん、主催者ならびに参加者の皆様ありがとうございました。 発表のネタ ネタは「トレタのMySQL」と「はじめてのRails+MySQLの運用でOctopusでハマったこと」の二つを用意したんだが、後者は内容がRailsに寄りすぎていたというのと、時間的にもアレだったので自粛した。 小規模限定回ということだったんだが、そもそもウチは小規模なんだろうか？という疑問があった。なので「これできるの小規模だからだよなぁ…」と思えることを捻出して喋ってみた。 トレタのMySQL 内容的には、 小規模だと、Likeで全文検索とかアンチパターンみたいなことやっててもでも割と動くよ。 小規模だと大規模に比べて運用は楽。でもこれは台数が少ないからということではなく、アーキテクチャがシンプルだから。 大規模であっ
Airbnbのメインデータベースをどうやって2週間で分割したか | POSTD
スケーリング＝時速160㎞で走行しながら自動車の全ての部品を取り替えること －Mike Krieger Instagramの共同設立者＠ Airbnb OpenAir 2015 Airbnbのピーク時のアクセス数は、毎年夏のピーク時で見ると年率3.5倍で増加しています。 2015年夏の旅行シーズンを前に、Airbnbの基盤チームは、夏季のアクセスで予想されるデータ通信量に対処するため、データベースのスケーリングで忙殺されていました。中でも特に全体への影響が大きかったプロジェクトが、特定のテーブルを、アプリケーションの機能に従ってそれぞれのデータベースに分割することを目的としたプロジェクトでした。これは通常、アプリケーション層のフォームの変更やデータ移行、データの整合性を保証する堅牢性テストなど、最小限のダウンタイムで多大な技術的投資を必要とするものです。何週間もかかるエンジニアリング時間
MySQLでハイパフォーマンスなアクセスカウンター - まるまるこふこふ
MySQL を使ってアクセスカウンターを作ってみたいと思います。 テーマは 1, 高速(できうる限りカウンタの更新・参照を速くする) 2, 高信頼性（多重アクセスがあっても壊れない。不整合が起こらない） です。 愚直に実装してみる。 まずは直感でザクっと作ります。 テーブル作成 CREATE TABLE counter ( cnt int unsigned not null ) ENGINE=InnoDB; 参照 SELECT cnt FROM counter; 更新 UPDATE counter SET cnt = cnt + 1; はい。解説の必要もないほどシンプルな内容だと思います。 ですが、このアクセスカウンターは高速とは言えません。 何故かというと、MySQLでは更新の際に対象の行にロックをかけるので、 例えば同時に100人アクセスがあったとしたら、100人同時にアクセスカウンタ
[MySQL5.7]マルチソースレプリケーション設定方法 – (っ´∀｀)っ ゃー | 一撃
プライベートIPアドレスはeth1に振っています。さくらのクラウドでCentOS7のeth1にIPアドレスを振る手順はこちらを参考にどうぞ。 今回構築するサーバーの、マスターとスレーブの関係は以下の通りです。 master0 は test0 データベースのマスター。チャネルは0 master1 は test1 データベースのマスター。チャネルは1 slave0 は 上記すべてのデータベースのスレーブになる slave1 は 上記すべてのデータベースのスレーブになる ちなみに、マルチソースレプリケーションはマルチマスターレプリケーションとイコールではありません。 こちらの図表を見ると違いが一目瞭然ですが、マルチマスターレプリケーションは循環型のレプリケーションで、SQLクライアントはどのノードに書き込みを行っても、レプリケーションを構成するすべてのノードに等しくデータが同期されます。いっぽう
![[MySQL5.7]マルチソースレプリケーション設定方法 – (っ´∀｀)っ ゃー | 一撃](https://cdn-ak-scissors.b.st-hatena.com/image/square/7b3c95b122706ca08a954d95d4671c7f8ae0bcc8/height=288;version=1;width=512/https%3A%2F%2Fnullpopopo.blogcube.info%2Fwp-content%2Fuploads%2F2015%2F10%2Fmysql57_20151025_0002.png)
mysqldump+bin-logによるInnoDBのbackupの設定とPerl実装スクリプト | hirobanex.net
若干それますが、あまりに対応するのもどうかと思いますが、ディレクターや顧客が「あのデータ手が滑って削除にしちゃったんだけど、やっぱり戻せない??」っていうのを無視するのはどうかと思いますし、開発時とか運用当初はいまいち要件も定まっていないことが多いはずなので、そういう観点からもしっかりそのほかの手法も組み合わせるべきですよね? 実際の組み合わせ 運用状況に応じて以下のように組み合わせるのが一般的ではないでしょうか? [Web型]mysqldump系 + bin-log + レプリケーション [Web型]mysqldump系 + レプリケーション [どうでもいい系,α版]mysqldump系 + bin-log [バッチシステム]mysqldump系 バッチの場合は楽ですね。で、今回はたいしてお金ないんだけど、まぁしっかりバックアップっぽいことをやりたいケースへの対応として最低限の「mysq
#yapcasia でMySQL 5.7の罠についてLTしてきました
ネタ的には 発掘するたび書き溜めてきたブログ記事 から 笑いが取れそうなものを 大事そうなもののみをピックアップして紹介した感じです。 知らないと致命傷、でも知ってれば予防できる（はず） MySQL 5.7で不幸になる人が1人でも少なくなってくれることを願っています。 さて、今年のYAPC::Asiaはメイントラックもトークを応募していたのですが見事に落選したので、1日目は完全にリラックスして過ごしました。LTの採否、当日になるまでわかんないのか大変だなーとか、他人事だったんですが、 1日目のLT見るじゃないですか。 面白いじゃないですか。 俺もしゃべりたくなるじゃないですか。 なったんですよ！！１ が、翌朝になってLTの応募ページをたどってみると
[MySQL] テキストにはVARCHAR型と?TEXT型のどちらを使うべきか？ – 端くれプログラマの備忘録
MySQLのテキスト型にはVARCHARと?TEXT(TINYTEXT、TEXT、MEDIUMTEXT、LONGTEXT)がある。長さの制限が違うだけで、どれを使ってもテキストを格納できるが、それぞれ特性は違うのだろう。プログラミングを実践する上でどのテキスト型を使うのが適切なのか判断できるように、これらの違いについてきちんと理解しておきたい。 ざっくりググってみると、テキスト型の違いを論じているページがいろいろ見つかる。 Takahiko HORIUCHI – Google+ – RDBMS に MySQL を採用したシステムで、VARCHAR の代わりに TEXT… https://plus.google.com/113405959631093302363/posts/E4tDXucskqb VARCHAR と ?TEXT の違い – ngの日記 http://ngyuki.haten
mysqldumpで出力したsqlを実行するときにはLOCK TABLESオプションに注意する
仕事でMySQLを触る時間が増えてくると、いろいろ知らなかったことやハマりが出てくる。いろいろ勉強になって楽しいなぁと思いつつ、今週引っかかったネタをひとつご紹介。 概要mysqldumpコマンドでダンプしたSQLは、デフォルトオプションではテーブルロックが付与されている。INSERTを高速にする効用があるが、投入するユーザに「LOCK TABLES」の権限がないと失敗する。 % mysql -u{username} -p{password} {database} < dump.sql error: 1044: Access denied for user '{username}'@'localhost' to database '{database}' when using LOCK TABLES 詳細と対策ダンプ時に対策するか、ユーザに権限を付与することで投入できるようになる。今動いて
MySQLレプリケーションを安全に利用するための10のテクニック
MySQLのレプリケーションは非常に簡単に使える割には応用の幅が広いので非常に人気のある機能の一つである。レプリケーションの応用分野は例えば、 バックアップ 参照系の負荷分散 HA（高可用性） ディザスタリカバリ（サイト間レプリケーション） BI（レポーティングetc） という風にとても多くのバリエーションがある。このブログを読んで頂いている皆さんの中にもレプリケーションを使っている方は多いのではないだろうか。ご覧の通りMySQLのレプリケーション機能はミッションクリティカル分野でも利用されているが、レプリケーションの使い方が適切でないとシステムの安定稼働に支障を来してしまってDBAやシステム管理者の肉体的、精神的負担が増大してしまう。逆にレプリケーションを堅牢に運用することが出来ればマクラを高くして眠れるというものだ。レプリケーションはMySQLの代表的な機能であるので、レプリケーション
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
ヤフー社内でやってるMySQLチューニングセミナー大公開
Import CSV to Update only one column in table
MySQLで2億件のデータ投入に75時間！？だが増強は無理！だったら徹底的にチューニングしてやるぜっ #yapcasia #yapcasiaD #MySQL
MySQL high "sy" (kernel) CPU time