地理分散DBについてDatabase Lounge Tokyo #4 https://database-lounge-tokyo.connpass.com/event/54855/ で話した資料。 動画はこっち https://www.youtube.com/watch?time_continue=1&v=VTEAJHJHIpY Read less
トランザクションをSerializableにする4つの方法
2015年12月18日に行われたビッグデータ基盤勉強会で発表する際に使った資料です。Read less
(解決済み) DBIx::TransactionManager + File::RotateLogsで意図せずトランザクションが終了してしまう件 - Hateburo: kazeburo hatenablog
DBIx::TransactionManager 1.13で子プロセスでrollbackを実行しないような変更が入っています。 https://metacpan.org/release/NEKOKAK/DBIx-TransactionManager-1.13 TengやDBIx::Sunnyなどでトランザクションを使用し、File::RotateLogsでログを書き出している場合はバージョンアップをお勧めします。 経緯など 某サービスにおいて、DBIx::TransactionManagerを使ってトランザクションを実行している箇所で9時にトランザクションが意図せず終了するという問題がありました。 コードにするとこんな感じ my $rotatelogs = File::RotateLogs->new( logfile => '/path/to/access_log.%Y%m%d%H%M',
MySQLでトランザクションの4つの分離レベルを試す - FAT47の底辺インフラ議事録
トランザクションとは 1つの作業単位として扱われるSQLクエリの集まりです。 複数のUPDATEやINSERTをひとつの集まりとして、 それらのクエリがすべて適用できた場合のみデータベースに反映します。 ひとつでも適用に失敗したクエリがあった場合は、そのまとまりすべてのクエリの結果は反映しません。 ACID特性 トランザクション処理に求められる4つの特性です。 原子性 (Atomicity) トランザクションに含まれる手順が「すべて実行されるか」「すべてされないか」のどちらかになる性質。 一貫性 (Consistency) どんな状況でもトランザクション前後でデータの整合性が矛盾なく保たれる性質。 分離性 (Isolation) トランザクション実行中は、処理途中のデータは外部から隠蔽されて他の処理に影響を与えない性質。 永続性 (Durability) トランザクションが完了したら、シス
もしもデータベースサーバがクラッシュしたら
人の作ったものは完璧ではない。完璧でないものはクラッシュする。故にデータベースはクラッシュする。サーバハードウェアの故障、OSのクラッシュ、データベースそのもののバグなど原因は様々であるが、永遠に停止することなく動き続けるRDBMSというものは存在しない。もちろん数年間無停止で問題が出ない場合もあるが、クラッシュするときはするので対策が必要である。もしもの時に備えて抜かりないのがスマートなオトコのスタイルである。データベースのご利用は計画的に。 と思ったそこのアナタ！！人生そんなに楽ではありません。 もちろんRDBMSはトランザクションのDurabilityを保証しているので99%の場合はそれでOKだけど、それはCOMMITが成功した場合の話。COMMITは大抵の場合高速な処理であるが、それでも処理にかかる時間はゼロではない。アプリケーションがデータベースサーバにCOMMITを送信してから
DBIx::TransactionManager の目的と、その使用法について - tokuhirom's blog
おはようございます。 DBI では当たり前のように $dbh->do('BEGIN') と $dbh->do('COMMIT') をつかえばトランザクションがつかえるわけですが、なぜ DBIx::TransactionManager のようなものが必要になったのでしょうか。 それは勿論、DBI で直接 transaction をとりあつかうと問題が発生するケースが存在するからです。 トランザクションと RAII一番おおきいのは、トランザクションが中途半端な状態になってしまうことを阻止することです。たとえば、以下のようなケースでは、おかしなことになってしまいます。 my $dbh = DBI->connect(...); for (@stuff) { eval { $dbh->do("BEGIN"); $dbh->do(q{INSERT INTO t1 (v) VALUES (?)}, $_
InnoDBのネクストキーロックによるデッドロックの例 - iakioの日記
あまりMySQLのことは自信ないですが。 一見問題なさそうに見える操作でデッドロックしてしまうケースがあったので動画にしてみました。 SELECTしてみて「有ればUPDEATE、無ければINSERT」や、あるいは「有れば何もせず、無ければINSERT」を行ないたい場合に、SELECT FOR UPDATEして無ければINSERTとしてしまうと、動画の最初の例のようにデッドロックしちゃいます。存在しない行に対してSELECT FOR UPDATEするとちょっと広めに行ロックがかかってしまう感じでしょうか。 「有ればUPDATE、無ければINSERT」であれば、INSERT ... ON DUPLICATE KEY UPDATEを使うのが良さそう。「有れば何もせず、無ければINSERT」なら、いきなりINSERTしてみて一意制約違反ではじいてもらうのがいいのかな。 動画の2つめの例は、i =
MySQL トランザクション - とみぞーノート
トランザクションを使うと複数のクエリをまとめて１つの処理として扱うことができる。処理の途中でエラーになって処理を取り消したいような場合はROLLBACKをすることで変更内容を元に戻すことができる。 トランザクションはデフォルトのMyISAM形式のテーブルでは使用できない。トランザクションが使用できるテーブルにはInnoDB,BDBなどがある。以下ではInnoDBを使って説明する。 1.InnoDBテーブルの作成 新規に作るテーブルをInnoDBにするには、以下のようにする。 mysql> CREATE TABLE friends (id SERIAL, name VARCHAR(30) NOT NULL, address VARCHAR(100), birthday DATETIME) TYPE=InnoDB; 既存のテーブルをInnoDBに変更する場合は以下のとおり。 mysql> AL
SELECT FOR UPDATEする上での注意点 - blog.nekokak.org
MySQLで行ロックかけてトランザクションを効かせたい場合、SELECT FOR UPDATEを使うわけですが、 以下のようなクエリを発行しちゃうと行ロックではなくテーブルロック風味に扱われるので注意。 mysql> begin; Query OK, 0 rows affected (0.00 sec) mysql> select * from user order by id DESC limit 1 for update; +----+---------+ | id | name | +----+---------+ | 4 | xaicron | +----+---------+ 1 row in set (0.00 sec)このクエリを実行中に別のセッションから同じことを実行するとロック待ち状態になり 最悪デッドロックで死亡します。 ERROR 1205 (HY000): Lock
MySQL InnoDBのネクストキーロック おさらい - SH2の日記
MySQLのInnoDBストレージエンジンは行ロックをサポートしています。しかしOracleと同じ感覚でアプリケーションを作っていると、思わぬところでデッドロックに出くわすことがあります。これはInnoDBのロック範囲がOracleよりも微妙に広いためです。 実際の例で確認してみましょう。 mysql> select * from t; +----+------+ | c1 | c2 | +----+------+ | 10 | a | | 15 | a | | 20 | a | | 25 | a | | 30 | a | | 35 | a | | 40 | a | | 45 | a | | 50 | a | +----+------+c1列は主キーになっています。1つめのセッションで以下のSQLを実行します。 mysql> set tx_isolation = 'repeatable-r
DBIx::TransactionManager
というのを書きました。 https://github.com/nekokak/p5-DBIx-TransactionManager まぁ、DBIx::Skinnyで使っているトランザクションの仕組みを別モジュールに切り出した感じです。 use DBI; use DBIx::TransactionManager; my $dbh = DBI->connect('dbi:SQLite:'); my $tm = DBIx::TransactionManager->new($dbh); { my $txn = $tm->txn_scope; $dbh->do("insert into foo (id, var) values (1,'baz')"); { my $txn2 = $tm->txn_scope; $dbh->do("insert into foo (id, var) values (
Song of Cloud: 分散トランザクション処理の最適化
前回の「送金のトランザクション処理パターン」では、EntityGroupにまたがるトランザクション処理について簡単に紹介しました。 様々なコメントいただきまして(ありがとうございます)、どうやら「Distributed Transactions on App Engine - Nick's Blog」のやり方が非常に優れているようですので、今回は「送金のトランザクション処理パターン」で紹介した手法に最適化を施して、Nickさんのやり方に近付けてみようと思います。 今回紹介する最適化は、前回のような「狭い範囲のACIDトランザクション」と「べき等性による処理の伝搬」を組み合わせた分散トランザクション一般に適用できそうな手法です。そんなに大層なことはしていませんが、例によってまだ構想段階ですので、また至らない点があればご指摘いただければ幸いです。 おさらい 送金のトランザクション処理パターンで
Song of Cloud: 送金のトランザクション処理パターン
App Engineで現実的な送金処理について考え中です。 ドラフト版なので、怪しい点があればご指摘いただければ幸いです。 コメントで情報いただきました。 Distributed Transactions on App Engineで紹介されてる方法と基本的に同じなので、おそらく問題なく動きそうです。ありがとうございました。 今回はこんな図を使います。 この図の読み方は、矢印の方向にユースケースの一連の処理(またはリクエストの処理)が流れていて、右に行くほど時間が経過しています。そして、矢印がくし刺しにしている四角形は、そのユースケース中で操作するエンティティを表しています。 また、左右の位置が同じ矢印は、基本的には同じ時刻に発生したイベントを表しています。上記の図では、A, B, Cがそれぞれの口座エンティティを同時に操作している感じです。 並行性制御(おさらい) 最初の図のように、それ
1
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
分割と整合性と戦う
ECナビ エンジニアブログ : MySQL InnoDBでのネクストキーロックの落とし穴