タグ

transactionに関するmasasuzのブックマーク (7)

  • 挿入と参照ロックに疲れ果てた俺たちは - ichirin2501's diary

    なかったらINSERTしたいし、あるならロック取りたいやん? from ichirin2501 www.slideshare.net 出来事 @ichirin2501 とりあえず何も考えずこの前のロックの話をSlideshareにあげてくれ!!— 柴崎優季 (@shiba_yu36) 2015, 8月 22 はじめに これは先日の社内勉強会で発表したもので、MySQLで特定の問題を解決したいときのノウハウ話です。特定の問題とは、アプリを書いてると「データがなかったINSERTしたい、あるなら排他ロックしつつ取得したい」という要望があったりします。例えば、あるユーザーアクションで初期値もパラメーターで渡されるケースで、データがないならそのままINSERT、既にデータがあるなら取得して状態に依存して更新処理を行いたい場合などです。見かけのロジックは単純に見えますが、MySQLでこれを実現しよう

    挿入と参照ロックに疲れ果てた俺たちは - ichirin2501's diary
  • MySQLのロックについて

    MySQLのロックについて JPOUG> SET EVENTS 20140907 2014/09/07 平塚 貞夫 1 Revision 2 自己紹介 • DBエンジニアをやっています。専門はOracle DatabaseMySQL。 • オープンソースソフトウェアの導入支援をしています。 • 仕事の割合はOracleMySQL:PostgreSQL=1:2:7くらいです。 • Twitter:@sh2nd • はてな:sh2 • • 写真は実家で飼っているミニチュアダックスのオス、アトムです。 2 日のお題 3 想定外のデッドロック • MySQLのInnoDBストレージエンジンに対して、2つのトランザクション を以下の順番で実行するとデッドロックが発生します。 • このデッドロックの発生メカニズムを理解するために、InnoDBのロック アーキテクチャについて確認していきます。 4

  • MySQLのロックについて - SH2の日記

    JPOUG> SET EVENTS 20140907 | Japan Oracle User Group (JPOUG)に参加して発表をしてきました。IIJさまのセミナルームは窓からの眺めがすばらしいですね。JPOUGの運営メンバのみなさま、会場を提供してくださったIIJのみなさま、当日お越しいただいたみなさま、どうもありがとうございました。 私のセッションでは「MySQLのロックについて」と題してネクストキーロックなどの説明をしました。プレゼンテーション資料と、調査のために作成したツールを公開します。 プレゼンテーション資料 (PDF) Lock Inspector 1.0 プレゼンテーション資料からリンクしているウェブサイトの一覧です。 MySQL Lists: mysql: Re: InnoDB's inner workings + checkpoints 過去記事の訂正 @kami

    MySQLのロックについて - SH2の日記
  • mysqldump --dump-slave について - Studio3104::BLOG.new

    MySQL5.5から追加になった、--dump-slaveオプションをつけてmysqldumpを実行すると、バックアップの最中Slave_SQL_Threadが停止してしまう。 これでは、--single-transactionオプションのメリットが大きく削がれてしまうことになる。 mysqluftに参加させていただいたときに、@nippondanjiさんにこのことについて相談したところ、バグ登録され、そのついでにパッチが書かれるという超俺得な出来事があった。 「FLUSH TABLES WITH READ LOCKしてないじゃん」という内容だが、Slave_SQL_Threadが停止してしまう問題についても一緒に対応してくださった模様。 @nippondanjiさんありがとうございました。 MySQL Bugs: #65035: FLUSH TABLES is missing on my

    mysqldump --dump-slave について - Studio3104::BLOG.new
  • もしもデータベースサーバがクラッシュしたら

    人の作ったものは完璧ではない。完璧でないものはクラッシュする。故にデータベースはクラッシュする。サーバハードウェアの故障、OSのクラッシュ、データベースそのもののバグなど原因は様々であるが、永遠に停止することなく動き続けるRDBMSというものは存在しない。もちろん数年間無停止で問題が出ない場合もあるが、クラッシュするときはするので対策が必要である。もしもの時に備えて抜かりないのがスマートなオトコのスタイルである。データベースのご利用は計画的に。 と思ったそこのアナタ!!人生そんなに楽ではありません。 もちろんRDBMSはトランザクションのDurabilityを保証しているので99%の場合はそれでOKだけど、それはCOMMITが成功した場合の話。COMMITは大抵の場合高速な処理であるが、それでも処理にかかる時間はゼロではない。アプリケーションがデータベースサーバにCOMMITを送信してから

    もしもデータベースサーバがクラッシュしたら
  • A Critique of ANSI SQL Isolation Levels再読 - 急がば回れ、選ぶなら近道

    元論文はこちら https://www.microsoft.com/en-us/research/wp-content/uploads/2016/02/tr-95-51.pdf 詳細なスライドはこちらになります。今年の夏のクラウド温泉で発表した内容です。一回見直して、若干手直しをしています。 http://www.slideshare.net/okachimachi/a-critique-of-ansi-sql-isolation-levels 論文の解説は割と意味があると思ったので、スライド自体は割とまじめに作りました。クラウド温泉では口八丁手八丁でいろいろ話しましたが、その辺はオミットしています。この論文の解説は探せば、いろいろ巷にはあるのですが、かなり苦闘して矢尽き刀折れ状態が散見されるので、多少なりとも状況が補修できればと思っておいておきます。(尚、当然ですが、内容が正確かどうかは

    A Critique of ANSI SQL Isolation Levels再読 - 急がば回れ、選ぶなら近道
  • A critique of ansi sql isolation levels 解説公開用

    A Critique of ANSI SQL Isolation Levelsの解説。Read less

    A critique of ansi sql isolation levels 解説公開用
  • 1