MySQL 새 버전 선정

회사에서는 초기에는 mysql5.5 버전을 주로 사용했는데, 올해는 데이터베이스 구성 센터를 구축하고 성능과 성능을 모두 갖춘 mysql5.6 버전을 주로 홍보했습니다. 기능이 개선되면 mysql5.6도 gtid를 지원할 수 있지만 온라인에서 gtid 모드와 일반 모드 사이를 전환할 수는 없습니다. 동시에 5.6의 동기화 성능은 여전히 ​​만족스럽지 못하며 이러한 경우에만 병렬 복제를 시작할 수 있습니다. 비즈니스에서는 이러한 보장이 어렵기 때문에 쓰기 작업이 집중되면 동기화 속도가 느려지는 것이 심각한 문제가 될 것입니다.

그래서 최근 MySQL 업그레이드를 고려하고 있습니다. MySQL을 업그레이드할 때 가장 먼저 직면하는 문제는 적합한 버전을 선택하는 것입니다. 우선 mysql5.7 사용을 고려하고 있습니다. 5.7은 올해 여러 가지 공식 버전으로 출시되었습니다. 공식적인 환경에서 사용하는 것이 고려될 수 있습니다. 그래서 우리는 온라인 비교 테스트를 실시한 결과 mysql5.7과 온라인 버전의 mysql5.6 사이에 성능에 큰 차이가 있음을 발견했습니다(일부 매개 변수가 제대로 조정되지 않았기 때문일 수도 있지만 실제로 5.7은 훨씬 더 복잡합니다).

동시에 회사에서는 최근 일부 로그 저장소를 자주 보았습니다. 대부분 innodb 엔진을 사용하는데 이는 용량 낭비입니다. 반면에 우리 회사의 표준 mysql 서버 용량은 대략 1.3T, 일부 대규모 기업의 경우 용량 요구 사항이 있는 경우에도 용량 병목 현상이 발생하므로 장기간 데이터를 보관하려면 수요를 충족하기 어려울 수 있습니다. 그래서 이번 기회에 Percona와 Mariadb 모두 Tokudb를 지원하고 있으며 Mariadb 10.2나 10.3에서도 Myrocks를 지원할 계획입니다.

그래서 비교 테스트를 하기로 결정하고 Percona 5.7.14, Mariadb 10.1.18 및 온라인 MySQL 5.6을 비교 테스트로 선택하고 스트레스 테스트를 통과했습니다.

우선 Innodb 엔진을 사용합니다:

Mariadb와 MySQL5.6의 테스트 결과가 비슷합니다.

Percona 5.7.14의 성능 결과와 공식 MySQL5.7은 MySQL 5.6과 비교하면 비슷합니다(performance_schema를 제거하는 것이 더 좋지만 여전히 차이가 있습니다).

Tokudb 엔진을 사용한 테스트 결과는 공식 주장과 다릅니다. snappy 압축을 사용할 경우 삽입 속도는 innodb보다 1/4 정도 느리고 업데이트 속도는 innodb의 절반 정도에 불과합니다. 페르코나의 성능이 더 나쁘기 때문에 고려하지 않을 것입니다.

마침내 Mariadb 10.1.18을 선택하고 온라인으로 사업을 전개하게 되었고, 이 사업을 천천히 시도한 후 점차 추진하게 되었습니다.

Mariadb를 사용하면서 겪게 되는 몇 가지 함정

저는 Mariadb를 사용하는 과정에서 많은 문제에 직면했습니다. 여기서는 참고로 제가 겪었던 두 가지 주요 문제를 주로 언급합니다. >
1. 동기화 성능 문제:

