innodb_flush_log_at_trx_commit = 2를 사용하는 것이 안전합니까?

나는 innodb_flush_log_at_trx_commit = 2매우 빠른 쓰기 속도를 얻었습니다. 그러나 프로덕션 웹 사이트에서 안전하게 사용할 수 있습니까?

최대 1 초 분량의 트랜잭션을 잃을 수 있습니다. 기본값은 1이며 InnoDB ACID 준수를 유지하는 데 도움이됩니다 .

innodb_flush_log_at_trx_commit 의 MySQL 문서에 따르면

innodb_flush_log_at_trx_commit의 값이 0이면 로그 버퍼가 초당 한 번 로그 파일에 기록되고 디스크로 플러시 조작이 로그 파일에서 수행되지만 트랜잭션 커미트에서는 아무것도 수행되지 않습니다. 값이 1 (기본값)이면 각 트랜잭션 커밋에서 로그 버퍼가 로그 파일에 기록되고 디스크로 플러시 작업이 로그 파일에서 수행됩니다. 값이 2 인 경우, 커밋 할 때마다 로그 버퍼가 파일에 기록되지만 디스크로 플러시 작업은 수행되지 않습니다. 그러나 값이 2 인 경우에도 로그 파일의 플러시가 초당 1 회 발생합니다. 프로세스 스케쥴링 문제로 인해 초당 플러시가 100 % 보장되는 것은 아닙니다.

완전한 ACID 준수를 위해서는 기본값 1이 필요합니다. 1과 다른 값을 설정하여 성능을 향상시킬 수 있지만 충돌시 최대 1 초 분량의 트랜잭션을 잃을 수 있습니다. 값이 0이면 mysqld 프로세스 충돌로 인해 마지막 트랜잭션이 지워질 수 있습니다. 값이 2이면 운영 체제 충돌 또는 정전 만이 마지막 트랜잭션의 초를 지울 수 있습니다. InnoDB의 응급 복구는 값에 관계없이 작동합니다.

트랜잭션과 함께 InnoDB를 사용하는 복제 설정에서 최대한의 내구성과 일관성을 유지하려면 마스터 서버 my.cnf 파일에서 innodb_flush_log_at_trx_commit = 1 및 sync_binlog = 1을 사용하십시오.

주의

많은 운영 체제와 일부 디스크 하드웨어는 디스크 비우기 작업을 속입니다. 그들은 플러시가 발생하지 않았음에도 불구하고 mysqld에 알려줄 수있다. 그러면 설정 1을 사용해도 트랜잭션의 내구성이 보장되지 않으며 최악의 경우 정전으로 인해 InnoDB 데이터베이스가 손상 될 수도 있습니다. SCSI 디스크 컨트롤러 나 디스크 자체에서 배터리 백업 디스크 캐시를 사용하면 파일 플러시 속도가 빨라지고 작업이 더 안전 해집니다. 하드웨어 캐시에서 디스크 쓰기 캐싱을 비활성화하거나 하드웨어 공급 업체에 특정한 다른 명령을 사용하려면 Unix 명령 hdparm을 사용해보십시오.

이를 바탕으로 1 이외의 값으로 InnoDB는 1 초 분량의 트랜잭션 또는 트랜잭션 커밋 분량의 데이터를 잃을 위험이 있습니다.

이 문서에는 use라고 나와 있습니다 sync_binlog=1.

sync_binlog 의 MySQL 문서에 따르면

충돌이 발생하면 이진 로그에서 최대 하나의 명령문이나 트랜잭션이 손실되므로 값 1이 가장 안전한 선택입니다. 그러나 디스크에 배터리 백업 캐시가 없어 동기화 속도가 매우 빠르지 않은 한 가장 느린 선택이기도합니다.

가장 안전한 선택은

[mysqld]
innodb_flush_log_at_trx_commit=1
sync_binlog=1

가능한 데이터 손실 (최대 1 초 가치)을 염두에 두지 않으면 보상 (빠른 쓰기 속도)이 가치가있는 경우 위험 부담으로 0 또는 2를 사용할 수 있습니다.

는 innodb_flush_log_at_trx_commit같은 목적으로 사용된다 ..

값 innodb_flush_log_at_trx_commit 이 0이면 로그 버퍼가 초당 로그 파일에 기록되고 디스크로 플러시 작업이 로그 파일에서 수행되지만 트랜잭션 커밋에서는 아무것도 수행되지 않습니다.

값이 1 (기본값)이면 각 트랜잭션 커밋에서 로그 버퍼가 로그 파일에 기록되고 디스크로 플러시 작업이 로그 파일에서 수행됩니다.

값이 2 인 경우, 커밋 할 때마다 로그 버퍼가 파일에 기록되지만 디스크로 플러시 작업은 수행되지 않습니다. 그러나 값이 2 인 경우에도 로그 파일의 플러시가 초당 1 회 발생합니다. 프로세스 스케쥴링 문제로 인해 초당 플러시가 100 % 보장되는 것은 아닙니다.

완전한 ACID 준수를 위해서는 기본값 1이 필요합니다. 1과 다른 값을 설정하여 성능을 향상시킬 수 있지만 충돌시 최대 1 초 분량의 트랜잭션을 잃을 수 있습니다. 값이 0이면 mysqld 프로세스 충돌로 인해 마지막 트랜잭션이 지워질 수 있습니다. 값이 2이면 운영 체제 충돌 또는 정전 만이 마지막 트랜잭션의 초를 지울 수 있습니다. InnoDB의 응급 복구는 값에 관계없이 작동합니다.

