Kafka Troubleshooting

• snapshot.mode : schema_only_recovery

간혹 debezium으로 테스트를 진행 중에 테스트를 위해 docker로 실행시킨 MySQL을 stop 후 다시 start를 하면 connector가 정상적으로 싱행이 되지 않을 때가 있었다.

 

정상적으로 connector가 실행되지 않을 때 처음으로 발생하는 에러는 MySQL에 접근하는 계정에 권한이 없다고 하는 에러였다.

저는 MySQL8 이상을 사용하고 있어 아래와 같이 명령어를 통해 권한을 주었다. (MySQL 5.7 이하는 identified를 통해 가능.)

GRANT ALL PRIVILEGES ON {DB명}.* TO {계정 ID}@'%' WITH GRANT OPTION; // 권한 부여
FLUSH PRIVILEGES; // 권한 갱신

그 후에도 connector가 정상적으로 실행되지 않아 다시 에러 로그 확인 결과 아래의 에러 메시지를 확인할 수 있었다. 

The db history topic is missing. You may attempt to recover it by reconfiguring the connector to SCHEMA_ONLY_RECOVERY

에러 로그 및 구글링을 해봤을 때 schema를 계속 감지하다가 topic의 데이터가 꼬여 정상적으로 connector가 RUNNING되지 못해 발생한 에러로 예상됩니다.

 

또한 kafka /log 디렉토리에 있는 controller.log 확인 시 아래와 같은 DEBUG 레벨 로그를 확인할 수 있었다.

Delete topic callback invoked on StopReplica response received from broker

 

 

원인 파악을 위해 debezium 공식 문서에서 schema_only_recovery를 찾아보니 connector를 실행시킬 때 body에 "snapshot.mode": "schema_only_recovery"를 추가 후 connector를 실행시키면 복구가 된다고 한다.

하지만 해당 옵션을 사용하여 connector를 실행시키면 주기적으로 topic에 쌓인 데이터의 정리가 되지만, topic에 적재된 데이터는 영원히 보존되어야한다고 써있는 부분을 보면 권고하는 사항은 아닌것으로 확인된다. (복구 후 connector의 삭제 / 실행이 필요할 것으로 보임.)

• snapshot.mode
  • schema_only_recovery : 이미 변경 사항을 캡처한 connector에 대한 복구를 하기 위한 옵션으로 해당 옵션을 추가하여 connector를 다시 시작하면 시작할 때 손상된 기록을 복구할 수 있다. 또한 해당 옵션은 통해 주기적으로 topic에 적재된 데이터의 청소가 가능하다고 되어있으나, topic의 기록은 영원히 보존이 되어야 한다.

 

 

https://debezium.io/documentation/reference/1.8/connectors/mysql.html 참고