작성
·
130
답변 2
0
답변 주셔서 감사합니다.
aws aurora mysql 로 작업하고 있으며, 이 문제가 aws msk connector 에서만 발생하는 것인지는 정확하지 않습니다. 다만 처음에는 잘되었다가 hisotry 테이블 교체로 발생한 이슈입니다.
위 사항으로 진행해도 같은 오류가 발생하더라고요..
다만, 새로운 schema.history.internal.kafka.topic 으로 지정된 topic에 로컬 환경에서 똑같이 생성한 history topic의 정보를 넣어두고 실행해도 오류가 발생하는 것을 보입니다. 그렇다면 debezium connector는 binlog에 있는 정보만을 토대로 snapshot을 찍는거 같아 보이는데 맞을까요? 그렇다면 binlog의 ddl이 남아 있지 않으면 무조건 schema에 대한 에러가 발생하는걸까요?
추가로 다른 해결방법은 없는걸까요??
네 맞습니다. 새로운 history topic 명을 사용하기 위하여 기존 hisotry 삭제 후 신규로 만들었습니다.
2. 로컬 환경의 구성한 history topic에 생성된 데이터를 aws msk connector에서 생성된 history topic으로 넣어서 시도해보았습니다.
말씀주신 방법으로 이행한 뒤 새로운 Event(dml) 발생 시 같은 문제(schema isn't known to this connector..)가 발생하였습니다.
현재 제가 찾은 해결법은 ddl 을 새롭게 발생시켜서 변경된 schema를 읽을 수 있도록하는 include.schema.changes 의 설정값을 이용하여 schema를 반영시켜 정상 수행하게끔 하였습니다.
몇가지만 질문 사항이 있어 남겨드립니다. 다시 한번 답변 남겨주시면 정말 감사드리겠습니다. (mysql debezium 에 관하여 질문입니다. )
1. schema_only( 2.7.ver 에서는 'no_data')를 진행하여도, 남겨진 초기부터 현재 binlog까지에서는 schema만 저장하고 현재 binlog 부터 data를 읽는것으로 이해하였는데 맞을까요?
2. connector 자체에서 snapshot으로 db schema 정보를 binlog로만 저장시키는 것으로 보이는데 맞을까요?
3. 위 사항이 맞다면 snapshot에 history topic이나 다른 방향으로 반영시킬 수는 없는 걸까요?
오, 해결이 되었다니, 다행이군요. 아래는 제 질문과 답변입니다.
말씀주신 방법으로 이행한 뒤 새로운 Event(dml) 발생 시 같은 문제(schema isn't known to this connector..)가 발생하였습니다.
=> snapshot.mode를 schema_only 로 했는데 여전히 같은 오류라는 말씀이신가요?
음..
snapshot.mode=schema_only면 initial data 로딩을 하지 않습니다. 그리고 initial data의 schema 변경 정보는 내부 schema history internal topic에 기록은 하지만 target DB에 반영하지 않습니다(근데 이게 안된다면 뭔가 제가 잘못 알고 있거나 버전업 이후 바뀌었을 수도 있겠군요 ^^;;). 이후에 connector가 기동된 이후의 binlog만 읽어 들여서 데이터와 스키마 변경을 모두 적용합니다.
아래는 질문의 답변입니다.
1. schema_only( 2.7.ver 에서는 'no_data')를 진행하여도, 남겨진 초기부터 현재 binlog까지에서는 schema만 저장하고 현재 binlog 부터 data를 읽는것으로 이해하였는데 맞을까요?
=> schema 변경 정보를 내부 schema history topic에 저장합니다(binlog가 중간에 이빨이 빠져 있지 않은 이상, 초기 binlog가 없다고 저장시 특별히 오류가 발생할 사항은 없어 보입니다만). 이후에는 connector 기동후의 binlog에서 data와 schema 변경 사항을 모두 반영합니다.
2. connector 자체에서 snapshot으로 db schema 정보를 binlog로만 저장시키는 것으로 보이는데 맞을까요?
=> 질문을 정확히 이해하지는 못했지만, binlog에서 schema 정보를 추출하는 것에 대한 질문이라면 네, 그렇습니다.
3. 위 사항이 맞다면 snapshot에 history topic이나 다른 방향으로 반영시킬 수는 없는 걸까요?
=> 이것 역시 질문을 잘 이해하지 못했습니다. schema 변경 정보는 binlog에서 추출해서 history topic에 저장됩니다.
마지막으로 제 생각으로는 history topic을 삭제하면서 생긴 문제라면, (물론 지금 문제가 해결되어서 그럴 필요는 없겠지만... ) consumer 및 connector와 관련된 모든 환경을 초기화 해본 뒤에 다시 테스트 해보면 어땠을 까 싶습니다.
0
안녕하십니까,
이게 AWS Aurora Mysql에 Debezium 적용시 이슈인지는 모르겠지만,
binlog에서 이전 DDL 이 없을 때 DDL 변경 작업이 수행된 binlog 기준만으로 Debezium이 DDL을 해석하지 못해서 나오는 오류인것도 같습니다.
저도 검색해보니 아래 URL에서 비슷한 오류의 해결방안을 제시하는 군요.
schema.history.internal.kafka.topic 으로 지정된 history topic은 삭제하고(이후에 자동으로 재 생성 됩니다)
connector 삭제 및 초기화 수행 후에, connector config의 schema_mode를 schema_recovery_only(debezium 2.0 기준)로 설정하라고 합니다.
해당 내용대로 함 적용해 보시지요.
감사합니다.
다만 처음에는 잘되었다가 hisotry 테이블 교체로 발생한 이슈입니다.
=> 교체를 어떻게 하신거죠? 삭제를 하시고, 새로 만드신건가요?
다만, 새로운 schema.history.internal.kafka.topic 으로 지정된 topic에 로컬 환경에서 똑같이 생성한 history topic의 정보를 넣어두고 실행해도 오류가 발생하는 것을 보입니다.
=> 로컬환경에서 똑같이 생성한 history의 정보를 넣어두었다는 것은 어떻게 진행을 하신건지요?
암튼 schema 쪽 관련해서 이슈가 있는 것 같으니, 다 해보셔도 안되는 거라면, 초기 데이터 snapshot.mode를 initial 로 하지 않고 schema_only로 해서 수동으로 초기 데이터를 타겟으로 넘긴뒤에 이후에 생성되는 데이터는 debezium으로 동기화 하는 방법이 있습니다.
이걸 적용하려면 소스 MySQL을 초기 데이터 로딩 동안에는 DML을 발생시키고 않는 상태를 유지해야 합니다(즉 사용자 접속을 허용하지 않아야 합니다)
소스 mysql을 정상적으로 shutdown/start 한 후 이행을 위한 사용자 외에는 다른 사용자가 들어와서 동기화 테이블을 수정하지 못하게 해야 합니다.
이후 target db가 mysql이라면 mysqldump로, 타 db라면 file로 export 해서 migration 시켜야 합니다.
초기 데이터가 다 migration 되었으면, connector의 config의 snapshot.mode=schema_only로 재 기동합니다.