MU-Migration으로 WordPress 다중 사이트 마이그레이션을 간소화하는 방법

게시 됨: 2022-03-10

빠른 요약 ↬ MU-Migration 도구를 소개합니다. MU-Migration 도구는 개발자가 다중 사이트 인스턴스 간에 사이트를 마이그레이션하는 데 도움이 되는 WP-CLI 명령입니다. 다중 사이트 마이그레이션에는 다양한 기술적 복잡성이 있으며 이 도구는 이를 완화하는 데 도움이 될 수 있습니다.

독립형 WordPress 사이트를 사이트 네트워크(또는 "다중 사이트") 환경으로 마이그레이션하는 것은 지루하고 까다로운 작업이지만 그 반대도 마찬가지입니다. WordPress Importer는 작고 단순한 사이트에서 합리적으로 잘 작동하지만 개선의 여지가 있습니다. 콘텐츠는 내보내지만 위젯 및 사용자 지정 프로그램 구성, 플러그인 및 사이트 설정과 같은 사이트 구성 데이터는 내보내지 않습니다. 수입업체는 또한 많은 양의 콘텐츠를 처리하는 데 어려움을 겪고 있습니다. 이 기사에서는 WP-CLI 플러그인인 MU-Migration을 사용하여 이러한 유형의 마이그레이션을 간소화하는 방법을 배웁니다.

멀티사이트 이해하기

WordPress 다중 사이트를 사용하면 동일한 WordPress 설치 내에서 여러 웹 사이트를 실행할 수 있습니다. 흔히 "다중 사이트 네트워크"라고 합니다. WordPress.com은 아마도 동일한 WordPress 인스턴스 내에서 수천 개의 사이트를 실행하는 다중 사이트 네트워크의 가장 큰 예일 것입니다.

WordPress 다중 사이트는 여러 사용 사례에 완벽하게 적합할 수 있으며 그 중 일부는 다음을 포함합니다.

클라이언트에는 여러 속성이 있을 수 있으며 모든 사이트를 고유한 WordPress 설치로 통합하여 단일 도메인을 공유하지만 이에 국한되지 않는 것이 합리적일 수 있습니다.
설정이 완료되면 새 사이트를 시작하고 네트워크에서 이미 사용 가능한 테마와 플러그인을 활용하는 간단하고 간단한 프로세스입니다.

다중 사이트 작동 방식에 대한 깊은 이해는 이 기사의 범위를 벗어나지만 다음 링크를 확인할 수 있습니다.

"네트워크 만들기", Codex, WordPress.org
"WordPress Multisite: 실용적인 기능과 방법", Kevin Leary, Smashing Magazine

점프 후 더! 아래에서 계속 읽기 ↓

도전과제 이해하기

단일 사이트 구조와 WordPress 다중 사이트 구조의 차이점은 상당히 합리적입니다. 다중 사이트를 사용하면 모든 사이트에서 공유되는 사용자 테이블( wp_user )을 제외하고 각 하위 사이트는 고유한 데이터베이스 테이블 세트를 얻습니다. 이것이 WordPress에서 작동하는 방식은 테이블의 각 하위 사이트 세트에 사이트 ID가 각 테이블 이름( wp_X_posts , wp_X_postmeta , wp_X_options )에 추가된다는 것입니다.

이 데이터베이스 구조 자체는 이미 몇 가지 복잡성을 도입합니다. 예를 들어, 다중 사이트에서 단일 설치로 하위 사이트를 마이그레이션하는 방법은 무엇입니까? 분명히, 단일 설치로 데이터베이스를 내보내고 가져올 수는 없습니다. 테이블 이름이 다릅니다! 내보낸 .sql 파일의 테이블 이름을 바꾸거나 ALTER TABLE SQL 쿼리를 사용하여 가져온 후 테이블 이름을 바꿔야 합니다. 반대의 경우에도 마찬가지입니다. 단일 사이트를 다중 사이트로 가져오는 경우 테이블 접두사도 업데이트해야 합니다. 너무 많은 작업처럼 들리지 않습니까?

