MySQL(Percona Server)을 5.7에서 8.0으로 업데이트

진전이 정체되지 않아 최신 버전의 MySQL로 업그레이드해야 하는 이유가 점점 더 설득력을 얻고 있습니다. 얼마 전 우리 프로젝트 중 하나에서 아늑한 Percona Server 5.7 클러스터를 버전 8로 업데이트할 때가 되었습니다. 이 모든 일은 Ubuntu Linux 16.04 플랫폼에서 발생했습니다. 가동 중지 시간을 최소화하면서 이러한 작업을 수행하는 방법과 업데이트 중에 발생한 문제는 이 기사에서 읽어보세요.

훈련

데이터베이스 서버의 모든 업데이트는 데이터베이스 재구성과 관련될 가능성이 높습니다. 즉, 시스템 리소스 제한에 대한 요구 사항 변경 및 오래된 지시문을 지워야 하는 데이터베이스 구성 수정입니다.

업데이트하기 전에 공식 문서를 반드시 참고하세요.

• MySQL 8 릴리스 노트;
• MySQL 업그레이드 가이드;
• 페르코나 업데이트 안내;
• 복제본 및 마스터 업데이트에 대한 MySQL 가이드.

그리고 행동 계획을 세워 봅시다.

1. 오래된 지시어를 제거하여 구성 파일을 수정하세요.
2. 유틸리티와의 호환성을 확인하십시오.
3. 패키지를 설치하여 슬레이브 데이터베이스 업데이트 percona-server-server.
4. 동일한 패키지로 마스터를 업데이트합니다.

계획의 각 지점을 살펴보고 무엇이 잘못될 수 있는지 살펴보겠습니다.

중요! Galera를 기반으로 MySQL 클러스터를 업데이트하는 절차에는 기사에 설명되지 않은 자체적인 세부 사항이 있습니다. 이 경우에는 이 지침을 사용하면 안 됩니다.

1부: 구성 확인

MySQL은 버전 8에서 제거되었습니다. query_cache. 실제로 그는 그랬다 쓸모없다고 선언됨 버전 5.7로 돌아갔지만 지금은 완전히 삭제됨. 따라서 관련 지시문을 제거해야 합니다. 요청을 캐시하기 위해 이제 외부 도구를 사용할 수 있습니다. 예를 들면 다음과 같습니다. 프록시SQL.

또한 구성에는 다음과 같은 오래된 지시문이 있었습니다. innodb_file_format. MySQL 5.7에서 InnoDB 형식을 선택할 수 있었다면 8번째 버전이 이미 작동하고 있는 것입니다. Barracuda 형식에만 해당.

결과적으로 다음 지시어가 제거되었습니다.

• query_cache_type, query_cache_limit и query_cache_size;
• innodb_file_format и innodb_file_format_max.

확인을 위해 Percona Server의 Docker 이미지를 사용하겠습니다. 서버 구성을 디렉토리에 배치합니다. mysql_config_test, 그 옆에 데이터 및 로그용 디렉터리를 생성합니다. Percona-서버 구성 테스트 예:

