max_allowed_packet 에 올바른 값을 설정합니다. |
대규모 트랜잭션 또는 빈로그가 한도를 초과하는 복제 설정에서 max_allowed_packet 크기를 위반하면 복제본이 실패한 복사본 상태가 되어 프라이머리가 잠길 위험이 발생할 수 있습니다. BLOB 또는 VARTEXT 열을 사용하여 MySQL 열에 파일 콘텐츠를 저장하면 백업의 복제 및 복원에 문제가 발생할 수 있습니다. 다양한 길이의 데이터를 열에 로드하는 경우 max_allowed_packet을
최대 값으로 구성하는 것이 좋습니다. 또한 특정 테이블에 여러 개의 넓은 LONGBLOB 열을 사용하면 행 크기가 최대 허용치를 초과하여 특정 시점을 사용한 복원이 작동하지 않는 상황이 발생할 수 있으므로 사용하지 마세요. |
| 행 수가 많은 테이블에 기본 키를 구현합니다. |
5K 행을 초과하는 테이블에 기본 키를 추가하면 복제를 크게 최적화하고 과도한 지연을 방지할 수 있습니다. 단일 문에서 5K 개 이상의 행을 삭제하거나 업데이트하는 작업이 수행되는 모든 테이블에 대해 기본 키를 정의하는 것이 좋습니다. 기본 키를 추가할 수 없는 경우 5K 행 미만의 일괄 처리로 삭제하고 일괄 처리당 커밋을 수행합니다. |
| 가능하면 전체 테이블 삭제보다 테이블 삭제 및 테이블 자르기를 선호합니다. |
복제는 모든 행 삭제를 기록하므로 프로세스 속도가 상당히 느려질 수 있습니다. 청크 삭제 및 업데이트를 권장합니다. DROP, CREATE 및 TRUNCATE는 DDL 문이며 백업 중에 완료되지 않고 백업 작업이 완료될 때까지 기다린다는 점에 유의하세요. 로그 항목에는 백업 중 이러한 문이 차단되는 시간에 대한 경고 메시지가 표시됩니다. 모니터링 대시보드의 디스크 사용량 패널을 확인하여 백업 시간을 예상할 수 있습니다.
일반적으로 500GB의 데이터를 백업하는 데는 약 90분이 걸립니다. |
| 업데이트 조인 또는 삭제와 같은 단일 문 다중 행 작업은 WHERE 범위 절을 사용하여 터치되는 행 수를 최소화합니다. |
이 방법을 사용하면 쿼리 성능을 개선하고 잠금 경합을 줄일 수 있습니다. |
| 애플리케이션 단에서 연결 풀링을 사용합니다. |
풀링은 연결을 재사용하여 연결이 최대로 초과되는 것을 방지합니다. 풀 크기가 데이터베이스의 max_connections 보다 훨씬 작은지 확인합니다. 재시도 로직을 구현하고 예외를 포착하여 풀 소진 또는 연결 실패를 처리하세요. |
| 프로덕션 애플리케이션당 전용 ICD-MySQL 인스턴스를 사용하여 폭발 반경을 줄이세요. |
애플리케이션을 분리하면 서비스 인스턴스당 볼륨이 줄어들어 여러 애플리케이션의 수요가 한꺼번에 몰리면서 발생하는 문제를 최소화할 수 있습니다. |
| MySQL 인스턴스당 MySQL 읽기 복제본을 배포합니다. |
읽기 복제본은 메인 인스턴스에서 읽기 트래픽을 지원하여 전체 워크로드를 줄이고 안정성을 향상시키는 기능을 제공합니다. |
| MySQL 를 전용 인스턴스에서 호스팅하기 |
생산 환경, 특히 성장 예상, 트래픽 증가, 높은 신뢰성 및 성능이 요구되는 환경에서는 MySQL 을 전용 인스턴스에 호스팅할 것을 강력히 권장합니다. 이는 더 나은 리소스 격리, 확장성 및 전반적인 시스템 안정성을 보장합니다. |