다중 사이트의 사용자 테이블은 전역입니다. 즉, 다중 사이트 전역 사용자 테이블을 완전히 무시하므로 단일 사이트에서 사용자 테이블을 가져올 수 없습니다. 반대의 경우 WordPress에서 하위 사이트를 추출하고 단일 사이트로 가져오면 마이그레이션되는 하위 사이트에 속하지 않는 사용자를 포함하여 네트워크의 모든 사용자를 이어받게 됩니다. 또한 하위 사이트를 한 다중 사이트에서 다른 다중 사이트로 마이그레이션하는 경우 사용자 테이블을 내보내는 것은 테이블에서 완전히 벗어납니다.

가장 좋은 해결책은 사용자를 개별적으로 내보내는 것이지만 다른 문제가 발생합니다. 사용자를 가져올 때 다른 ID를 갖게 됩니다. 이 문제를 해결하려면 새 사용자의 ID를 추적하고 매핑 테이블을 만들고 매핑 테이블을 사용하여 WordPress의 사용자 ID에 대한 모든 참조를 업데이트해야 합니다! 다시 말하지만, 너무 많은 작업, 맞습니까?

이는 이와 같은 마이그레이션을 처리할 때 직면할 수 있는 문제의 두 가지 예일 뿐입니다. 업로드 폴더를 적절한 위치로 이동, 사이트 ID를 참조하는 데이터베이스의 레코드 마이그레이션 등과 같이 처리해야 하는 다른 사소한 일도 많이 있습니다.

MU-Migration 만나기

MU-Migration은 여러 클라이언트 마이그레이션 작업 중에 생성한 WP-CLI 플러그인이며 나중에 10up에서 오픈 소스로 제공됩니다. 단일 WordPress 사이트에서 다중 사이트 인스턴스로(또는 그 반대로) 사이트를 이동하는 프로세스를 간소화하기 위해 고안되었습니다. 기본적으로 모든 것을 ZIP 패키지로 내보낸 다음 원하는 WordPress 설치에서 사이트를 가져오는 데 사용할 수 있습니다.

사이트의 콘텐츠와 선택적으로 테마, 플러그인 및 업로드 폴더를 다른 WordPress 설치로 쉽게 가져올 수 있는 zip 패키지로 내보내는 방식으로 작동합니다. MU-Migration을 사용할 때 마이그레이션의 기본 기술 세부 사항에 대해 걱정할 필요가 없습니다. 이 모든 것을 간단히 처리하므로 고객에게 성공적인 마이그레이션을 제공하는 중요한 일에 집중할 수 있습니다.

WP-CLI 및 MU-Migration 설치

MU-Migration을 사용하려면 먼저 공식 WordPress 명령줄 도구인 WP-CLI를 설치해야 합니다. WP-CLI를 설치하는 것은 서버에서 아래 명령을 실행하는 것만큼 간단합니다.

 $ curl -O https://raw.githubusercontent.com/wp-cli/builds/gh-pages/phar/wp-cli.phar $ chmod +x wp-cli.phar $ sudo mv wp-cli.phar /usr/local/bin/wp

이 단계를 실행한 후 WordPress 루트 디렉토리에 있는 한 WordPress 설치에서 wp 만 입력하여 WP-CLI를 실행할 수 있습니다.

예를 들어 WordPress 설치 폴더에서 다음 명령을 실행해 보십시오.

 $ wp theme status

이것은 간단한 명령이며 사용 가능한 모든 테마를 나열하고 현재 활성화된 테마를 강조 표시합니다.

마지막으로 MU-Migration을 설치하기 위해 package install 명령을 활용할 수 있습니다. 다음 명령을 사용하여 MU-Migration을 WP-CLI 플러그인으로 다운로드하고 설치합니다.

 $ wp package install 10up/mu-migration

단순 마이그레이션 실행

MU-Migration의 사용법은 매우 간단합니다. 첫 번째 시나리오에서는 단일 WordPress 사이트를 WordPress 다중 사이트 설치로 이동합니다.

단일 사이트 내보내기

단일 사이트를 내보내는 것으로 시작하겠습니다. 그렇게 하려면 export all 명령을 사용해야 합니다.

 $ wp mu-migration export all single-site.zip --themes --plugins --uploads

위의 명령은 전체 사이트를 ZIP 패키지로 --themes , --plugins 및 --uploads 플래그는 선택 사항이며 내보내기에 각각 현재 테마, 모든 플러그인 및 업로드 폴더를 포함합니다. 사이트 크기에 따라 프로세스를 완료하는 데 시간이 걸릴 수 있지만 대부분의 사이트에서 내보내기 프로세스는 몇 분 이상 걸리지 않습니다.

