MySQL 데이터를 Elasticsearch에 동기화하는 방법은 무엇입니까?

1. 비즈니스 계층 동기화

MySQL 데이터의 작업도 비즈니스 계층에서 완료되므로 비즈니스 계층에서 다른 데이터 소스를 동기화하는 것이 당연합니다. 보다 일반적인 접근 방식은 ORM의 후크 후크에 관련 동기화를 작성하는 것입니다. 암호.

이 접근 방식의 단점은 서비스가 많아지면 동기화된 부분이 너무 분산되어 업데이트 및 반복이 어려울 수 있다는 것입니다. 예를 들어 ES 인덱스의 호환되지 않는 마이그레이션은 전체 시스템에 영향을 미칠 수 있습니다.

2. 미들웨어 동기화

애플리케이션 아키텍처가 마이크로서비스로 진화하면 각 서비스는 더 이상 MySQL을 직접 호출할 수 없지만, 이때 미들웨어는 다른 데이터 소스를 동기화하면서 MySQL을 작동할 수 있습니다.

이 방법은 미들웨어가 적응해야 하며 어느 정도 복잡합니다.

3. 예약된 작업은 update_at 필드를 기반으로 동기화됩니다.

update_at(데이터 업데이트 시간)과 같은 MySQL 테이블 구조의 특수 필드를 설정하면 예약된 작업이 실제 변경된 데이터를 쿼리하여 데이터를 실현합니다. 업데이트 증분 업데이트.

오픈 소스 Logstash를 사용하여 이 방법을 완료할 수 있습니다.

물론 단점도 분명합니다. 즉, 데이터 삭제를 동기화할 수 없다는 것입니다.

4. binlog 동기화 분석

예를 들어 유명한 운하.

데이터 변경 사항을 알아보기 위해 MySQL의 바이너리 로그를 구문 분석하기 위해 슬레이브로 변장합니다.

이것은 업계에서 비교적 성숙한 솔루션입니다.

이 방법을 사용하려면 MySQL의 binlog-format을 ROW 모드로 설정해야 합니다. binlog-format 设置为 ROW 模式。

5. 解析 binlog — mixed / statement 格式

MySQL 的 binlog 有三种格式：

• ROW 模式，binlog 按行的方式去记录数据的变更；

• statement 模式，binlog 记录的是 SQL 语句；

• mixed 模式时，混合以上两种，记录的可能是 SQL 语句或者 ROW 模式的每行变更；

某些情况下，可能你的 MySQL binlog 无法被设置为 ROW 模式，这种时候，我们仍然可以去统一解析 binlog ，从而完成同步，但是这里解析出来的当然还是原始的 SQL 语句或者 ROW

5. binlog 구문 분석 — 혼합/문 형식

MySQL의 binlog에는 세 가지 형식이 있습니다:

ROW 모드, binlog는 데이터 변경 사항을 행에 기록합니다. 🎜

• statement 모드, binlog는 SQL 문입니다. 🎜

• mixed 모드에서는 위의 두 가지가 혼합되어 기록되는 내용이 SQL 문일 수도 있고 ROW 모드의 각 행일 수도 있습니다. 🎜

🎜어떤 경우에는 MySQL binlog가 ROW 모드로 설정되지 않을 수 있습니다. 동기화를 완료하려면 binlog를 균일하게 구문 분석해야 하지만 여기서 구문 분석되는 것은 물론 원본 SQL 문이거나 ROW 패턴의 각 행 변경 사항입니다. 이때 이러한 SQL 또는 각 행을 그에 따라 구문 분석해야 합니다. 정규 매칭이나 AST 추상 구문 트리 등을 사용하여 비즈니스 변경 사항을 적용한 후 구문 분석 결과를 기반으로 데이터를 동기화합니다. 🎜🎜이 방법의 한계도 분명합니다. 첫째, 비즈니스 분석 SQL을 조정해야 합니다. 둘째, 일괄 업데이트 시나리오는 물론 기본 키를 기반으로 데이터를 수정하거나 삭제하는 경우에는 처리하기 어려울 수 있습니다. 더 잘 적용할 수 있습니다. 🎜

위 내용은 MySQL 데이터를 Elasticsearch에 동기화하는 방법은 무엇입니까?의 상세 내용입니다. 자세한 내용은 PHP 중국어 웹사이트의 기타 관련 기사를 참조하세요!