Background

싱계의 "서유기"에는 아주 유명한 대사가 있습니다. "한때 내 앞에는 소중히 여기지 않았던 진심 어린 인연이 있었다. 잃어버리고 나서야 후회할 뿐이었다. " 그리고 세상에서 가장 고통스러운 것은 이것이다. 만약 신이 나에게 또 한 번 기회를 준다면 나는 어떤 여자에게든 세 마디 말을 할 것이다. 사랑한다. 이 사랑에 시간 제한을 추가해야 한다면 1만 번은 좋겠다. 우리 개발자들의 눈에는 이 감정이 우리 데이터베이스의 데이터와 동일합니다. 우리는 그것이 10,000년 동안 변하지 않기를 바라지만, 회사가 계속 발전함에 따라 상황은 종종 역효과를 낳습니다. . 데이터에 대한 요구 사항도 지속적으로 변화하고 있으며 아마도 다음과 같은 상황이 있을 수 있습니다.

하위 데이터베이스 및 하위 테이블: 비즈니스 개발이 점점 더 빨라지고 있어 단일 시스템 데이터베이스에 대한 부담이 커지고 있습니다. 그리고 데이터의 양 현재 이 문제를 해결하기 위해 일반적으로 데이터베이스 분할 방법이 사용되며 데이터베이스 트래픽이 다른 시스템에 고르게 분산됩니다. 독립형 데이터베이스에서 하위 데이터베이스로 전환하는 과정에서 하위 데이터베이스의 데이터를 성공적으로 사용할 수 있도록 데이터를 완전히 마이그레이션해야 합니다.
저장 매체 교체: 일반적으로 위에서 소개한 하위 데이터베이스를 마이그레이션한 후에도 저장 매체는 여전히 동일합니다. 예를 들어 이전에는 단일 머신 Mysql을 사용했지만 하위 데이터베이스 이후에는 여러 시스템에서 Mysql이 되며 데이터베이스 테이블의 필드는 변경되지 않았으며 마이그레이션이 비교적 간단합니다. 때때로 우리의 하위 데이터베이스와 테이블이 모든 문제를 해결할 수 없는 경우가 있습니다. 복잡한 쿼리가 많이 필요한 경우 현재로서는 MySQL을 사용하는 것이 안정적인 솔루션이 아닐 수 있습니다. 그러면 Elasticsearch를 사용하는 등의 쿼리 저장 매체를 교체해야 합니다. 마이그레이션 유형은 약간 더 복잡하며 다른 저장 매체의 데이터 변환이 포함됩니다.
새로운 시스템으로 전환: 일반적으로 회사가 빠른 속도로 발전할 때 속도를 위해 반복적으로 구축되는 프로젝트가 많이 있을 것입니다. 회사가 일정 기간에 도달하면 이러한 프로젝트는 일부 멤버십 시스템, 전자상거래 시스템 등과 같은 플랫폼 또는 중간 플랫폼으로 병합되어 전환되는 경우가 많습니다. 이때 기존 시스템의 데이터를 새 시스템으로 마이그레이션해야 하는 경우가 종종 있는데, 이때 저장 매체뿐만 아니라 프로젝트도 변경되었을 가능성이 있습니다. 언어가 다를 수 있습니다. 상위 수준에서 보면 부서가 다를 수 있으므로 이러한 종류의 데이터 마이그레이션은 더 어렵고 위험도 더 큽니다.

실제 비즈니스 개발에서는 상황에 따라 다양한 마이그레이션 계획을 세워보겠습니다. 다음으로 데이터 마이그레이션 방법에 대해 논의하겠습니다.

데이터 마이그레이션

사실 데이터 마이그레이션은 하루아침에 이루어지지 않습니다. 모든 데이터 마이그레이션은 일주일이 걸릴 수도 있고 몇 달이 걸릴 수도 있습니다. 일반적으로 데이터 마이그레이션 프로세스는 기본적으로 아래 그림과 유사합니다. :' 먼저 데이터베이스의 기존 데이터를 일괄 마이그레이션한 다음 새 데이터를 처리해야 하며, 원본 데이터베이스를 작성한 후 이 데이터를 실시간으로 새 스토리지에 써야 합니다. 그 과정에서. 기본적인 문제가 심각하지 않은 것으로 확인되면 스트림 절단 작업을 수행하게 되며, 스트림이 완전히 절단된 후에는 더 이상 데이터 확인 및 증분 데이터 마이그레이션을 수행할 필요가 없습니다.

기존 데이터 마이그레이션