완료되면 모든 사이트 데이터, 테마 및 플러그인과 업로드 디렉토리가 포함된 single-site.zip 이라는 파일이 생성됩니다. 다음 단계는 WordPress 다중 사이트가 있는 서버로 이동하는 것입니다. 선호하는 SFTP 클라이언트 또는 rsync 와 같은 보다 강력한 솔루션을 사용할 수 있습니다.

단일 사이트를 다중 사이트로 가져오기

다중 사이트 서버에서 내보낸 파일을 사용하여 WordPress 다중 사이트 디렉토리에서 가져오기 명령을 사용하기만 하면 됩니다. 말할 필요도 없이 WP-CLI와 MU-Migration도 대상 서버에 설치해야 합니다.

 $ wp mu-migration import all /path/to/single-site.zip --new_url=example.com/single-site

위의 명령은 single-site.zip 파일을 가져와 압축을 풀고 모든 것을 다중 사이트로 가져옵니다. 네트워크에 새 하위 사이트가 생성됩니다. --new_url 매개변수는 선택 사항입니다. MU-Migration이 검색을 수행하도록 지시하고 내보낸 사이트의 사이트 URL을 모두 지정된 것으로 교체하기 위해 교체합니다. 이 매개변수는 마이그레이션에 URL 변경이 포함되거나 로컬로 가져오거나 스테이징 환경에서도 유용합니다.

가져오기 프로세스는 일반적으로 더 오래 걸리고 가져오는 사이트의 크기에 따라 다르지만 MU-Migration은 마이그레이션이 실행되는 동안 계속 업데이트됩니다. 프로세스가 완료되면 MU-Migration에서 가져온 사이트의 최종 URL을 알려줍니다. 서버에서 실행되는 모든 캐시 계층, 특히 Memcache 또는 Redis를 플러시하는 것이 좋습니다 .

마이그레이션 재실행

마이그레이션을 수행할 때 최종 마이그레이션을 실행하기 전에 테스트할 목적으로 먼저 테스트 실행을 수행하는 것이 일반적입니다. 이는 일반적으로 대상 다중 사이트 설치에서 다른 내보내기를 수행하고 다시 가져오는 것을 의미합니다. 그러나 첫 번째 마이그레이션 예제에서 MU-Migration은 네트워크 위에 단일 사이트를 가져오기 위해 네트워크 내에 새 하위 사이트를 만들었습니다. 똑같은 명령을 다시 실행하면 우리가 기대하는 것과 정확히 다른 하위 사이트가 생성됩니다.

다행히 MU-Migration이 지정된 blog_id 로 하위 사이트를 재정의하도록 지시하는 blog_id 를 지정할 수 있습니다. 예를 들어 이전 가져오기 명령이 ID가 2 인 하위 사이트를 생성했으며 마이그레이션을 다시 실행하려고 한다고 가정해 보겠습니다. 다음을 수행할 수 있습니다.

 $ wp mu-migration import all /path/to/single-site.zip --new_url=example.com/single-site --blog_id=2

blog_id 를 모르는 경우 네트워크 관리자 설정을 통해 또는 $ wp site list 을 실행하여 얻을 수 있습니다.

다중 사이트 설치에서 하위 사이트 추출

MU-Migration은 또한 다중 사이트 설치에서 하위 사이트 추출 및 다른 다중 사이트 또는 단일 사이트로 가져오기를 지원합니다.

이 두 시나리오의 경우 단일 사이트가 아닌 다중 사이트 설치에서 내보내기 명령을 실행합니다. 즉, 내보낼 하위 사이트를 지정하는 방법이 필요합니다. 그렇게 하려면 --blog_id 매개변수를 내보내기 명령에 전달하기만 하면 됩니다.

 $ wp mu-migration export all subsite-3.zip --themes --plugins --uploads --blog_id=3

이 예에서는 ID가 3인 하위 사이트를 내보내고 있습니다. 이렇게 하면 다른 다중 사이트 또는 단일 사이트로 가져올 준비가 된 ZIP 파일이 생성됩니다. 단일 사이트와 다중 사이트로 가져오기 위한 명령은 정확히 동일합니다. MU-Migration은 다중 사이트에서 실행 중인지 여부를 감지하고 자동으로 조정합니다. 참고로, 다른 다중 사이트 인스턴스로 가져올 때 --blog_id 매개변수를 지정하여 기존 하위 사이트를 재정의할 수도 있습니다.

 $ wp mu-migration import all /path/to/subsite-3.zip [--new_url= ] [--blog_id= ] $ wp mu-migration import all /path/to/subsite-3.zip [--new_url= ] [--blog_id= ] $ wp mu-migration import all /path/to/subsite-3.zip [--new_url= ] [--blog_id= ]

