サーバダウンしたニコニコ漫画に何が起きていたのか - BOOK☆WALKER inside
こんにちは。メディアサービス開発部Webアプリケーション開発課の奥川です。ニコニコ漫画のバックエンド開発を担当しています。 2021年初頭、ニコニコ漫画である作品の連載が開始されました。それに端を発する数カ月間のサーバ障害により、ユーザーの皆様には大変ご迷惑をおかけしました。 少し前の話にはなりますが、当時ニコニコ漫画のサーバでは何が起こっていたのか、どのような対応を行ったのかを振り返ってみたいと思います。 1号棟（事の起こり） 2021/01/08 問題の作品（以後、「作品I」*1と記述します）の第1話が投稿されます。その過激な内容からSNSなどでは一部で話題になりましたが、まだニコニコ漫画へのアクセスも穏やかなものでした。 2021/01/22 その2週間後、「第2話（前編）」の公開から事件が起こります。 ピークタイム最中の12:22頃から、まずmemcachedがCPU Utiliz
MySQL 8.0のクライアントでMySQL 5.7のサーバーに接続するとcharsetが設定されないかもしれない - かみぽわーる
mysql_options(mysql, MYSQL_SET_CHARSET_NAME, cs_name) だけして mysql_real_connect(mysql, ...) した後SHOW VARIABLESしてみたら接続のcharsetが設定済みの挙動をするんやけどmysql_real_connectからの一連のコード読んでもどこでそれが起きるのかわからん誰かたすけて🥲https://t.co/ZScoD3tIQ8— Ryuta Kamizono (@kamipo) February 20, 2021 MySQLのハンドシェイクパケットにcollation_idを1バイトだけ入れられるところがあって、charset name のデフォルトの collation_id を送っています。 クライアントとサーバーのバージョンが違うとデフォルトのcollation_idが違うことがあって
InnoDBのロックの範囲とネクストキーロックの話 - かみぽわーる
この記事はMySQL Casual Advent Calendar 2013 3日目の記事です。 はじめに 以前にSELECT ... FOR UPDATEとロックの挙動 - walf443's blogの記事にTwitterで少し言及したんですが、それの補足というか、InnoDBのロックの範囲について僕はこう理解していますよという話です。 MySQLといえば、InnoDBをネットワークサーバとして使うためのフレームワークであり、SQLはInnoDBのインデックスにアクセスするためのDSLといっても過言ではないでしょう。 InnoDBのロックとはつまるところインデックス行のロックなので、InnoDBのロックの範囲を理解するためにInnoDBのインデックスについて少し前置きしておきます(だいぶ端折ったけど長くなった…)。 クラスタインデックスとセカンダリインデックス すでにInnoDBのイン
ストレージエンジンであそんでみた
こうなるはずだったんですがlightningのVGA変換アダプタとmini display portの変換アダプタを間違えて持って行ってしまいましたorz 次回から忘れないように全部まとめてキーホルダーに付けようと思います（´・ω...:.;::..
LAST_INSERT_IDの限界 - 筋トレとともに生きるDBAの雑記
こんにちは。 突然ですが32bit/64bitの差を調べていて気づいたのでメモ。 32bitだともちろん32bitを超える数値をそのままでは扱えないわけですが、MySQL的にはどうなのよってことで特に値が大きくなりがちなid発番を見てみました。 弊社ではid発番をauto_incrementではなく、MyISAMなテーブルに対する以下クエリで発番しています。 CREATE TABLE `hoge` ( `id` bigint(20) unsigned NOT NULL ) ENGINE=MyISAM DEFAULT CHARSET=sjis update hoge set id=LAST_INSERT_ID(id+1) で、unsignedなんだから「18446744073709551615」までイケるだろ！ と思ったら mysql> select * from hoge; +------
MySQL 5.6のInnoDB memcached pluginを使ってみる - 酒日記 はてな支店
MySQL 5.6の RC 版が出ましたね。魅力的な機能が満載で皆さんwktkしていることと思います。早速、個人的に気になっていた memcached plugin を試してみました。 最初に結論から言いますが、現時点 (5.6.7rc) では HandlerSocket の代わりに使えるようなものではなさそうです。 memcached protocol でアクセスできるのは全体で 1 テーブルのみ 訂正: namespace という仕組みで複数テーブルにmapが可能です テーブルの文字コードは latin1 である必要がある 【2012-11-22 追記】5.6.8RCでは、文字コードが latin1 であるという制限は撤廃されました 「MySQL のテーブルに memcached protocol でアクセスできる」というよりは、「memcached のストレージを InnoDB にで
NoSQLの成功は1:10問題にかかっている:Kenn's Clairvoyance
ここ2-3年ほど、いわゆる非SQL系データベースがホットな話題になってきています。このムーブメントを総称して「NoSQL (Not-only SQL)」と呼ばれることが多いようです。まるでSQLを否定しているかのような誤解を招きやすい用語ですが、かといってキー・バリュー型データストアや列指向DBを総称できる他の呼び方もないので、このエントリではNoSQLという用語を使うことにします。 OracleやMySQLなどのSQLデータベースが成熟していく一方で、SQLデータベースを特徴づける弱点である柔軟性のなさ、堅牢さと引き換えに犠牲になった更新性能の低さ、スケールアウトの難しさなどから、「何でもかんでもRDB」から「目的に応じた永続化」が模索される流れになってきました。 時を同じくして、キャッシュサーバの世界でも、MemcachedのもつシンプルなAPIの使いやすさが評価される一方、LRUによ
MySQL 5.1.46リリース InnoDB Pluginが正式版に - SH2の日記
出ました。今回は機能追加が1件、バグ修正が55件あります。バグ修正のうちセキュリティに関するものが1件、パーティショニングに関するものが5件、レプリケーションに関するものが7件となっています。 MySQL 5.1.38から本体に付属するようになったInnoDB Pluginですが、バージョンが1.0.7に上がりRCからGA(Generally Available、正式版)となりました。ついに正式リリースです。というわけで何度か繰り返している話題ですが、今回はInnoDB Pluginについて再度おさらいをしておきたいと思います。 InnoDB Pluginの使い方 MySQL 5.1.38以降であればInnoDB Pluginを使うように設定するのは簡単です。/etc/my.cnfに以下の設定を書き加えることでInnoDB Pluginが有効化されます。 ignore-builtin-in
快適スケールアウト生活への第一歩。SPIDERストレージエンジンを使ってみよう！
先月、Not Only NoSQL!! 驚異的なまでにWRITE性能をスケールさせるSPIDERストレージエンジンというエントリでSPIDERストレージエンジンによるスケールアウトが凄い！という話を書いた。SPIDERストレージエンジンは凄いヤツだが、ノウハウがあまりウェブ上で見つからない。唯一見つかる日本語の記事は、ウノウラボによる「国産MySQLストレージエンジン「Spider」の作者、斯波健徳氏に聞く 」だけである。SPIDERストレージエンジンは斯波氏による単独の作品であるため、斯波氏は開発だけで手いっぱいであり、使い方の紹介記事を書くことまでは手が回らないのであろう。こんな凄いストレージエンジンをドキュメントが足りないせいで使って貰えないなんて勿体ない！！ というわけで、今日はSPIDERストレージエンジンの基本的な使い方について紹介する。少し長いエントリであるが、最後までお付き
Not Only NoSQL!! 驚異的なまでにWRITE性能をスケールさせるSPIDERストレージエンジン
Webサービスでは、世界中からのトラフィックを捌く必要があるため、いくらチューニングしようとも一台のRDBMSでは捌ききることが出来ないのが常だ。MySQLは最初からマスター・スレーブ型のレプリケーション機能が搭載されており、スレーブをたくさんぶら下げることによって参照の負荷をスレーブに割り振るというスケールアウトによってその問題に対処してきた。スレーブによるスケールアウトは、参照（＝PV）が多いWebサイトと非常に相性が良く、幾多のWebサイトにおいて実績を作ってきているし、まだまだ利用されている。 しかしながら、サイトのトラフィックが劇的に増加してくるようになると、レプリケーションによる負荷分散では追いつかなくなってきた。そこで人々がとった選択肢は、memcachedを利用することである。memcachedはインメモリ型の高速なKVSであり、参照・更新性能はMySQLより格段に高い。M
MySQL を使ったお手軽メッセージキュー実装 - ドワンゴ 研究開発ブログ
はじめに この記事では、MySQL を使って簡単なメッセージキューを手軽に実装する方法を解説します。 メッセージキューとは、メッセージを一時的に溜めておき、順次処理するための仕組みです。迅速なレスポンスが必要な Web アプリケーションにおいて、時間のかかる処理を非同期に行うために、バックグラウンドで順次処理していくような場合に利用できます。 簡単なメッセージキューと言っても、大規模な運用にも耐えられる程度の速度と堅牢性を持ちます。 また、ここで解説している方法で作られたメッセージキューは、弊社ウェブサービスであるニコニコ動画に最近追加されたtwitter連携機能でも利用しています。 メッセージキューを作るにあたって 今回実装するメッセージキューは メッセージの追加(push)を高速に行う事ができる メッセージの取得(pop)はある程度高速に行う事ができる 多くのクライアントから同時に p
MySQL 5.5登場
MySQL 5.5がリリースされた。「えっ？！この前5.4をリリースしたばっかりでしょ？！まだ5.4すら使ってないよ！！」と驚かれた方はご安心を。これは開発リリースモデルが変更されたためで、MySQL 5.4はこれでいったん開発終了して今後の開発はバージョン5.5をベースにして継続されることになる。バージョン5.4も5.5も「マイルストーンリリース」（以下MR）という位置づけであり、GA（正式リリース）版ではない点に注意して頂きたい。MR版の位置づけは次のようなもの。 品質的にはRC（リリース候補）版と同レベル（従ってほぼ安定している） 3〜6ヶ月ごとに新しいバージョンが出る 新しいMR版では機能が追加されることになるが、RC版と同レベルまで安定した機能だけが追加の対象になる MR版へ追加する予定の機能については別のブランチで開発が進められる 12〜18ヶ月ごとにMRのうち一つをGA版へと
実録、ほぼ無停止なMySQLのフェイルオーバ (動画もあるよ) - （ひ）メモ
レプリケーションしてるMySQLで、マスタやスレーブが障害停止した場合のリカバリプラン でも掲げたゴールである、「マスタが落ちてもぐーすか寝ていられるようにしたい」がほぼできたので、ほとんどサービスが停止することなく、フェイルオーバする様をスクリーンキャストに収めました。 埋め込みプレイヤーだと、小さくてわからないと思うので、リンク直接でみてください。 http://www.irori.org/pub/mysql-mm.mov 登場するホスト 登場するホストは2台、db901とdb902です。 最初は、db901が更新系クエリを受けるプライマリでdb900の浮動IPアドレスを持っています。 画面分割 画面は5分割しています。 左上 = 「select sysdate(),@@server_id」をdb900に対して(sleep 1しながら)延々と実行しまくりんぐ 右上 = ping -n
Kazuho@Cybozu Labs: Mycached: memcached protocol support for MySQL
It is a well-known fact that the bottlenecks of MySQL does not exist in its storage engines, but rather in the core, for example, its parser and execution planner. Last weekend I started to wonder how fast MySQL could be if those bottlenecks were skipped. Not being able to stop my curiousity, I started adding memcached proctol support to MySQL as a UDF. And that is Mycached. From what I unders
パーティショニングの使用例 - カーディナリティが低いカラムを使って検索する場合
MySQL 5.1で追加された機能にパーティショニングがある。これは適切に利用すれば非常に強力な機能であることは間違いないのだが、使いどころが難しい。なぜなら、 インデックスをつけるだけでカバー出来る場合が多い。 パーショニングを使わずに、単にテーブルを分けてしまえばいい。 テーブルが巨大にならないとあまり効果を実感できない。 使い方を間違えると性能が落ちてしまう。 などの問題があるからだろう。 そんなわけで、今日と明日でパーティショニングが役に立つシーンを2つ紹介しようと思う。今日は一つ目、インデックスをつけたいカラムのカーディナリティが低い場合だ。カーディナリティとは日本語に訳すと濃度とか訳されるが、要は値の種類（分散具合）のことである。例えば、YesかNoの2つの値しかとらないカラムは非常にカーディナリティが低く、インデックスをつけるととても効率が悪い。インデックスを使って目的の行を
How FriendFeed uses MySQL to store schema-less data - Bret Taylor's blog
Background We use MySQL for storing all of the data in FriendFeed. Our database has grown a lot as our user base has grown. We now store over 250 million entries and a bunch of other data, from comments and "likes" to friend lists. As our database has grown, we have tried to iteratively deal with the scaling issues that come with rapid growth. We did the typical things, like using read slaves and
1
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
【資料あり】ドワンゴ技術勉強会(2) - ドワンゴ 研究開発ブログ
RethinkDB: the open-source database for the realtime web
【速報】米Oracle、Sun Microsystemsを56億ドルで買収 | 経営 | マイコミジャーナル