마이그레이션 플러그인을 사용하여 XE 게시판을 워드프레스 케이보드 게시판으로 이관하는 작업을 최근 맡았습니다. XE 사이트 규모가 큰 경우 마이그레이션하는 과정에서 예상치 못한 난관에 직면할 수도 있습니다. 데이터 크기가 너무 크면 데이터를 다운로드/업로드하는 데 상당한 시간이 걸릴 수 있습니다. 너무 데이터가 큰 경우에는 개별 파일과 폴더를 업로드하려면 시간이 너무 많이 소요될 수 있습니다. 그런 경우 압축 파일로 다운로드하고 업로드하는 것을 고려할 수 있지만, 웹 서버 디스크 용량이 충분해야 가능합니다.
XE 게시판과 Kboard 게시판을 매핑한 다음, 이전을 시도하니 특정 게시판의 데이터가 너무 느리게 마이그레이션이 진행되었고, 중간에 멈추는 현상이 발생했습니다. 서버 에러 로그를 살펴보니 WordPress database error Got a packet bigger than 'max_allowed_packet' bytes for query 에러가 발생하는 것을 혹인할 수 있었습니다. 이 오류가 발생하는 경우 max_allowed_packet 값을 높이면 문제가 해결될 것입니다.
WordPress database error Got a packet bigger than 'max_allowed_packet' bytes for query... 오류가 발생하는 경우 해결 방법
워드프레스에서 마이그레이션 플러그인을 사용하면 XE, 그누보드, 제로보드, 킹콩보드 등의 게시판을 워드프레스 게시글이나 게시판으로 이전할 수 있습니다.
KBoard에서 게시판을 만들어 XE 등의 게시판을 매핑시켜 데이터를 이관할 수 있습니다.
보통은 빠르게 진행되지만, 어떤 이유로 인해 중도에 멈추는 경우가 있을 수 있습니다. 367개 게시글이 있는 XE 이벤트 게시판을 이전을 시도하니 50개째에서 멈추는 현상이 발생하여 서버 에러 로그를 확인해 보니 다음과 같은 에러가 발생하고 있었습니다.
WordPress database error Got a packet bigger than 'max_allowed_packet' bytes for query UPDATE `wp_options` SET `option_value` = 'a:164240:{s:60:\"/var/www/vhosts/example.net/httpdocs/wp-includes/php-compat\" ... /var/www/vhosts/example.net/httpdocs/wp-content/uploads\";i:78384062964;}' WHERE `option_name` = '_transient_dirsize_cache' made by require('wp-blog-header.php'), wp, WP->main, WP->parse_request, do_action_ref_array('parse_request'), WP_Hook->do_action, WP_Hook->apply_filters, rest_api_loaded, WP_REST_Server->serve_request, WP_REST_Server->dispatch, WP_REST_Server->respond_to_request, WP_REST_Site_Health_Controller->get_directory_sizes, WP_Debug_Data::get_sizes, recurse_dirsize, set_transient, update_option...
이 오류는 MySQL의 max_allowed_packet 설정값이 너무 낮아서 발생하는 문제입니다. 따라서 이 값을 높여주면 문제가 해결될 수 있습니다.
일반적으로 max_allowed_packet 설정은 DB에서 처리할 수 있는 최대 패킷 크기를 정의하며, 필요한 크기는 DB에서 처리하는 쿼리의 크기에 따라 다릅니다. 기본적으로 64M로 설정하면 대부분의 경우에 충분하지만, 대량의 데이터 업데이트를 처리해야 하는 경우에는 더 큰 값이 필요할 수 있다고 합니다.
서버의 램 크기가 8192MB여서 저는 이 값을 256M로 설정하여 테스트하니 (여전히 특정 게시판에서 이관 속도가 느렸지만) 중간에 멈추지 않고 이전이 완료되었습니다.
이벤트 게시판의 게시글 개수가 몇 개 되지 않았지만, 이상하게 이 게시판에서만 이런 현상이 발생했습니다.
SSH에 접속하여 my.cnf 파일을 편집하여 max_allowed_packet 값을 변경할 수 있습니다.
이 파일의 경로는 /etc/my.cnf 또는 /etc/mysql/my.cnf입니다. Vultr에서 Plesk 앱을 배포할 경우 이 파일의 경로는 /etc/mysql/my.cnf였습니다.
sudo nano /etc/my.cnf
또는
sudo nano /etc/mysql/my.cnf
명령을 실행하면 my.cnf 파일 편집 화면이 열립니다.
[mysql] 섹션을 찾아 다음 라인을 찾아 수정하거나 없는 경우 추가합니다.
[mysqld]
max_allowed_packet=64M
실제 크기는 서버 사양에 따라 적절히 변경합니다.
위의 라인을 추가하거나 수정한 후에 저장하도록 합니다. 그런 다음 아래의 명령을 실행하여 MySQL 서버를 재시작하면 변경 사항이 적용됩니다.
sudo systemctl restart mysql
또는
sudo service mysql restart
max_allowed_packet 값을 높였다면 다시 시도해보시기 바랍니다. 저는 256M로 이 값을 높이니 더 이상 에러가 발생하지 않았습니다.
이런 작업에 앞서, 가능한 경우 데이터와 디비 백업을 확실히 받아놓으면, 문제가 발생할 경우 쉽게 롤백이 가능합니다.
Vultr의 Plesk 앱이나 CyberPanel 앱을 사용하면 서버를 비교적 수월하게 운영할 수 있지만, 최소한의 서버 관리 지식이 필요할 수 있습니다. 보다 수월하게 Vultr 등의 서버를 선택하여 워드프레스 사이트를 운영하려는 경우 클라우드웨이즈(Cloudways)를 이용할 수 있습니다.
참고
https://avada.tistory.com/3046
https://avada.tistory.com/2897
https://avada.tistory.com/3383