대규모 마이그레이션 실행을 위한 팁

앞의 예는 중소 규모의 마이그레이션에 매우 적합하지만 대규모 사이트를 다중 사이트로 또는 다중 사이트에서 마이그레이션하는 경우 상당한 시간이 걸릴 수 있습니다. 이 섹션에서는 여러 엔터프라이즈급 마이그레이션을 수행하면서 배운 몇 가지 교훈을 공유하겠습니다.

마이그레이션 계획 생성

데이터 마이그레이션은 종종 필요하지만 많은 프로젝트에서 간과되는 부분입니다. 마이그레이션은 번거롭고 복잡할 수 있지만 적절하게 계획하면 고통이 없을 수 있습니다. 마이그레이션 계획을 만드는 것은 모든 마이그레이션 프로젝트의 첫 번째 단계여야 합니다.

일반적인 마이그레이션 계획에는 다음이 포함됩니다.

프로덕션 편집 프로세스에 대한 마이그레이션의 영향(즉, 콘텐츠 정지, 차등 마이그레이션 요구 사항).
마이그레이션은 얼마나 오래 실행될 것으로 예상됩니까?
백업은 어떻게 복원됩니까? 실패한 마이그레이션은 어떻게 처리됩니까?
내보내기 프로세스가 사이트 성능에 어떤 영향을 미칩니까? 많은 사이트는 피크 시간에 데이터베이스 내보내기를 감당할 수 없습니다.

일반적으로 마이그레이션은 가능한 한 원활하게 이루어져야 하며 이상적으로는 출시일에 모든 무거운 작업이 이미 완료되어 꼭 필요한 단계만 수행해야 합니다. 즉, 실수 및 QA를 수정할 수 있는 여지를 제공하므로 실제 출시 날짜 이전에 가능한 모든 것을 마이그레이션해야 합니다. 새 사이트 빌드이고 데이터를 마이그레이션하는 경우 콘텐츠 고정 창의 이점을 얻고 미리 콘텐츠를 이동할 수 있습니다. 가능한 경우 콘텐츠를 점진적으로 이동하는 전략을 사용할 수도 있습니다. 이 기술의 예는 다음 섹션을 확인하십시오.

여러 번 무시되지만 적절한 마이그레이션 계획은 마이그레이션과 관련된 다양한 문제를 피할 수 있습니다. 예기치 않은 상황으로 인해 마이그레이션이 실패하지 않도록 미리 계획하십시오! 마이그레이션 계획에 대한 보다 심층적인 논의는 10up 모범 사례의 마이그레이션 섹션을 확인하는 것이 좋습니다.

Rsync를 사용하여 업로드를 점진적으로 복사

대규모 사이트의 업로드 폴더는 매우 클 수 있으며 나중에 추출하기 위해 ZIP 파일로 압축하는 것이 항상 가장 빠르고 좋은 솔루션은 아닙니다. 업로드 폴더를 대상 서버에 복사하는 몇 가지 다른 방법이 있습니다. 엔터프라이즈급 마이그레이션에 일반적으로 사용되는 도구는 rsync 입니다. 이는 표준 SFTP 솔루션을 사용하는 것보다 더 빠르게 서버 간에 파일을 전송할 수 있으며 플러스로 전송을 일시 중지하고 복원할 수 있습니다. 이미 전송된 내용을 추적하므로 파일을 점진적으로 동기화할 수 있습니다. 예를 들어 실제 마이그레이션 며칠 전에 파일 동기화를 시작하여 시간을 벌 수 있습니다. 그런 다음 마이그레이션 당일에 마지막 동기화 이후 추가된 모든 항목이 대상 서버로 전송되도록 파일을 동기화하기만 하면 됩니다.

이 접근 방식의 유일한 주의 사항은 다중 사이트의 업로드 폴더 구조가 약간 다르기 때문에 수동으로 업로드의 하위 디렉토리를 올바른 위치로 이동해야 한다는 것입니다. .

