접근 경로의 제약을 적어 둔다

여러 인스턴스에 흩어진 같은 이름의 데이터베이스를 하나로 합치는 작업이었다. 세 곳에서 각각 덤프를 떠서 모으면 되는 일인데 한 곳에서 계속 막혔다.

Open Table of contents

간헐 타임아웃과 우회

두 곳은 잘 됐고 한 곳에서만 원격 접속이 간헐적으로 끊겼다. 간단한 명령은 되는데 덤프처럼 오래 걸리는 작업이 자꾸 끊겼다.

다른 머신에서 해 보니 되는 것으로 보아 특정 클라이언트 환경에서만 나는 문제였다. 원인을 깊이 파지 않고 그 호스트의 작업은 전용 조회 도구로 바꿨는데 원격 접속을 안 거치니 타임아웃이 안 났다.

다른 인스턴스에서는 원격 접속이 되는데 복잡한 SQL을 넘길 때 깨졌다. 로컬 셸과 원격 셸과 데이터베이스 클라이언트 세 단계에서 인용이 한 번씩 해석되기 때문이다.

어디서 깨지는지 추적이 안 되고 조용히 깨져서 오염된 SQL이 다른 것을 실행할 위험도 있었다. 인라인 명령을 포기하고 스크립트로 짰는데 스크립트 안에서는 인용이 한 겹이고 파라미터 바인딩을 쓰면 이스케이프 문제 자체가 없다.

이 둘을 제약으로 기록했다. 이 호스트로의 원격 접속은 이 클라이언트 환경에서 간헐 타임아웃이 나므로 전용 조회 도구를 우선 쓰고 원격 경유 덤프는 안 한다는 것이 하나다.

다른 하나는 셸에서 복잡한 인용을 원격으로 전달하면 오염되므로 스크립트 파일로 작성해 실행한다는 것이다. 왜 그렇게 하는지를 같이 적지 않으면 다음 사람이 한 줄이면 될 것을 왜 스크립트로 하느냐며 되돌린다.

이 작업은 끝나지 않았고 그 호스트의 네 데이터베이스가 통합되지 않았다. 그래서 남은 것을 데이터베이스별 테이블 수까지 적었다.

미완료라고만 쓰면 무엇이 남았는지 알 수 없다. 테이블 수까지 적으면 다음 사람이 규모를 알고 나중에 대조도 할 수 있다.

간헐 타임아웃의 원인을 안 판 것이 맞았는지도 따져 봤다. 목적이 데이터 통합이지 네트워크 진단이 아니었고 우회가 되며 비용이 낮고 결과가 같으면 우회가 답이다.

다만 우회했다는 사실과 이유를 남겼는데 그래야 그 문제가 나중에 다른 데서 나올 때 연결된다. 원인 미규명이고 우회했다고 적는 것이 정직한 상태이고 해결했다고 적으면 안 된다.