우선 기존 데이터 마이그레이션 방법에 대해 이야기해보겠습니다. 오픈소스 커뮤니티에서 기존 데이터 마이그레이션을 검색한 결과 현재 Alibaba Cloud의 DTS에는 사용하기 쉬운 도구가 없습니다. 기존 데이터 마이그레이션을 제공하는 DTS는 서로 다른 동종 및 이기종 데이터 소스 간의 마이그레이션을 지원하며 기본적으로 Mysql, Orcale, SQL Server 등 업계 공통 데이터베이스를 지원합니다. DTS는 앞서 언급한 처음 두 가지 시나리오에 더 적합합니다. 하나는 Alibaba Cloud의 DRDS를 사용하는 경우 DTS를 통해 데이터를 DRDS로 직접 마이그레이션할 수 있는 시나리오입니다. Redis, ES, DTS 등 모두 직접 마이그레이션을 지원합니다.

그럼 DTS 재고를 마이그레이션하는 방법은 무엇입니까? 실제로는 비교적 간단하며 아마도 다음 단계일 것입니다.

재고 마이그레이션 작업이 시작되면 현재 마이그레이션해야 하는 가장 큰 ID와 가장 작은 ID를 가져옵니다.
10,000과 같은 세그먼트를 설정하고, 매번 가장 작은 ID부터 시작하여 10,000개의 데이터를 DTS 서버에 쿼리하고 DTS에 전달하여 처리합니다. SQL은 다음과 같습니다.

select * from table_name where id > curId and id < curId + 10000;复制代码

로그인 후 복사

3. id가 maxId보다 크거나 같으면 기존 데이터 마이그레이션 작업이 종료됩니다

물론 실제 마이그레이션 과정에서 Alibaba Cloud를 사용하지 않을 수도 있고, 세 번째 시나리오에서는 데이터베이스 필드 간에 많은 변환을 수행해야 하는데 DTS가 이를 지원하지 않는 경우 DTS를 모방할 수 있습니다. 세그먼트 단위로 데이터를 읽어서 데이터를 마이그레이션합니다. 여기서 주목해야 할 점은 데이터를 일괄 마이그레이션할 때 온라인 작업의 정상적인 작동에 영향을 미치지 않도록 세그먼트의 크기와 빈도를 제어해야 한다는 것입니다.

증분 데이터 마이그레이션

기존 데이터에 대한 마이그레이션 솔루션은 상대적으로 제한적이지만 증분 데이터 마이그레이션 방법은 일반적으로 다음과 같은 방법이 있습니다.

DTS: Alibaba Cloud의 DTS는 원스톱 서비스입니다. 기존 데이터 마이그레이션은 물론 증분 데이터 마이그레이션도 제공하지만, 용량에 따라 과금만 하면 된다.
서비스 이중 쓰기: 시스템이 전환되지 않은 마이그레이션, 즉 스토리지만 변경되었지만 시스템은 그대로인 하위 데이터베이스, 하위 테이블, Redis 데이터 동기화 등 마이그레이션에 더 적합합니다. 이 방법은 비교적 간단하고 코드에서 직접 동기화할 수 있지만, 동일한 데이터베이스가 아니기 때문에 트랜잭션을 보장할 수 없으며 이로 인해 데이터를 마이그레이션할 때 데이터 손실이 발생할 수 있습니다. 이 과정은 후속 데이터 검증을 통해 해결될 예정입니다.
MQ 비동기 쓰기: 모든 시나리오에 적용할 수 있습니다. 데이터가 수정되면 MQ 메시지가 전송되고 소비자는 메시지를 받은 후 데이터를 업데이트합니다. 이는 위의 double write와 다소 유사하지만 데이터베이스 작업을 MQ 비동기식으로 변경하므로 문제가 발생할 가능성이 훨씬 작아집니다
binlog 모니터링: 앞서 언급한 운하나 데이터버스 등 다른 오픈 소스를 사용할 수 있습니다. binlog 모니터링 binlog 모니터링 방법은 메시지를 보내는 단계를 생략한 점만 제외하면 위의 메시지 MQ 방법과 동일합니다. 이 방법의 개발량은 기본적으로 최소화됩니다.

방법이 이렇게 많은데 어떤 방법을 사용해야 할까요? 개인적으로 binlog를 모니터링하는 방법을 추천하는데, binlog를 모니터링하면 개발 비용이 절감되고, 소비자 로직만 구현하면 되고, 모니터링되는 binlog이기 때문에 이전에 이중으로 기록될 염려가 없습니다. 다른.비즈니스 문제.

데이터 검증