내 의견 innodb_flush_log_at_trx_commit으로는 2를 사용하는 것은 문제가되지 않지만 1을 사용하는 것이 가장 안전합니다.

내 의견은 다른 의견과 다릅니다. innodb_flush_log_at_trx_commit = 0 인 경우 : 민감한 데이터가없는 개발 컴퓨터 또는 홈 미니 데이터베이스입니다.

innodb_flush_log_at_trx_commit = 2 인 경우 : 블로그 / 통계 / 전자 상거래 (매일 ~ 100x 상점) 등

innodb_flush_log_at_trx_commit = 1 인 경우 : 고객이 많거나 은행과 같은 돈 거래를해야하는 경우. 따라서 이번에는 속도와 안전을 위해 여러 서버간에 데이터 흐름을 분할해야합니다.

쓰기 속도가 ~ 75 배 빠르며 하드웨어에 장애가 발생하는 경우에만 실패하기 때문에 2를 선호합니다.

어쨌든 더 많은 쓰기 속도 또는 최대 1 초 정보가 필요한 것을 알고 있어야합니까?

대답하려고합니다. 목적은 무엇입니까? innodb_flush_log_at_trx_commit?

InnoDB는 대부분의 작업을 메모리에서 수행합니다 ( InnoDB Buffer Pool). 모든 수정 된 데이터는 InnoDB transaction log file내구성있는 저장소 (하드 디스크)에 기록 된 후 플러시 (기록)됩니다.

데이터 안전성 ( Durability from ACID)을 위해 InnoDB는 각 트랜잭션의 수정 된 데이터를 영구 저장소에 저장해야합니다. 동시에 각 트랜잭션에 대해 디스크에 커밋하는 과정은 비용이 많이 듭니다.

디스크 I / O는 블로킹 프로세스이며 매우 느리고 디스크가 느립니다. 또한 InnoDB transaction per seconds디스크 처리량을 줄일 수 있습니다.

InnoDB는 innodb_flush_log_at_trx_commit이 플러시 작업의 빈도를 제어하는 ​​변수를 제공 합니다. 값에 따라 InnoDB 플러시 작업은 다르게 동작합니다.

(다른 답변에서 이미 설명했습니다)

0-로그 파일에 기록하고 매초마다 디스크로 플러시합니다 (데이터는 로그 파일에 기록되지 않은 버퍼 풀에 있으며 성능 향상을 위해). 1-트랜잭션이 커밋 될 때 디스크로 플러시-기본값 (데이터 안전의 경우-ACID 준수) 2-모든 트랜잭션에 대한 로그 파일에 쓰고 매 초마다 디스크로 플러시합니다. (성능 향상을 위해)

응용 프로그램 요구 사항 ( Performance Vs data safety) 에 따라이 변수를 설정할 수 있습니다. 0과 2의 차이는 둘 다 성능을 높이고, 값 2는 트랜잭션 파일에 데이터를 저장하며 충돌이나 실패의 경우 복구 가능하지만 0은 아닙니다.

대부분의 경우 디스크로 플러시 란 데이터가 InnoDB buffer pool (memory) to Operating systems cache실제로 저장소 디스크 (영구 저장소)에 기록되지 않고 기록되는 것을 의미합니다 . 실패한 경우 최악의 경우 최대 1 초의 데이터가 손실 될 수 있습니다.)

성능 향상은 환경에 따라 다르며 벤치마킹하고 식별 할 수 있습니다. 복제 환경에서 데이터의 안전성과 일관성을 설정 innodb_flush_log_trx_commit = 1하고 sync_binlog=1.

성능이 응용 프로그램의 주요 목표 인 경우 InnoDB는 로그 플러시 빈도를 제어하는 ​​변수를 제공합니다.-- innodb_flush_log_at_timeout로그 플러시 빈도 범위를 1 to 2700 seconds기본값으로 1로 설정할 수 있습니다 .

플러시 간격을 최대 N 초까지 늘리면 데이터 안전성이 최대 N 초까지 저하되어 성능이 향상됩니다. 예를 들어, 매 5 초마다 플러시가 발생하도록 설정하면 처리량 이득이 매우 높지만 정전 또는 시스템 고장의 경우 5 초에 해당하는 데이터가 손실됩니다.

이 기사에서는 InnoDB 플러시 및 트랜잭션 커밋 작업에 대해 설명 합니다.

aws rds에서 모드 2를 수행 한 후 변경할 수 있습니다.

복제 다중 az가있는 경우와 같이 일부 경우에는 수정할 수 없습니다.

하드웨어가 고장 나면 모든 데이터를 잃을 수 있으므로 걱정없이 param = 2를 사용합니다. 어쨌든 2 개의 DB 서버간에 민감한 (주문, 가상 돈 ...) 및 일반 (통계, 장바구니 등) 데이터를 분리하여 안전하고 빠르게 유지할 수 있습니다. 데이터베이스 간 트랜잭션의 경우 http://dev.mysql.com/doc/refman/5.7/en/xa.html 을 사용할 수 있습니다.