mkdir -p {mysql_config_test,mysql_data,mysql_logs}
cp -r /etc/mysql/conf.d/* mysql_config_test/
docker run  --name some-percona -v $(pwd)/mysql_config_test:/etc/my.cnf.d/  -v $(pwd)/mysql_data/:/var/lib/mysql/ -v $(pwd)/mysql_logs/:/var/log/mysql/ -e MYSQL_ROOT_PASSWORD=${MYSQL_PASSWORD} -d percona:8-centos

요점: 구성에 따라 Docker 로그 또는 로그가 있는 디렉터리에 문제가 있는 지시문을 설명하는 파일이 나타납니다.

우리가 가진 것은 다음과 같습니다.

2020-04-03T12:44:19.670831Z 0 [Warning] [MY-011068] [Server] The syntax 'expire-logs-days' is deprecated and will be removed in a future release. Please use binlog_expire_logs_seconds instead.
2020-04-03T12:44:19.671678Z 0 [Warning] [MY-013242] [Server] --character-set-server: 'utf8' is currently an alias for the character set UTF8MB3, but will be an alias for UTF8MB4 in a future release. Please consider using UTF8MB4 in order to be unambiguous.
2020-04-03T12:44:19.671682Z 0 [Warning] [MY-013244] [Server] --collation-server: 'utf8_general_ci' is a collation of the deprecated character set UTF8MB3. Please consider using UTF8MB4 with an appropriate collation instead.

따라서 우리는 여전히 인코딩을 파악하고 오래된 지시어를 교체해야 했습니다. expire-logs-days.

2부: 작동 중인 설치 확인

업데이트 문서에는 데이터베이스 호환성을 확인하는 두 가지 유틸리티가 포함되어 있습니다. 이를 사용하면 관리자가 기존 데이터 구조의 호환성을 확인하는 데 도움이 됩니다.

고전적인 mysqlcheck 유틸리티부터 시작해 보겠습니다. 간단히 실행하세요:

mysqlcheck -u root -p --all-databases --check-upgrade

문제가 발견되지 않으면 유틸리티는 코드 0으로 종료됩니다.

또한 최신 버전의 MySQL에서도 유틸리티를 사용할 수 있습니다. mysql-쉘 (Percona의 경우 이는 패키지입니다. percona-mysql-shell). 이는 기존 mysql 클라이언트를 대체하며 클라이언트 기능, SQL 코드 편집기 및 MySQL 관리 도구를 결합합니다. 업데이트하기 전에 서버를 확인하려면 서버를 통해 다음 명령을 실행할 수 있습니다.

mysqlsh -- util check-for-server-upgrade { --user=root --host=1.1.1.1 --port=3306 } --config-path=/etc/mysql/my.cnf

우리가 받은 의견은 다음과 같습니다.

일반적으로 중요한 것은 없습니다. 인코딩에 대한 경고만 있습니다. (아래 참조). 전체 실행 결과:

우리는 업데이트가 문제 없이 진행되어야 한다고 결정했습니다.

인코딩 문제를 나타내는 위의 경고에 대한 참고 사항입니다. 사실 최근까지 MySQL의 UTF-8은 UTF-8이 "사실"이 아니었습니다.3바이트 대신 4바이트만 저장했기 때문입니다. MySQL 8에서는 이것이 마침내 가능해졌습니다. 그것을 고치기로 결정했다: 별칭 utf8 곧 코딩으로 이어질 것이다 utf8mb4, 테이블의 이전 열은 다음과 같습니다. utf8mb3. 추가 인코딩 utf8mb3 제거될 예정이지만 이번 릴리스에서는 제거되지 않습니다. 따라서 우리는 업데이트 후 실행 중인 DBMS 설치에 이미 있는 인코딩을 수정하기로 결정했습니다.

3부: 서버 업데이트

이런 현명한 계획이 있으면 무엇이 잘못될 수 있습니까?.. 미묘한 차이는 항상 발생한다는 것을 잘 이해하고 MySQL 개발 클러스터에서 첫 번째 실험을 수행했습니다.

이미 언급했듯이, 공식 문서 복제본으로 MySQL 서버를 업데이트하는 문제를 다룹니다. 결론은 MySQL 8이 마스터 버전 5.7에서 복제할 수 있으므로 먼저 모든 복제본(슬레이브)을 업데이트해야 한다는 것입니다. 모드를 사용한다는 사실에 약간의 어려움이 있습니다. 마스터 <-> 마스터, 원격 마스터가 모드에 있을 때 읽기 전용. 즉, 실제로 전투 트래픽은 하나의 데이터 센터로 이동하고 두 번째는 백업 데이터 센터로 이동합니다.

토폴로지는 다음과 같습니다.

업데이트는 복제본으로 시작되어야 합니다. mysql 복제본 dc 2, mysql 마스터 dc 2 и mysql replica dc 1, mysql 마스터 dc 1 서버로 끝납니다. 신뢰성을 높이기 위해 가상 머신을 중지하고 스냅샷을 찍은 다음 업데이트 직전에 명령을 사용하여 복제를 중지했습니다. STOP SLAVE. 업데이트의 나머지 부분은 다음과 같습니다.

1. 구성에 3가지 옵션을 추가하여 각 복제본을 다시 시작합니다. skip-networking, skip-slave-start, skip-log-bin. 사실 데이터베이스를 업데이트하면 시스템 테이블 업데이트와 함께 바이너리 로그가 생성됩니다. 이러한 지시문은 데이터베이스의 애플리케이션 데이터가 변경되지 않고 시스템 테이블 업데이트에 대한 정보가 바이너리 로그에 포함되지 않음을 보장합니다. 이렇게 하면 복제를 재개할 때 문제가 발생하지 않습니다.
2. 패키지 설치 percona-server-server. MySQL 버전 8에서는 아니 명령을 실행해야합니다 mysqlupgrade 서버 업데이트 후.
3. 성공적으로 시작되면 첫 번째 단락에 추가된 매개변수 없이 서버를 다시 시작합니다.
4. 복제가 성공적으로 작동하는지 확인합니다. 확인 SHOW SLAVE STATUS 그리고 애플리케이션 데이터베이스의 카운터가 있는 테이블이 업데이트되었는지 확인하세요.

모든 것이 매우 간단해 보입니다. 개발 업데이트가 성공적이었습니다. 좋습니다. 프로덕션을 위한 야간 업데이트를 안전하게 예약할 수 있습니다.

슬픔은 없었습니다 - 우리는 제품을 업데이트했습니다

그러나 성공적인 개발 경험을 프로덕션으로 전환하는 것은 놀라운 일이 아니었습니다.

다행스럽게도 업데이트 과정 자체가 복제본으로 시작되기 때문에 문제가 발생하면 작업을 중단하고 스냅샷에서 복제본을 복원했습니다. 문제 조사는 다음날 아침으로 연기됐다. 로그에는 다음 항목이 포함되어 있습니다.

2020-01-14T21:43:21.500563Z 2 [ERROR] [MY-012069] [InnoDB] table: t1 has 19 columns but InnoDB dictionary has 20 columns
2020-01-14T21:43:21.500722Z 2 [ERROR] [MY-010767] [Server] Error in fixing SE data for db1.t1
2020-01-14T21:43:24.208365Z 0 [ERROR] [MY-010022] [Server] Failed to Populate DD tables.
2020-01-14T21:43:24.208658Z 0 [ERROR] [MY-010119] [Server] Aborting

Google의 다양한 메일링 리스트 아카이브를 조사한 결과 이 ​​문제가 다음으로 인해 발생한다는 것을 알게 되었습니다. MySQL 버그. 이것은 유틸리티 버그일 가능성이 더 높지만 mysqlcheck и mysqlsh.

MySQL은 소수 필드(int,tinyint 등)에 대한 데이터를 표현하는 방식을 변경했기 때문에 mysql-server는 이를 저장하기 위해 다른 방법을 사용합니다. 데이터베이스의 경우 처음에는 버전 5.5 또는 5.1에 있었다가 5.7로 업데이트했다면 다음을 수행해야 할 수도 있습니다. OPTIMIZE 일부 테이블의 경우. 그런 다음 MySQL은 데이터 파일을 업데이트하여 현재 저장 형식으로 전송합니다.

유틸리티를 사용하여 이를 확인할 수도 있습니다. mysqlfrm:

mysqlfrm --diagnostic -vv /var/lib/mysql/db/table.frm
...
 'field_length': 8,
  'field_type': 246, # формат поля
  'field_type_name': 'decimal',
  'flags': 3,
  'flags_extra': 67,
  'interval_nr': 0,
 'name': 'you_deciaml_column',
...

면 field_type 0과 같으면 이전 유형이 테이블에 사용됩니다. OPTIMIZE. 그러나 값이 246이면 이미 새 유형이 있는 것입니다. 유형에 대한 자세한 내용은 다음에서 확인할 수 있습니다. 암호.

또한, 이 버그 우리는 우리를 우회한 두 번째 가능한 이유를 고려하고 있습니다. 시스템 테이블에 InnoDB 테이블이 없기 때문입니다. INNODB_SYS_TABLESPACES, 테이블이 버전 5.1에서 생성된 경우. 업데이트 시 문제를 방지하려면 다음을 사용할 수 있습니다. 첨부된 SQL 스크립트.

개발팀에서는 왜 그런 문제가 발생하지 않았나요? 데이터베이스는 프로덕션에서 주기적으로 복사됩니다. 테이블이 다시 생성됩니다..

불행하게도 실제로 작동하는 대규모 데이터베이스에서는 범용 데이터베이스를 가져와서 실행할 수는 없습니다. OPTIMIZE. percona-toolkit이 도움이 될 것입니다. pt-online-schema-change 유틸리티는 온라인 OPTIMIZE 작업에 탁월합니다.

업데이트된 계획은 다음과 같습니다.

1. 모든 테이블을 최적화합니다.
2. 데이터베이스를 업데이트하십시오.

이를 확인하고 동시에 업데이트 시간을 확인하기 위해 복제본 중 하나를 비활성화하고 모든 테이블에 대해 다음 명령을 실행했습니다.

pt-online-schema-change --critical-load Threads_running=150 --alter "ENGINE=InnoDB" --execute --chunk-size 100 --quiet --alter-foreign-keys-method auto h=127.0.0.1,u=root,p=${MYSQL_PASSWORD},D=db1,t=t1

유틸리티가 기본 테이블에서 데이터를 복사하는 새 임시 테이블을 생성하므로 긴 잠금 없이 테이블이 업데이트됩니다. 두 테이블이 동일해지는 순간 원래 테이블은 잠기고 새 테이블로 교체됩니다. 우리의 경우 테스트 실행 결과 모든 테이블을 업데이트하는 데 하루 정도 소요되는 것으로 나타났으나 데이터 복사로 인해 디스크에 너무 많은 부하가 발생했습니다.

이를 방지하기 위해 프로덕션에서 명령에 인수를 추가했습니다. --sleep 값 10 - 이 매개변수는 데이터 배치를 새 테이블로 전송한 후 대기 시간을 조정합니다. 이렇게 하면 실제 실행 중인 애플리케이션이 응답 시간을 요구하는 경우 로드를 줄일 수 있습니다.

최적화를 수행한 후 업데이트가 성공했습니다.

... 하지만 완전히는 아닙니다!

업데이트 후 XNUMX분 이내에 클라이언트에 문제가 발생했습니다. 데이터베이스가 매우 이상하게 작동했습니다. 주기적으로 시작되었습니다. 연결 재설정. 모니터링을 해보니 이렇습니다.

스크린샷은 일부 MySQL 서버 스레드가 오류로 인해 주기적으로 충돌했기 때문에 톱니 모양의 그래프를 보여줍니다. 응용 프로그램에 오류가 나타났습니다:

[PDOException] SQLSTATE[HY000] [2002] Connection refused

로그를 빠르게 조사한 결과 mysqld 데몬이 운영 체제에서 필요한 리소스를 얻을 수 없다는 사실이 드러났습니다. 오류를 정리하던 중 시스템에서 발견한 "고아" 의류 정책 파일:

# dpkg -S /etc/apparmor.d/cache/usr.sbin.mysqld
dpkg-query: no path found matching pattern /etc/apparmor.d/cache/usr.sbin.mysqld
# dpkg -S /etc/apparmor.d/local/usr.sbin.mysqld
dpkg-query: no path found matching pattern /etc/apparmor.d/local/usr.sbin.mysqld
# dpkg -S /etc/apparmor.d/usr.sbin.mysqld
mysql-server-5.7: /etc/apparmor.d/usr.sbin.mysqld
# dpkg -l mysql-server-5.7
rc  mysql-server-5.7 5.7.23-0ubuntu0.16.04.1      amd64

이 파일은 몇 년 전 MySQL 5.7로 업그레이드할 때 생성되었으며 제거된 패키지에 속합니다. 파일을 삭제하고 의류 서비스를 다시 시작하면 문제가 해결되었습니다.

systemctl stop apparmor
rm /etc/apparmor.d/cache/usr.sbin.mysqld
rm /etc/apparmor.d/local/usr.sbin.mysqld
rm /etc/apparmor.d/usr.sbin.mysqld
systemctl start apparmor

결론적으로

가장 간단한 작업이라도 예상치 못한 문제가 발생할 수 있습니다. 그리고 잘 계획을 세웠다고 해서 항상 예상한 결과가 보장되는 것은 아닙니다. 이제 우리 팀의 모든 업데이트 계획에는 최근 조치의 결과로 나타날 수 있는 불필요한 파일을 의무적으로 정리하는 것도 포함됩니다.

그리 전문적이지는 않은 그래픽 창의성을 바탕으로 뛰어난 제품을 제공한 Percona에게 큰 감사를 전하고 싶습니다!

PS

블로그에서도 읽어보세요.

• «데이터베이스 및 Kubernetes(개요 및 동영상 보고서)";
• «Kubernetes 팁과 요령: 대규모 데이터베이스의 부트스트랩 속도 향상";
• «SRE 일상생활에 대한 6가지 실용적인 이야기";
• «K8s의 Redis 운영자에 대한 이야기와 이 데이터베이스의 데이터를 분석하기 위한 유틸리티에 대한 간략한 검토";
• «MongoDB를 Kubernetes로 원활하게 마이그레이션".

출처 : habr.com