MySQL 원리와 InnoDB 스토리지 엔진 아키텍처 설계를 완전히 마스터하세요.

이 기사는 mysql 원리의 InnoDB 스토리지 엔진 아키텍처 설계에 대한 관련 지식을 제공하는 데 도움이 되기를 바랍니다.

InnoDB 구성 요소 구조:

1. 버퍼 풀: 버퍼 풀, 캐시 디스크 데이터

2. redo 로그 버퍼: 버퍼 풀에 작업을 기록하고, 다운타임을 방지하기 위해 정책에 따라 디스크에 기록하지만 트랜잭션은 커밋됨 데이터 손실

3. undo 로그: 버퍼 풀의 데이터가 수정되면 트랜잭션이 제출되기 전에 롤백이 수행될 수 있습니다. 이때 롤백을 용이하게 하기 위해 언두 로그 파일에 이전 값이 기록됩니다. 버퍼 풀의 데이터 디스크와의 불일치는 더티 데이터입니다

1. 버퍼 풀

업데이트 문이 있다고 가정합니다.

update users set name = 'lisi' where id = 1

를 데이터베이스에 업데이트해야 합니다. InnoDB는 어떤 작업을 수행합니까?

먼저 InnoDB는 id = 1인 데이터가 버퍼 풀에 있는지 확인합니다. 존재하지 않으면 디스크에서 버퍼 풀로 로드되고 배타적 잠금도 추가됩니다. 여러 SQL을 방지하려면 이 데이터 행도 수정하세요.

2. undo 로그 파일

id = 1이라고 가정합니다. 이 데이터 이름의 원래 값은 name = 'zhangsan'입니다. 이제 이를 name = 'lisi'로 업데이트하려고 합니다. 이전 값을 name ='zhangsan' 및 id=1로 변경하면 실행 취소 로그 파일에 정보가 기록됩니다.

데이터베이스에 익숙한 학생들은 트랜잭션의 개념을 모두 이해하고 트랜잭션이 제출되기 전에 모든 작업이 롤백될 수 있습니다. 즉, name = 'lisi'는 name = 'zhangsan'으로 롤백될 수 있습니다. 업데이트됩니다. 이전 값이 실행 취소 로그 파일에 기록됩니다.

3. 버퍼 풀 데이터 업데이트

실행 취소 로그 파일이 작성된 후 메모리에서 이 데이터 업데이트를 시작합니다. 이름 = 'zhangsan'을 ID = 1로 이름 = 'lisi'로 업데이트합니다. 이때 메모리의 데이터는 업데이트되었지만 디스크의 데이터는 변경되지 않았습니다. 이때 일관성 없는 더티 데이터가 나타납니다.

이때, 트랜잭션이 제출되었으나 MySQL 서비스가 다운되고 메모리에 있는 데이터가 디스크에 기록되지 않은 경우 데이터 손실이 발생하고 불일치가 발생하는지 궁금하실 수 있습니다. SQL 실행 데이터에서?

4. 리두 로그 버퍼

InnoDB 구조에는 리두 로그를 저장하는 리두 로그 버퍼가 있습니다. 예를 들어 id=1, name='zhangsan'을 name=으로 변경합니다. '리시' 로그입니다.

하지만 이때 Redo 로그 버퍼는 메모리에만 존재하며, MySQL 다운타임 이후 데이터 복구는 불가능합니다.

5. 트랜잭션이 제출되지 않은 경우 데이터베이스가 다운되면 영향이 있나요?

실제로는 아무런 영향이 없습니다. 트랜잭션이 제출되지 않아 실행이 성공하지 못한다는 의미입니다. MySQL이 충돌하거나 다운되더라도 버퍼 풀의 수정된 데이터와 메모리의 Redo 로그 버퍼는 그대로 유지됩니다. 손실되며 데이터의 일관성에는 영향을 미치지 않습니다. 트랜잭션 커밋이 실패하면 데이터베이스의 데이터는 변경되지 않습니다.

6. 트랜잭션 제출, 리두 로그 구성 전략

트랜잭션을 제출하면 리두 일기는 전략에 따라 리두 로그 버퍼의 리두 로그를 디스크에 기록합니다. 정책은 innoDB_flush_log_at_trx_commit를 통해 구성됩니다.

1. innoDB_flush_log_at_trx_commit 매개변수는 0입니다. 트랜잭션이 커밋된 후에도 Redo 로그는 디스크에 기록되지 않습니다. MySQL이 충돌하면 메모리의 데이터가 손실됩니다.

1. innoDB_flush_log_at_trx_commit의 매개변수는 1입니다. 트랜잭션이 제출된 후 리두 로그는 메모리에서 디스크로 플러시됩니다. 트랜잭션이 성공적으로 제출되는 한 리두 로그는 확실히 존재합니다. 디스크에.

이때 버퍼 풀 데이터가 디스크에 플러시되지 않더라도 Redo 로그에서 어떤 데이터가 수정되었는지 알 수 있습니다. MySQL을 종료하고 다시 시작한 후에 수정된 데이터를 확인할 수 있습니다. 리두 로그에서 복원됩니다.