위에서 언급한 모든 솔루션의 경우 대부분 성숙한 클라우드 서비스(dts) 또는 미들웨어(canal)이지만 일부 데이터 손실이 발생할 가능성이 있으며 여전히 전체 데이터 손실이 발생합니다. 비교적 드문 일이지만 문제 해결이 매우 어렵습니다. 실수로 dts나 운하가 흔들리거나 데이터를 수신할 때 실수로 손실될 수도 있습니다. 마이그레이션 프로세스 중에 데이터가 손실되는 것을 방지할 수 있는 방법이 없으므로 다른 방법으로 데이터를 수정해야 합니다.

일반적으로 데이터를 마이그레이션할 때 데이터 확인 단계가 있지만 팀마다 다른 데이터 확인 방식을 선택할 수 있습니다.

제가 이전에 Meituan에 있었을 때 우리는 이중 읽기를 했습니다. 모든 읽기 작업은 새 항목의 복사본을 읽지만 반환된 데이터는 여전히 오래된 것입니다. 문제가 있는 경우 수동 수리 또는 자동에 대한 경보를 발행할 수 있습니다. 수리하다. 이런 방식으로 우리가 일반적으로 사용하는 데이터를 신속하게 복구할 수 있습니다. 물론 전체 데이터 검사도 수시로 실행하지만 이러한 종류의 데이터 복구 확인 시간은 상대적으로 지연됩니다.
원부도 이후에는 이전 방법을 채택하지 않습니다. 왜냐하면 이중 읽기 검사를 통해 데이터의 오류를 빠르게 찾을 수 있지만 이 부분에 대한 실시간 검증 및 이중 읽기 수준이 그렇게 높지 않기 때문입니다. 코드 개발의 양은 여전히 상대적으로 많지만 때때로 전체 확인을 통해 보장할 수 없으므로 데이터 확인 시간이 매우 길어집니다. 화해는 T+1의 아이디어를 빌려 매일 이른 아침 기존 데이터베이스에서 업데이트된 데이터를 하나씩 가져와서 새 데이터베이스의 데이터와 비교하는 방식을 채택했습니다. 데이터가 다르거나 누락된 경우 즉시 복구할 수 있습니다.

물론 실제 개발 과정에서는 다음 사항에도 주의를 기울여야 합니다.

데이터 검증 작업의 정확성을 보장하는 방법은 무엇입니까? 검증 작업은 원래 다른 데이터를 수정하는 것이지만, 자체적으로 문제가 있으면 검증의 의미를 잃게 됩니다. 코드를 검토하여 검증 작업의 정확성을 보장하는 방법입니다.
작업을 확인할 때 로그 인쇄에 주의해야 합니다. 때로는 모든 데이터에 직접적인 문제가 발생하여 문제가 발생할 수 있습니다. 그러면 확인 작업에서 많은 수의 오류 로그가 인쇄되고 이로 인해 알람이 발생할 수 있습니다. 시스템이 중단되거나 다른 사람의 서비스에 영향을 미칩니다. 여기서 더 간단하게 만들고 싶다면 수동으로 처리되지 않은 일부 알람을 경고로 전환할 수 있습니다. 더 복잡하게 만들고 싶다면 특정 오류 인쇄가 특정 기간에 일정량을 초과하는 경우 도구를 캡슐화할 수 있습니다. 시간이 지나면 다시 인쇄할 필요가 없습니다.
검증 작업의 온라인 실행 서비스에 영향을 주지 않도록 주의하세요. 일반적으로 검증 작업은 배치 쿼리문을 많이 작성하게 되며, 코드가 제대로 작성되지 않으면 배치 테이블 스캐닝이 발생하기 쉽습니다. 정지할 데이터베이스.

스트림 커팅

데이터 검증에 기본적으로 오류가 없다는 것은 마이그레이션 프로그램이 비교적 안정적이라는 의미인데, 그러면 새 데이터를 직접 사용할 수 있나요? 물론 불가능합니다. 한꺼번에 전환하면 잘 되면 좋겠지만, 문제가 생기면 모든 사용자에게 영향을 미치게 됩니다.