마지막 예로 대규모 단일 사이트를 다중 사이트 인스턴스로 마이그레이션하는 방법을 살펴보겠습니다. 단일 사이트를 ZIP 패키지로 내보내고 대상 서버에서 모의 테스트를 실행하여 시작하겠습니다. 그 시점에서 도메인이 여전히 이전 서버를 가리키고 있기 때문에 사이트에 액세스할 수 없습니다. 즉, 마이그레이션을 테스트하기 위해 호스트의 파일을 새 서버로 안전하게 지정할 수 있습니다. 대상 사이트에서 사이트 액세스 제한과 같은 플러그인을 활성화하여 어떤 식으로든 공개적으로 액세스할 수 없도록 할 수도 있습니다.

테스트를 위해 우리는 계획된 마이그레이션 날짜 몇 일 또는 몇 주 전에 사이트를 내보내 테스트하고 프로세스가 얼마나 걸릴지 알 수 있습니다. 업로드 폴더는 포함되어 있지 않습니다.

먼저 테스트 실행

항상 먼저 드라이 런을 수행하십시오. 이상적으로는 실제 서버 또는 유사한 서버 스택이 있는 스테이징 환경에서 테스트 실행이 발생해야 합니다.

--mysql-single-transaction 플래그 사용 고려

가져오기 명령은 또한 SQL 내보내기를 단일 트랜잭션으로 래핑하여 가져오기의 모든 변경 사항을 한 번에 커밋하는 --mysql-single-transaction 플래그를 지원하여 특히 클러스터된 MySQL 환경에서 쓰기 작업이 데이터베이스 서버를 압도하는 것을 방지합니다.

 $ cd /path/to/wordpress $ wp mu-migration export all site.zip --themes --plugins

rsync 를 사용하면 생성된 내보낸 파일을 쉽게 전송할 수 있습니다.

 $ rsync -aP site.zip [email protected]:/var/www/multisite/

그런 다음 대상 서버에서 가져오기 명령을 실행합니다.

 $ ssh [email protected] $ cd /var/www/multisite $ wp mu-migration import all site.zip

이제 새로 생성된 하위 사이트의 blog_id 가 무엇인지 알아야 합니다. 다음을 실행하여 해당 정보를 얻을 수 있습니다.

$ wp 사이트 목록
블로그 아이디	URL	마지막_업데이트	등기
1	https://멀티사이트.com/	2017-09-09 20:59:31	2016-11-23 21:59:34
2	https://siglesite.com/	2017-06-21 18:30:09	2017-04-25 13:07:46

위 명령의 출력에서 우리 사이트가 ID 2로 임포트되었음을 알 수 있습니다. rsync 를 사용하여 업로드 폴더를 올바르게 이동하려면 이 정보가 필요합니다. 단일 사이트 서버에서 다음을 실행합니다.

 $ rsync -azP wp-content/uploads/ [email protected]:/var/www/multisite/wp-content/uploads/sites/2/

위의 명령은 전체 업로드 폴더를 다중 사이트 설치의 올바른 위치에 복사합니다. 이 폴더는 사이트 폴더 아래에 있고 폴더 이름이 사이트의 ID일 뿐입니다(이 경우 2). 이 시점에서 단일 사이트 도메인이 다중 사이트 서버를 가리키도록 호스트 파일을 편집할 수 있습니다. 그런 다음 마이그레이션이 예상대로 작동하는지 확인하기 위해 몇 가지 테스트를 수행할 수 있습니다.

최종 마이그레이션의 경우 --blog_id=2 를 import 명령에 전달하는 것을 제외하고 모든 것이 동일합니다.

 $ wp mu-migration import all site.zip --blog_id=2

그리고 이점으로 rsync 는 마지막 동기화 이후에 변경되거나 추가된 파일만 전송하기 때문에 업로드 동기화가 훨씬 더 빨라집니다.

결론

다중 사이트로 또는 다중 사이트에서 마이그레이션하는 것은 어려우며 이 기사에서 소개한 도구는 몇 가지 CLI 명령에 대한 노력을 줄여 전체 마이그레이션 프로세스를 단순화합니다. MU-Migration은 1년 이상 프로덕션에서 활발히 사용되었으며 완전히 오픈 소스 프로젝트입니다. 플러그인은 Github에서 개발되었으며 pull 요청을 환영합니다!