1. innoDB_flush_log_at_trx_commit의 매개변수는 2입니다. 트랜잭션이 제출된 후 리두 로그는 OS 캐시에만 유지되며 이때 서비스가 다운되는 경우 디스크로 플러시되지 않습니다. 그러면 os 캐시의 데이터도 손실됩니다. 트랜잭션이 성공적으로 제출되더라도 데이터는 손실됩니다.

이 내용을 읽은 후 데이터 보안을 보장하려면 매개 변수 1이 최선의 전략이라고 생각합니다.

7. 트랜잭션의 최종 제출물인 binlog

binlog는 실제로 MySQL Server에 속한 로그 파일이며, redo 로그와 밀접한 관련이 있기 때문에 여기서 언급합니다.

1) biglog와 redo 로그의 차이점

• redo 로그: "어떤 데이터 페이지에 어떤 기록이 있는지, 어떤 수정이 이루어졌는지"와 같은 부분적인 물리적 특성을 지닌 redo 로그를 기록합니다

• Binlog: "사용자 테이블에서 id=10인 데이터 행이 업데이트되었습니다. 업데이트 후 값은 무엇입니까?"와 같이 보다 논리적인 로그입니다.

2) binlog를 다음 위치에 작성하세요.

업데이트를 실행하는 동안 innoDB는 버퍼 풀에 데이터 로드, 실행 취소 로그 파일 작성, 메모리 데이터 업데이트, 리두 로그 작성 및 디스크 플러시 등을 포함하여 실행기와 지속적으로 상호 작용합니다. binlog에 대한 쓰기도 실행 프로그램에 의해 수행됩니다.

업데이트 문을 실행할 때 1, 2, 3, 4단계를 수행하고, 트랜잭션을 커밋할 때 5, 6단계를 수행합니다.

3) Binlog 로그 플러시 전략 분석

sync_binlog 매개변수는 binlog 플러시 전략을 제어합니다.

1. sync_ binlog의 기본값은 0입니다. 트랜잭션이 제출된 후 binlog 로그는 os 캐시에 저장됩니다. MySQL이 다운된 후 문제가 발생합니다. os 캐시

2. sync_binlog 값은 1입니다. 트랜잭션이 제출된 후 binlog 로그가 디스크로 직접 플러시됩니다.

4) binlog 및 redo 로그를 기반으로 트랜잭션 제출 완료

binlog가 디스크에 기록된 후 binlog 로그 파일의 위치와 파일 이름이 redo 로그 파일에 기록됨과 동시에 Redo 로그 파일에 커밋 표시를 작성합니다.

5) 커밋 태그의 의미는 무엇인가요?

커밋 표시는 redo 로그와 binlog 로그를 일관되게 유지한다는 의미입니다. 5단계 또는 6단계에서 트랜잭션 제출이 시작되고 MySQL이 다운되고 리두 로그에 커밋 표시가 없으면 트랜잭션 제출이 실패합니다.

커밋 표시는 트랜잭션이 마침내 성공적으로 제출되었음을 의미합니다.

8. 버퍼 풀 더티 데이터는 디스크로 플러시됩니다.

더티 데이터는 백그라운드 IO 스레드에 의해 무작위로 디스크로 플러시됩니다.

이 때, 디스크를 플래싱하기 전에 MySQL이 다운되면 어떻게 해야 할까? 이때 트랜잭션은 성공적으로 제출되었으며, Redo 로그에 커밋 표시가 남아 있습니다. 다운되더라도 재시작 후에는 Redo 로그 파일에 따라 데이터가 메모리에 업데이트되어 IO를 기다립니다. 디스크를 플러시하는 스레드입니다.

9. 요약

update 문을 통해 분석을 실행한 후 InnoDB 스토리지 엔진에는 다음과 같이 버퍼 풀 버퍼 풀, redo 로그 버퍼 버퍼 및 기타 캐시 데이터, undo, reod 로그 및 기타 로그 파일이 포함되어 있음을 알게 되었습니다. MySQL 서버 로그 파일도 마찬가지입니다.

업데이트 문을 실행하면 버퍼 풀, 실행 취소 로그 파일 작성, 리두 로그 버퍼 작성 및 기타 작업이 수정되고, 트랜잭션이 제출되면 리두 로그가 플러시되고, binlog가 플러시되고, binlog 파일이 삭제됩니다. 이름과 위치가 기록되고 커밋 표시를 입력한 후 마지막으로 IO 스레드가 버퍼 풀의 더티 데이터를 무작위로 플러시할 때까지 기다립니다.

추천 학습: mysql 비디오 튜토리얼

위 내용은 MySQL 원리와 InnoDB 스토리지 엔진 아키텍처 설계를 완전히 마스터하세요.의 상세 내용입니다. 자세한 내용은 PHP 중국어 웹사이트의 기타 관련 기사를 참조하세요!