다음으로 스트림 커팅인 그레이스케일을 수행해야 합니다. 다양한 비즈니스 흐름 컷의 차원은 다릅니다. 사용자 차원 흐름 컷의 경우 일반적으로 userId의 모듈로 방법을 사용하여 흐름을 컷합니다. 테넌트 또는 판매자 차원 비즈니스의 경우 흐름을 컷하는 방식으로 테넌트 ID를 모듈로해야 합니다. 이러한 트래픽 차단을 위해서는 트래픽 차단 계획을 세워야 하며, 어느 기간에, 얼마나 많은 트래픽을 해제할지, 트래픽을 차단할 때는 트래픽이 상대적으로 적은 시간을 선택해야 합니다. 로그를 자세히 관찰하여 가능한 한 빨리 문제를 해결합니다. 트래픽을 해제하는 과정은 느린 것부터 빠른 것까지 진행됩니다. 예를 들어 처음에는 1%로 계속 중첩됩니다. % 또는 20%로 빠르게 볼륨을 높이세요. 문제가 있으면 트래픽이 적을 때 발견되는 경우가 많기 때문에 트래픽이 적더라도 문제가 없으면 볼륨을 빠르게 늘릴 수 있습니다.

기본 키 ID에 주의하세요

데이터를 마이그레이션하는 과정에서 기본 키 ID에 특히 주의해야 합니다. 위의 이중 쓰기 솔루션에서는 기본 키 ID가 이중이어야 한다고 언급되어 있습니다. -ID 생성 순서가 틀리지 않도록 수동으로 작성하고 지정합니다.

샤딩 데이터베이스와 테이블 때문에 마이그레이션하는 경우 향후 기본 키 ID는 자동 증가 ID가 될 수 없다는 점을 고려해야 하며 여기서 더 권장되는 것은 Meituan의 오픈 소스 리프입니다. 두 가지 유형을 지원하는 첫 번째 모드는 증가 추세에 있는 눈송이 알고리즘이지만 모든 ID는 Long 유형이므로 Long을 ID로 지원하는 일부 애플리케이션에 적합합니다. 설정한 기본 ID를 기준으로 위에서부터 계속해서 증가하는 숫자 세그먼트 모드도 있습니다. 그리고 기본적으로 메모리 생성을 사용하며 성능도 매우 빠릅니다.

물론 여전히 시스템을 마이그레이션해야 하는 상황이 있습니다. 이전 시스템의 기본 키 ID가 이미 새 시스템에 존재하므로 ID를 매핑해야 합니다. 시스템을 마이그레이션할 때 앞으로 어떤 시스템이 마이그레이션될지 이미 알고 있다면 예약 방법을 사용할 수 있습니다. 예를 들어 시스템 A의 현재 데이터는 1억~1억이고, 시스템 B의 데이터도 1억입니다. 이제 두 시스템 A와 B를 새로운 시스템으로 병합해야 합니다. 그러면 일부 버퍼를 약간 추정할 수 있습니다. 예를 들어 시스템 A에 1억~1억 5천만을 남겨두면 A를 매핑할 필요가 없습니다. , 시스템 B는 1억 5천만에서 3억입니다. 그런 다음 이전 시스템 ID로 변환하면 1억 5천만을 빼야 합니다. 마지막으로 새 시스템의 새 ID는 3억에서 증가합니다. 하지만 시스템에 계획된 예약 세그먼트가 없다면 어떻게 될까요? 다음 두 가지 방법으로 이를 수행할 수 있습니다:

새 테이블을 추가하고 기존 시스템의 ID와 새 시스템의 ID 사이에 매핑 레코드를 만들어야 합니다. 일반적인 마이그레이션에는 수십 또는 수백 개의 테이블이 포함되고 비용이 많이 들기 때문에 이 작업량은 여전히 상대적으로 큽니다. 기록률은 여전히 높다.
id가 Long 유형인 경우 long이 64비트라는 사실을 잘 활용할 수 있습니다. 새 시스템의 ID는 숫자로 시작하는 것과 같이 비교적 큰 숫자로 시작됩니다. 작은 Int의 일부는 ID 마이그레이션을 위해 기존 시스템에 남겨둘 수 있습니다. 예를 들어 우리 위의 1억 5천만 데이터 볼륨은 실제로 28비트만 사용하므로 여전히 4개가 있습니다. 물론, 계획에 마이그레이션할 시스템이 더 많은 경우 새 시스템의 ID 시작점을 더 크게 설정할 수 있습니다. 아래 그림과 같이

요약

마지막으로 이 루틴을 간단히 요약해 보겠습니다. 실제로는 4단계로 이루어집니다. 즉, 재고, 증분, 흐름 차단, 마지막으로 ID에 주의하세요. 데이터의 양이 아무리 많아도 이 루틴에 따라 마이그레이션하면 기본적으로 큰 문제가 없습니다. 이 기사가 귀하의 후속 데이터 마이그레이션 작업에 도움이 되기를 바랍니다.