GN⁺: Jepsen의 MySQL 8.0.34 평가
(jepsen.io)MySQL의 배경
- MySQL은 지난 28년 동안 가장 널리 배포된 SQL 데이터베이스 중 하나임.
- 주로 온라인 트랜잭션 처리(OLTP)에 사용되며, OLAP 및 큐잉 시스템의 일부로도 배포됨.
- 단일 서버 데이터베이스로 설계되었으나, 다양한 멀티 노드 복제 방식으로 확장됨.
- InnoDB 스토리지 엔진을 사용하는 MySQL에 대해 집중적으로 분석함.
ANSI SQL 격리 수준은 실제로 나쁨
- SQL 격리 수준의 미묘함을 논의하기 위해, 1977년에 제안된 트랜잭션 일관성의 네 가지 안전 수준과 1986년 ANSI가 발표한 SQL 표준의 역사적 배경 설명 필요.
- ANSI SQL은 격리 수준을 세 가지 가능한 현상(더티 리드, 논리피트 리드, 팬텀)을 통해 정의함.
- 1995년에 ANSI SQL 격리 수준의 결함이 지적되었고, 1999년에 Adya는 ANSI SQL의 격리 수준에 대한 형식적이고 구현 독립적인 정의를 개발함.
MySQL의 격리 수준
- MySQL 문서는 SQL:1992 표준에 의해 설명된 네 가지 트랜잭션 격리 수준을 제공한다고 함.
- 각 격리 수준에서 MySQL이 어떻게 이를 달성하는지에 대한 설명이 포함됨.
- MySQL의 Repeatable Read 격리 수준은 스냅샷 메커니즘을 통해 안전성을 보장함.
테스트 설계
- Jepsen 테스트 라이브러리를 사용하여 MySQL에 대한 테스트 스위트 설계.
- 단일 MySQL 노드 및 binlog 복제 클러스터, AWS RDS 클러스터 등 다양한 환경에서 테스트 수행.
- Elle의 list-append 검사기를 사용하여 트랜잭션 격리에 대한 주요 워크로드 수행.
결과
- MySQL의 Repeatable Read는 Adya의 PL-2.99 격리 수준이 금지하는 G2-item을 허용함.
- MySQL의 Repeatable Read는 또한 G-single(읽기 왜곡)을 허용함.
- MySQL의 Repeatable Read는 P4(잃어버린 업데이트) 현상을 허용함.
- MySQL의 Repeatable Read는 내부 일관성 오류를 보임.
- MySQL의 Repeatable Read는 Monotonic Atomic View를 위반함.
GN⁺의 의견
- MySQL의 Repeatable Read 격리 수준이 표준에 명시된 것과 다른 동작을 보이는 것은 개발자와 데이터베이스 관리자에게 중요한 정보임. 이는 데이터 일관성과 격리에 대한 기대를 충족시키지 못할 수 있음을 의미함.
- 테스트 결과는 데이터베이스 시스템의 격리 수준을 이해하고 적절한 격리 메커니즘을 선택하는 데 필수적인 정보를 제공함.
- 이러한 발견은 데이터베이스의 격리 수준과 관련된 표준이 실제 구현과 어떻게 다를 수 있는지에 대한 통찰력을 제공함. 이는 데이터베이스 기술의 복잡성과 격리 수준의 미묘한 차이를 이해하는 데 도움이 됨.
Hacker News 의견
-
"repeatable read"가 나쁜 아이디어라고 오랫동안 주장해왔음. 구현이 완벽하더라도, 데이터베이스에서 올바르게 작동하더라도 복잡한 쿼리를 다룰 때 이해하기 어려움.
- 두 가지 격리 수준이 의미가 있다고 생각함:
- read committed
- serializable
- serializable 설정은 예상치 못한 일이 없음. read committed 방향은 데이터에 일관된 뷰를 원하면 행을 읽기 시작하기 전에 잠가야 한다는 것이 명백함.
- read committed는 일반 멀티스레드 코드와 메모리 관리와 매우 유사하여 대부분의 엔지니어가 직관적으로 이해할 수 있음.
- serializable은 매우 엄격해서 예상치 못한 실수를 하기 어려움.
- 중간 수준은 아무도 속하지 않는 땅이며, Read Committed보다 덜 일관된 것은 더 이상 데이터베이스가 아님.
- 두 가지 격리 수준이 의미가 있다고 생각함:
-
FOSSDEM-2024에서 "Isolation Levels and MVCC in SQL Databases: A Technical Comparative Study" 발표 예정.
- Oracle, MySQL, SQL Server, PostgreSQL, YugabyteDB 비교 연구.
-
AWS RDS에 대한 글을 평가하고 있으나, AWS Aurora (MySQL)에 대한 초점이 있는지 궁금함. AWS는 MySQL이나 PostgreSQL인 척하는 데이터베이스 플랫폼을 구축함. Aurora MySQL이 RDS나 MariaDB와 같은 "기능"을 가지고 있는지 보는 것이 흥미로울 것임.
-
많은 일관성 아티팩트를 보여주는 기반 위에 구축된 "실제로 작동하는 시스템"들을 보여주는 훌륭한 예시라고 생각함.
-
RDS 복제가 5분 만에 작동을 멈추고 건강 검사 실패 알림이 없는 것이 다소 걱정됨.
-
append (a)가 주어진 테이블에서 실제 SQL 작업에 어떻게 매핑되는지, TEXT 필드가 리스트로 사용되는지 궁금함.
- MySQL의 repeatable read 모드에서 단일 SELECT가 단일 행을 선택하고 불가능한 결과를 반환한 문제가 있었음. 예를 들어,
SELECT min(value), max(value) FROM table WHERE id = 1;
에서 id가 기본 키인데 min과 max에 대해 서로 다른 값을 얻은 적이 있음.
- MySQL의 repeatable read 모드에서 단일 SELECT가 단일 행을 선택하고 불가능한 결과를 반환한 문제가 있었음. 예를 들어,
-
이론적인 격리 모드 정의와의 비교뿐만 아니라 PostgreSQL, MS SQL, Oracle과 같은 다른 인기 있는 관계형 데이터베이스와의 비교가 도움이 될 것임. 개발자들이 호환성을 확보하고자 할 때 염두에 둬야 할 사항임.
-
"SELECT ... FOR UPDATE"가 이러한 모든 문제에 대한 해답인 것 같음, 업데이트할 행을 잠그면 모든 것이 광고된 대로 작동함.
-
오늘 일을 좀 하려고 했는데, aphyr의 'call me maybe'와 jepsen.io는 인터넷에서 읽은 최고의 콘텐츠 중 일부임에 감사함.
-
MySQL 분석 내용 중 얼마나 많은 부분이 기본 스토리지 엔진으로 InnoDB를 사용하는 MariaDB에 대해 동일할지 궁금함.