yagikota
commented
1 month ago トランザクション
- DBアクセスをするアプリケーションの実装を楽にしてくれる（データベース側にある程度のエラー処理・並行性の問題の処理を任せられる）
7.1 トランザクションという捉え所のない概念
トランザクションの特徴=ACID特性
7.1.1 ACIDの意味
ACID
- A(Atomicity)
- C(Consistency)
- I(Isolation)
- D(Durability)
→DBごとに定義が異なるので、ほぼマーケティング用語と化している。
Atomicity
- トランザクションが「全て成功する」か「全て失敗する」かのいずれかであることを保証（All or Nothing）
- Write Ahead Log(WAL)が一役買っている。
- https://planet.mysql.com/entry/?id=17817
事前にロギングを行う仕組みは全てWALと呼ばれる。MySQLで言えばInnoDBにおいてRedoログとして利用されるログもWALであるし、MySQL Clusterのディスクテーブル利用時のUndoログだってWALの一種である。現在開発中のストレージエンジンであるFalconやMaria（MyISAMにクラッシュリカバリやトランザクション機能をつけたもの）もWALを搭載する予定である。もちろんOracleやPostgreSQLなど他のRDBMSでもWALが搭載されている。 用途、つまりRedoなのかUndoなのかということに因らず、実データに更新を行う前にログに書き込む方式をWALというわけである。 WALがあれば、チェックポイント処理（どこまでデータファイルに書き込んだのかということを記録する処理）と組み合わせることで、万が一の障害時に役に立つ。
- https://planet.mysql.com/entry/?id=17817
Consistency
- トランザクションの前後でデータの整合性が取れている（データがinsertされている・外部キー貼られているなどなおd）。
- これだけ、アプリケーション側の責務。アプリケーションの実装次第で崩れることもある。
Isolation
- トランザクションAはトランザクションBに影響を与えない。逆もまた然り。
Durability
- トランザクション成功後のデータは永続化される。
7.1.2単一オブジェクト操作と複数オブジェクト操作
7.1.2単一オブジェクト操作
単一オブジェクトレベルでのAtomicityとIsolationは必要
- Atomicity: クラッシュリカバリログ（MySQLで言うところの、redo/undolog）
- https://tanishiking24.hatenablog.com/entry/innodb-durability
- https://www.percona.com/blog/understanding-the-differences-between-innodb-undo-log-and-redo-log/
- redo: コミット後のデータ（障害発生時に、ログを元に復元）
- undo: コミット前のデータ（ロールバックの際に使う）
- Isolation: ロックを使う（オブジェクトにアクセスできるスレッドを1つにする）
7.1.3 エラーと中断の処理
中断されたトランザクションのエラー処理は完璧ではない
- トランザクション成功後に、DB→バックエンドサーバの通信がうまくいかないな場合 - バックエンドはトランザクション失敗と見なす - リトライされる→結果、トランザクションが2回実行される。 - これを防ぐには、バックエンドで重複排除の仕組みがいる（トランザクションIDとか？知らんけど） - https://www.geeksforgeeks.org/avoiding-double-payments-in-a-distributed-payments-system/
- 過負荷によるエラーの場合
- どうしようもない。リトライしても意味ない。
- リトライ制御（回数とかexponential backoffとか）
- 恒久的なエラー（制約違反）の場合 - リトライすべきエラーではないので、リトライしない
- トランザクションがDB外に副作用（メール送信など）持っている場合 - リトライのたびにメール送信したくない - 2相commit(2PC)
- リトライ中にプロセス落ちた場合
- リトライできない。データの書き込み失敗。→どうするの？
What do you do?
7章読む。
TODO