비즈니스 피크 기간이 9,000회/초를 넘었습니다. 첫 번째 문제는 동기화 성능이 슬레이브 수를 따라가지 못한다는 것입니다. 동기화 스레드는 16개 스레드로 늘어나 거의 따라잡을 수 없습니다. 그러나 데이터베이스가 잠시 중지되면 결코 따라잡지 못할 가능성이 있습니다. 거의 절망에 빠졌을 때 mariadb 공식 기사(https://mariadb.com/kb/en/mariadb/parallel-replication/)를 읽었습니다. Mariadb의 병렬 복제는 순차 모드와 두 가지 모드를 지원합니다. 비순차적이지만 당사 비즈니스는 순차순을 지원하므로 비순차적 모드에서는 보수적 및 낙관적이라는 두 가지 유형이 지원됩니다. 이 병렬 모드는 엄격하게 지원됩니다. 5.7의 그룹 커밋 원칙과 유사한 순서를 보장합니다. 낙관적 모드에서는 복제 중에 가능한 한 많은 세션이 시작되고 충돌이 발견될 때까지 충돌이 처리되지 않습니다. 과감히 Optimistic을 사용해 보았는데 최대 동기화 속도가 14,000회/초로 매우 강력했습니다.

2. "메모리 누수"

시스템 배포 구조는 MariaDB 2개를 마스터-마스터 복제로 사용하고, 자체 개발한 분산 데이터베이스를 전면 배포하고, 사업측은 분산 데이터베이스 데이터베이스 프로세스에 연결합니다. 시스템이 며칠 동안 온라인 상태가 된 후 기본 데이터베이스가 설명할 수 없을 정도로 중단되는 것으로 나타났습니다. 다행스럽게도 분산 데이터베이스가 있으며 MariaDB 기본 데이터베이스가 중단되면 자동으로 다른 기본 데이터베이스로 전환됩니다. 비즈니스 측이 눈치채지 못하게 데이터베이스를 관리합니다. 커널 로그를 확인해보니 OOM이었고 커널이 MySQL을 종료한 것으로 나타났습니다.

그래서 Tokudb 엔진 구성을 제거하고 Mariadb 10.1.19로 변경하는 등 다양한 시도를 해봤지만 결국 메인 데이터베이스가 충돌했습니다. 우연히 메인 라이브러리에서 슬레이브를 중지했는데 갑자기 메인 라이브러리의 메모리가 많이 줄어들고 메모리가 더 이상 늘어나지 않는 것을 발견했습니다. 그런데 메인 라이브러리에서 슬레이브를 시작하자마자 메모리가 증가하지 않는 것을 발견했습니다. 점차적으로 다시 증가했습니다. 이 현상은 mysql 스레드의 메모리 할당 메커니즘(mem_root 기반 메모리 할당, 스레드가 중지되면 모두 해제됨)과 매우 유사하므로 초기에는 이것이 원인일 것으로 의심됩니다. 듀얼 마스터의 다른 MariaDB와 마찬가지로 메모리 증가 문제는 없을 것으로 나타났습니다.

위 현상을 발견한 후 gdb를 사용하여 하나의 mariadb를 시작하고 다른 하나는 일반 명령으로 이 두 라이브러리를 이중 마스터로 만듭니다.

첫 번째 방법 상황: 슬레이브 라이브러리로 테스트할 때 수신된 binlog 이벤트

일반 명령으로 시작된 mariadb에 데이터 행을 삽입하여 수신된 이벤트를 보는 순서는 다음과 같습니다.

### i ) Gtid_log_event
### ii) Table_map_log_event
### iii) Write_rows_log_event
### iv) Xid_log_event

아니요. 두 가지 상황: 메인 라이브러리로 테스트할 때 binlog 이벤트가 수신되었습니다.

在gdb启动的mariadb上插入一行记录，然后gdb观察接收到的事件为：

### 1）Rotate_log_event
### 2）Gtid_list_log_event
### 3）Rotate_log_event

Rotate_log_event事件是虚拟出来的，用于让主库跟上从库的同步位置，这基本上是一个空事件，没有做任何处理，所以初步怀疑是在处理Gtid_list_log_event事件的时候，出现了问题。

反复查看Gtid_list_log_event::do_appy_event函数中的调用情况，发现确实有些方法会调用thd->alloc来分配内存，但是没有回收，所以造成内存不断的增大，我考虑了一下，因为是主库对于同步性能要求也不高，所以在Gtid_list_log_event::do_apply_event函数的最后加了一行代码：free_root(thd->mem_root, MYF(MY_KEEP_PREALLOC));  重新编译后，跑了一天，内存终于稳定了。

由于目前发现只有主库有该事件，主库同步处理性能要求不高，所以暂时先这样用着了。不知道mariadb官方版本什么时候会优化一下。

总体来看，Mariadb还是比较适合我们公司的，它有最新的功能、特性能够给我们提供很多解决方案。Tokudb可以解决日志型存储的问题；连接池可以解决大量连接情况下性能地下的问题；审计插件提供安全方面的审核；slave并发模式能够提供高性能的复制能力。除了这些常见功能以外，Mariadb还提供了Cassandra插件、图数据库插件等等，这些都给我们给业务的服务增加了想象力。

【相关推荐】

1. 免费mysql在线视频教程

2. MySQL最新手册教程

3. 数据库设计那些事

위 내용은 Mariadb를 사용할 때 발생하는 두 가지 문제 공유의 상세 내용입니다. 자세한 내용은 PHP 중국어 웹사이트의 기타 관련 기사를 참조하세요!