サービス稼働中にMySQLでALTER TABLEしたら Waiting for table metadata lock が溢れて死んだ - Qiita
サービス稼働中にMySQLでALTER TABLEしたら Waiting for table metadata lock が溢れて死んだMySQL ALTER TABLEすると以下のような挙動でカラム変更されるようです 他のセッションからのREADを許可し、WRITEをブロック 新しいtable定義の一時テーブルを作成 一時tableに元tableのデータをすべてコピー 一時tableを元table名にリネームして元tableを削除 ブロックされていたWRITE系クエリを反映 全コピしてるので、ALTER TABLEを実行する時にどでかいtableのサイズの場合は長い時間WRITEがブロックされるので注意が必要です。 ALTER TABLEを実行した環境 上記を踏まえた上で、以下のようなテーブルにALTER TABLEを実行してカラム追加する事にした レコード数はちょっとしかない READ
MySQLインデックスの基礎 その2 : 2つのクエリの違いとオプティマイザの判断 | Yakst
MySQLのインデックスを効果的に使う方法の第2弾。よく似た2つのクエリなのに、実際にはインデックスの使い方がそれぞれ異なることを通じて、オプティマイザがどのようにクエリの実行計画を立案するのか、そしてその結果どうインデックスが使われるのかを解説する。 前の記事では、ひとつのテーブルに対する様々なクエリを対象にして、インデックスのデザイン方法について議論しました。この記事ではより実世界に即した問題解決の例として、よく似ているにも関わらず、ひとつは適したインデックスを使い、もうひとつはフルテーブルスキャンをしてしまうという、2つのクエリを取り上げます。動作の違いはバグなのでしょうか？それとも想定された動きなのでしょうか？続きを読んでみてください！ 対象のクエリ2つ # Q1 mysql> explain select col1, col2 from t where ts >= '2015-0
MySQLのレプリケーションでありがちな10の問題 | Yakst
レプリケーションの問題でよくある10パターン。 1) セッションのみで有効なバイナリログ sql_log_bin = 0を設定すると、そのセッション内でバイナリログを無効にできる。つまり、マスタのセッション内で実行したDMLやDDLは、スレーブにはレプリケーションされない。 マスタでバイナリログをオフにする。 mysql> set sql_log_bin = 0 ; Query OK, 0 rows affected (0.00 sec) reptestデータベースにテーブルを作成してみる(マスタ上で実行)。 mysql> create table reptest(ID int) ; Query OK, 0 rows affected (0.01 sec) mysql> show tables ; +-------------------+ | Tables_in_reptest | +-
長年の議論に終止符 -- MySQL/MariaDBのバックアップとロックの関係＋クラッシュセーフについて - interdb’s diary
よい機会なのでまとめておく。対象はMySQL5.6以下とMariaDB10.0以下。 (2014.12.3追記：以下の書籍にも記述した。) 要旨 MySQL/MariaDBのバックアップについて、相変わらず「InnoDBさえ使っていれば、FLUSH TABLES WITH READ LOCKは不要。よってバックアップ中に更新不可になることはない！」との主張が繰り返されているが、少なくとも5.6/10.0まではそんなことはない。 オンラインバックアップに関するロックの正確な記述 より正確に言えば「全データベース領域をバックアップする場合には、FLUSH TABLES WITH READ LOCKは必須。特定のInnoDBだけのデータベースやテーブルをバックアップする際は、この限りではない」。 なのだが、全領域のバックアップをしたい人に対してロック不要説を吹き込む人が未だにいる。 ロックの必要
mysql で duplicate な error を防ぐために insert ignore はしないほうがいいのかなぁと思った - soh335 memo
insert した際に unique key とか primary key で duplicate な場合に error が起きるのを防ぐために（無視して良いとうい仕様の場合に） insert ignore ... すると良いみたいな記事があったりするけれども、実際どうなのかなぁと思って調べた。 If you use the IGNORE keyword, errors that occur while executing the INSERT statement are ignored. For example, without IGNORE, a row that duplicates an existing UNIQUE index or PRIMARY KEY value in the table causes a duplicate-key error and the state
Mroongaを使って全文検索Webサービスを作ったときにはまったこと(第1回) - CreateField Blog
前回のエントリに書いたように、１年半ほどをかけて、独学で特許の全文検索サービスを開発しました。 PatentField | 無料特許検索 最初は、MySQLを使ったこともない状態だったこともあり、かなり紆余曲折しました。Groonga開発チームの懇切な対応もあって、専用サーバ1台で最大で1千万レコード超、400GiB以上のサイズのテキストデータを高速に検索できるようになりました。 今後、何回かにわけて、Mroonga(Groonga)を使って全文検索Webサービスを作ったときにはまったこと、学んだことを全て書き出したいと思います。 全文検索エンジンMroongaとは？ Mroongaは全文検索エンジンであるGroongaをベースとしたMySQL用のストレージエンジンです。Mroongaは、MySQLが使える人であれば、簡単に高速な全文検索機能が使えます。MariaDB10.0系にもバンドル
MySQLをインストールしたら、必ず確認すべき10の設定 | Yakst
MySQL Performance Blogの翻訳。インストール後に必ず設定を確認しなければならない設定パラメータ10つを挙げ、その意味を解説する。MySQLの設定変更時の、一般的な注意点も合わせて。 January 28, 2014 By Stephane Combaudon 我々がパフォーマンス監査の仕事をする時には、MySQLの設定のレビューと改善提案を求められる。大抵の場合、たくさんのオプションがある中でほんのいくつかの設定しか変更するように提案しないことに、多くの顧客は驚く。この記事のゴールは、もっとも重要な設定をいくつか挙げてみることにある。 既にこういった提案は過去にもしているが数年前のもので、それ以来MySQLの世界ではたくさんの変化があったのだ。 話の前に 熟練した人でも、重大なトラブルを引き起こすミスをしでかすことがある。従って、ここに挙げたものを盲目的に適用する前に、
Facebook: MySQL Pool Scannerでの徹底した自動化 - ワザノバ | wazanova.jp
https://www.facebook.com/notes/facebook-engineering/under-the-hood-mysql-pool-scanner-mps/10151750529723920 Facebookがエンジニアブログで、MySQLの運用を自動化している事例を紹介しています。このレベルまでくると、意思をもった大規模なロボット群みたいで、すごいですね。前半はマスタ/スレーブの基本的な自動化の話ですが、後半ではオペレーションの自動化ロジックをどのように自動化して増やすかという手法まで言及してます。 FacebookのMySQL DBクラスタは、２つの大陸にまたがる複数のデータセンタにある数千台のサーバで構成されている。通常、DBアドミンが担当するルーティーンワークは、MySQL Pool Scanner (MPS) で自動化されている。 1) DBノードを詳しく
Cache-Oblivious データ構造入門 @DSIRNLP#5
9. なぜ B-Tree の方が良いか？ 大事な前提（若干雑） 1. ディスクの読み込み時間 >> 計算時間 2. ディスクである箇所を読み込むと周辺も含 めてそこそこ大きく読まれる 前提より • ディスクを読み込む回数だけを考える – 普段の議論：「O(ほげ) 時間」 – 今回の議論：「ディスクI/O 𝑂(ほげ) 回」 • 一度に読み込まれるサイズを 𝐵 とおく Cache-Oblivious データ構造入門 (@iwiwi) 10 10. データの探索にかかる I/O 回数 二分探索木 • 𝑂 log 𝑛 回 一回の I/O で 2 分岐 B-Tree • 𝑂 log 𝐵 𝑛 回 一回の I/O で Θ(𝐵) 分岐！ ↑ノードのサイズをブロックサイズ 𝐵に合わせる B-Tree のほうが log 𝐵 倍ぐらい早い これは平気で 10 倍とかになるので大違い！ Cac
気軽なMySQLバージョンアップ - まめ畑
このエントリーはMySQL Casual Advent Calendar 2013 10日目の記事です。カジュアル！ このへんでそろっとカジュアル詐欺と言われるのを防止するために、カジュアルな話を書いてみました。 MySQL5.6も正式リリースされてもうすぐ1年経ち、5.7の足音も聞こえてきている今日このごろですが皆様のMySQLのご機嫌はいかがでしょうか。 新機能や性能向上/bugfixに対応するためにMySQLのバージョンアップを行う機会や性能や不具合調査を行うことも多いかと思います。データベースのバージョンアップは特にメジャーバージョンアップの場合、パラメータのデフォルト値などの変更や仕様変更の影響(オプティマイザの変更)をアプリケーションが受けないか、性能の変化などを検証すると思います。 検証 実際に検証を行う場合、本番環境で流れているクエリをバージョンアップ先のDBに実際に流して
データベースアプリケーション開発を炎上させる負のスパイラル
毎度おなじみ、はてブのホットエントリに「SIをダメにする負のスパイラル」というタイトルのまとめが掲載された。きしだ氏とはかなり視点は違うものの、開発現場の問題点については少し思うところがあるので意見を書いてみようと思う。と言っても、以下の話の内容はデータベースアプリケーションに限定した話であり、またSIerだけに限った話ではないのでその点はご容赦頂きたい。もちろんSIer各位の案件はデータベースは必須なので、本エントリで触れる問題点には該当するだろう。 Q.なぜ炎上するのか？ A.正しいデータベース設計ができていないから結論から言おう。データベースアプリケーションの開発が炎上するのは正しいデータベース設計ができていないからだ。ここでいう「正しい」とは、論理的に証明できる正しさという意味ではない。「本来こうするべき」といった意味で捉えて欲しい。 「炎上」というのは、例えばテストが通らない、バ
re:InventでのParseのDevOps話がとても良かったのでまとめておく - すずけんメモ
今、AWS re:Inventにきていて、今日parse.comのセッションを聴く時間があったので簡単にまとめておく。とてもざっくり書くと、要点は parseは1-3段階のDevOpsの進化を経てきた 最初はRoRでデプロイするにも全てのサーバでcapistorano走らせなければ行けなかった。結果として90分から150分くらいデプロイに時間が掛かる。 現在はAutoScalingGroupとChefがシームレスに連携していて、5-10分でシステムをフルビルドできるようになった。 ということ。 セッションの概要は以下のとおり。 MBL307 - How Parse Built a Mobile Backend as a Service on AWS Parse is a BaaS for mobile developers that is built entirely on AWS. Wi
Homebrew で作るモダンなフロントエンド開発環境 (Git + zsh + apache + MySQL + Ruby) | DevelopersIO
一つ前のエントリーで新規 Mac にインストールしておきたいアプリのまとめを紹介しました。フロントエンド開発をしていくにあたり、アプリをインストールするだけでなく必要に応じて様々な動作環境を構築する必要がある訳ですが、これもまた何かと手間のかかる面倒な作業だったりします。都度ググっては参考になりそうな情報に倣って試みるも、その情報が古かったり構築するための前提条件が微妙に異なったりと、そっくりそのまま参考にすることが難しいことがほとんどだったりします。 現状、僕は Mac の開発環境の構築に Homebrew というパッケージ管理ツールを利用しています。海外と比較して日本での利用者が多いことから日本語の情報が多く出回っていることが主な理由です。 Homebrew（ホームブルー）は、Mac OS Xオペレーティングシステム上でソフトウェアの導入を単純化するパッケージ管理システムのひとつである
What to tune in MySQL 5.6 after installation – Master MySQL
Morgan Tocker MySQL Product Manager I work on the MySQL team at Oracle. My current position has me responsible for MySQL Server product management. I was previously community manager. As the result of a number of improvements to default values, MySQL 5.6 requires far less configuration than previous versions of MySQL. Having said that, I wanted to write about the settings that you may need to chan
MySQL 5.6のインストール後にチューニングすべき項目 | Yakst
MySQLコミュニティマネージャのMorgan Tocker氏による、MySQL 5.6をインストールした後にデフォルト値から変更した方がよいパラメータの解説。 数々のデフォルト値の改善によって、過去のバージョンと比べてMySQL 5.6では設定しなくてはならない値がかなり減った。とは言え、変更すべきものについてここで書いておきたい。 InnoDBの設定 innodb_buffer_pool_size - デフォルトは128M。これは、メモリにロードされるデータとインデックスのためにInnoDBがどのくらいメモリを使うかを指定するものなので、設定すべき重要な値だ。MySQLの専用サーバなら、搭載されているメモリの50%から80%が推奨される設定値だ。例えば、64GBのRAMを搭載しているサーバなら、バッファプールは50GB程度にすべきだろう。 innodb_log_file_size -
O/R Mapper におけるページャーの実装について - tokuhirom's blog
欠点$rs->pager(); のように、クエリをうっているっぽくないのに裏でうってるので、重い処理なのにおもそうにみえなくてさがすのが面倒。お気軽につかえすぎて危険。 HAVING などをつかうクエリの場合、そもそもただしい値がとれてないのに、なんとなくうごいてしまう。まちがった値をかえす API を標準でつけるのはいかがなものか。 得に HAVING などの処理がうまくできないのは自明なので、こういう実装は僕は好きではないです。 → Teng にはついてない。
ウェブオペレーションエンジニアはリリース前のソースコードのココを見ているッ！ - blog.nomadscafe.jp
「ウェブオペレーションエンジニアはリリース前のソースコードのココを見る！」みたいな記事があればいいね — masahiro nagano (@kazeburo) November 20, 2012 ちょいと前にツイートしたこの件のまとめ。新規サービスのリリースや既存サービスに新しい機能が追加される際に、しばしばそのソースコードを確認しているのですが、僕がどんなところを見ているのかまとめてみました。 そのサービスへの導線とランディングページの確認 まず、そのサービスへの導線やランディングページを確認します。そしてその一番アクセスがあろうページ、一つか二つに確認対象を絞ります — masahiro nagano (@kazeburo) November 20, 2012 どんな素敵なサービスも、機能も適切な誘導がなければ使われる事はありません。また誘導次第では大量のアクセスが一度にサーバに対し
はてなグループの終了日を2020年1月31日(金)に決定しました - はてなの告知
はてなグループの終了日を2020年1月31日(金)に決定しました 以下のエントリの通り、今年末を目処にはてなグループを終了予定である旨をお知らせしておりました。 2019年末を目処に、はてなグループの提供を終了する予定です - はてなグループ日記 このたび、正式に終了日を決定いたしましたので、以下の通りご確認ください。 終了日: 2020年1月31日(金) エクスポート希望申請期限:2020年1月31日(金) 終了日以降は、はてなグループの閲覧および投稿は行えません。日記のエクスポートが必要な方は以下の記事にしたがって手続きをしてください。 はてなグループに投稿された日記データのエクスポートについて - はてなグループ日記 ご利用のみなさまにはご迷惑をおかけいたしますが、どうぞよろしくお願いいたします。 2020-06-25 追記 はてなグループ日記のエクスポートデータは2020年2月28
1
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
MySQL 容量確保のためのデータ削除方式 | Ore no homepage
IDEA * IDEA