SELECT ... FOR UPDATEとUPDATEでデッドロックが出る人へ - 41から始めました
はじめに 最近は主に花粉症に悩まされており、目が痒くてたまりません。 また、娘の生活がガラッと変わったせいで、毎日貧乏ヒマ無しです。 そんな中、たまたま早起きできたので奮起して久々に書いてみました。 問題が起きる環境 MySQL8.0.17以前 transaction_isolationがREAD-COMMITTED WHERE句の条件が一意ではない。（フルテーブルスキャンだと発生しやすくなる） キーの値がたすきがけになってる トランザクション開始＋SELECT ...FOR UPDATE→UPDATEのようにロックを取っている 先に実行されたトランザクションが、たすきがけになっているキー値の若い（っていうのかな？）方のロックを取る 何が起きるかと言うと、SELECT ...FOR UPDATEのWHERE句で抽出した行に対してロックを取ってるのに、 後から別セッションで実行されたSELE
ALTER TABLEを上手に使いこなそう。
テーブル定義を変更したい。インデックスが壊れてしまったので再作成したい。そんな場合はALTER TABLEを使う。ALTER TABLEはテーブル定義を変更するお馴染みのコマンドであるが、その挙動は意外と知られていない。（エキスパートとおぼしき方々からも度々質問を受ける。）そんなわけで、今日はALTER TABLEについて解説しようと思う。 まず結論から言うと、なんとMySQLのALTER TABLEはテーブルのデータを全てコピーし直すのである。なんて無駄なことを！？と思うかも知れないが、テーブル定義（スキーマ）の変更を動的に行うには、ストレージエンジンによるサポートが必要であり、動的なスキーマ変更をサポートしているストレージエンジンはまだ少ないのである。（動的スキーマ変更をサポートしているのはMySQL Clusterぐらいだ。しかも追加だけ。）デフォルトで利用出来るMyISAMはInn
MySQLでALTER TABLEでINDEXを作成するときの注意事項
こんにちは。Ops側の小宮です。 ある日朝来たら突然開発の方から相談いただいたので、後のために記録しておこうと思います。 相談内容： jenkinsで本番デプロイを行ったが、処理を途中停止した。 (CakeのDBマイグレーションスクリプトでデプロイした） KEYカラムにINDEXをはろうとしたがDBの応答がなくなり接続できなくなった。 結果としてテーブルが破損したためRDSの時刻指定してロールバックする機能を用いた。 (ALTERが終わってたかどうかとかはロールバックしたので不明) 同じレコード数の試験環境で同じ操作をしたら特に異常なくすんなり終わった。 もう一回同じことを本番でやりたいけどどうしましょう。 MySQLのバージョンは5.5.27。 私の個人的認識： 普通、ALTERする時はロックがかかるから、 事前に同じ構成と件数の試験環境でかかる時間を見積もってから その時間サービス止め
mysql binlogからDB復旧 - Qiita
mysqlbinlogでDB復旧した時の自分用メモ。繰り返す自分用のメモ。 依頼内容 依頼者「2014-02-14の20時台に作業間違えた。なかったコトにしてもらえませんか。」 俺「・・・」 やりたいこと 2014-02-14の20時台に投げられたクエリをすべてなかったことにしたい。 作業手順 バックアップしたデータベースをリストアする mysqlbinlogで、リストアした時間（2014-02-13 03:30）から該当時間（2014-02-14 20:00）まで、ログ吐き出して適用 該当時間後の正常なデータを吐き出し。具体的に2014-02-14 20:59:59以降のデータを吐き出して適用 データ確認 && 差し替え 前提条件 binlogが吐かれていること 定期バックアップが取られていること binlogを吐く方法 /etc/my.confにbinlogの設定をする。 基本レプリケ
今さらだけどMySQLのパーティショニング機能を試してみた - (ﾟ∀ﾟ)o彡 sasata299's blog
2013年03月21日18:11 MySQL 今さらだけどMySQLのパーティショニング機能を試してみた 最近は花粉が飛んでて辛い季節ですがみなさまいかがお過ごしでしょうか。でももうちょっと我慢すればサクラの季節ですよ〜。花見良いですよね、飲みたいだけですが。 ・・さて、今回はちょっと必要になったので、MySQLのパーティショニング機能なるものを試してみました。存在は知ってたけど、実際に試してみたことは無かった…。 パーティショニングとは？ これはどういうものかと言うと、MySQL5.1から使えるようになった機能で、ひとつのテーブルのデータを条件によって複数の領域（パーティション）に振り分けて管理することができる、というものです。例えば日別にデータを別々のパーティションに振り分けたり。 パーティショニングするとデータの削除が高速だったり（通常は削除ってものすっごい遅いけど、特定のパーティシ
YappoLogs: なぜ SQL_CALC_FOUND_ROWS や LIMIT OFFSET のページングが良く無いのか
なぜ SQL_CALC_FOUND_ROWS や LIMIT OFFSET のページングが良く無いのか ここ最近の大規模サービス関連したデータページング考です。 mysql 5.5.34 で試して記事書いてます。 bigdata テーブルは id BIGINT UNSIGNED NOT NULL AUTO_INCREMENT, PRIMARY KEY (id) なカラムがある前提です。もちろん InnoDB です。 2014年なんだからCOUNT(*)とかSQL_CALC_FOUND_ROWSとかLIMIT OFFSETのページングはやめようぜ - Togetterまとめが発端にみえるけど、わりと昔から話されてる事なんだけど、「nippondanji SQL_CALC_FOUND_ROWS」でググっても有用な情報ないし文書化されてないからしとく。 ページング処理で使われがちな機能です。 S
ソーシャルゲームのためのMySQL入門 | BLOG - DeNA Engineering
こんにちはこんにちは。最近お腹痛いばっかり言ってることで有名なiwanagaです。 DeNAは外部的にはプラットフォーム的な部分の方がフィーチャーされることが多いですが、実はソーシャルゲームの提供も行っています。怪盗ロワイヤルとか、どこかで聞いたことがあるのではないでしょうか。 僕はDeNAでソーシャルゲームが誕生した辺りからずっとサーバサイドを見てきましたが、そんな運用の中で自分が貯めてきた知見とかTIPSをご紹介したいと思います。 かれこれ10タイトル近くはレビューしたり運用したりしてるため結構言いたいことはいっぱいあるので、小出しにしつつ評判よければ次も書きます。 ソーシャルゲームのためのMySQL入門一覧 ソーシャルゲームのためのMySQL入門 - Technology of DeNA ソーシャルゲームのためのMySQL入門2 - Technology of DeNA 「MySQL
MySQLからPostgresqlに移行するためのPHPコード - Qiita
ブログを更新しました。元の記事はコチラ herokuはMySQLをサポートしてないので、MySQLを使っている既存アプリをPostgresqlに移行してみた。 まぁheroku使いたいがためにデータベースを変更するってのもどうかと思いますが、実験がてら。Wordpressとかをherokuで無料で動かしたいって人にはちょっとは役に立つかも。 ここに可能性のある方法がならんでいます。 Converting from other Databases to PostgreSQL いろんな方法がありますが、誰にでも取っつきやすい(？)、PHPでコードを書いてる人がいたので、使わせてもらいました。 バグレポート送ったんだけど、速攻で修正してくれた上に、律儀に名前まで載っけてくれてる…。なんか嬉しい。 PHP_my2pg PHP_my2pg PHP_my2pgのページにSource codeがあるので
MariaDB Galera Cluster による DB サーバの冗長化 - dogmap.jp
さくらインターネット研究所さんの「MariaDB Galera Clusterを試す」という記事を読んで居ても立ってもいられなくなり、さっそく AWS で構築してみました。 上記の記事によれば 簡単にまとめると次のようになります。 Galera Replicationが複数のRDBMをレプリケーションするwsrep APIを提供し、同期をとります 完全同期型であるため、すべてのノードがアクティブかつマスターとなります クラスターノードのどれに対してもリード／ライトが可能です ノードの追加／削除は自動で行えます クライアント接続は通常のMySQLとなんら変わりなく使えます via. MariaDB Galera Clusterを試す (1) « さくらインターネット研究所 おー！スレーブ/マスター形式のレプリケーションよりも、断然使いやすそうやんか！ ってわけで AWS の ELB 配下に複
DBエンジニアのための技術勉強会で発表したスライドを公開しました。
DBエンジニアのための技術勉強会というイベントで、リレーショナルモデルにおけるDB設計について話す機会を頂いた。リレーショナルモデルは非常に重要であるにも関わらず、現場ではないがしろにされてしまっている。その結果、アプリケーションのロジックを上手くクエリで表現できず、開発現場では非効率な開発が行われ、多くの人がデスマ的な状況に追い込まれている。そういう危機意識について、これまで何度か本ブログでも書いてきたし、WEB+DB Pressで連載している動機もその点にある。リレーショナルデータベースはやはりリレーショナルデータベースとして使うべきだ。そのための鍵となるのが、DB設計である。 今回はなんと約2時間の持ち時間を頂いた。リレーショナルモデルについてはこれまで何度か話す機会を頂いたが、2時間というのは最長記録である。それに合わせてスライドもボリュームたっぷりのものになった。過去のスライドと
1
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
http://kwatch.houkagoteatime.net/blog/2014/12/20/postgresql-features/
データベース設計徹底指南