문제
데이터 마이그레이션, 동기화 또는 구독 작업을 만들 때 원본 또는 타깃 데이터베이스 연결 테스트가 실패합니다.
가능한 원인
Telnet 테스트가 실패하는 경우 원인은 다음과 같습니다.
Telnet 테스트는 통과했지만 데이터베이스 연결에 실패하는 경우 원인은 다음과 같습니다.
원본 데이터베이스의 네트워크 또는 서버에 구성된 보안 그룹 또는 방화벽
보안 그룹은 방화벽과 유사합니다. 클라우드의 데이터베이스에 대한 네트워크 보안 설정 그룹입니다.
실제 조건에 따라 다음과 같이 확인하십시오.
원본 데이터베이스가 자체 구축된 데이터베이스인 경우 원본 데이터베이스가 있는 서버에 방화벽 정책이 설정되어 있는지 확인하고 방화벽 정책이 설정되어 있으면 방화벽을 비활성화합니다.
Windows: 제어판을 열고 Windows Defender 방화벽을 찾아 방화벽 정책이 구성되어 있는지 확인합니다.
Linux: ‘iptables -L’ 명령을 실행하여 서버가 방화벽 정책으로 구성되었는지 확인합니다.
원본 데이터베이스가 TencentDB 데이터베이스인 경우 해당 데이터베이스의 보안 그룹에서 DTS IP 범위가 차단되어 있는지 확인하고 차단된 경우 다음과 같이 수정합니다.
연결 테스트가 실패하면 DTS에 대해 허용해야 하는 IP 범위가 아래와 같이 콘솔에 표시됩니다.
1. 원본 데이터베이스(예시: MySQL)에 로그인하고 인스턴스 목록에서 인스턴스 ID를 클릭하여 인스턴스 관리 페이지로 들어갑니다.
2. 인스턴스 관리 페이지에서 보안 그룹 탭을 선택하고 DTS의 SNAT IP 범위를 차단하는 정책이 있는지 확인합니다.
3. DTS IP 범위 정책을 허용으로 설정합니다.
원본 데이터베이스가 3rd party 클라우드 데이터베이스인 경우 보안 그룹 설정을 확인하십시오.
확인 방법
MySQL 확인 방법
원본 데이터베이스가 배포된 서버에서 데이터 마이그레이션 작업에서 입력한 데이터베이스 계정과 암호를 사용하여 원본 데이터베이스에 연결합니다. 데이터베이스가 정상적으로 연결될 수 있는 경우 원본 데이터베이스에서 원본 IP 주소가 차단될 수 있습니다.
자체 구축된 데이터베이스의 경우 데이터베이스의 bind-address 구성을 확인해야 합니다. 0.0.0.0이 아니면 해당 IP가 차단됩니다.
원본 데이터베이스가 MySQL인 경우 MySQL 클라이언트를 사용하여 연결하고 다음 SQL 문을 실행하고 인증된 IP 주소 목록에 출력 결과에 DTS의 SNAT IP 주소가 포함되어 있는지 확인할 수 있습니다.
사용자에게 데이터베이스 권한을 부여할 때 승인된 IP에는 SNAT IP가 포함되어야 합니다. 그렇지 않으면 차단될 수 있습니다. 예를 들어:
root@10.0.0.0/8 //10.0.0.0/8을 통해 사용자에게 액세스 권한을 부여하면 다른 IP는 차단됩니다(잘못된 구성).
root@% //사용자에게 SNAT IP를 포함해야 하는 모든 IP에 액세스할 수 있는 권한 부여(올바른 구성)
다음과 같이 확인할 수 있습니다.
select host,user,authentication_string,password_expired,account_locked from
mysql.user WHERE user='[\\$Username]'; //[\\$Username]은 데이터 마이그레이션 작업에 입력한 데이터베이스 계정입니다.
SQL Server 확인 방법
원본 데이터베이스에 액세스 원본 IP 주소를 차단하는 Endpoint 또는 Trigger가 있는지 확인합니다.
PostgreSQL 확인 방법
원본 데이터베이스가 클라우드의 다른 데이터베이스인 경우 원본 데이터베이스의 보안 액세스 정책에 제한이 있는지 확인합니다. 개별 클라우드 공급업체에 따라 다음을 확인하십시오.
원본 데이터베이스가 자체 구축한 PostgreSQL 데이터베이스인 경우 $PGDATA 디렉터리에 data 디렉터리를 입력하고 ‘pg_hba.conf’ 파일을 찾은 다음 파일에 deny 정책이 포함되어 있는지 또는 네트워크를 통해 특정 IP 주소에서만 액세스를 허용하는지 확인합니다.
local replication all trust
host replication all 127.x.x.1/32 trust
host replication all ::1/128 trust
host all all 0.0.0.0/0 md5
host all all 172.x.x.0/20 md5
MongoDB/Redis 확인 방법
자체 구축된 데이터베이스의 경우 데이터베이스의 bind 구성을 확인해야 합니다. 0.0.0.0이 아니면 해당 IP가 차단됩니다.
수정 방법
1. 원본 데이터베이스가 MySQL인 경우 다음 SQL 문을 실행하여 데이터 마이그레이션 작업에 구성된 사용자에게 권한을 부여합니다.
mysql> grant all privileges on . to '[\\$UserName]'@'%'; //[\\$Username]은 데이터 마이그레이션 작업에 입력한 데이터베이스 계정입니다.
mysql> flush privileges;
2. 원본 데이터베이스가 자체 구축한 데이터베이스인 경우 bind-address 구성이 비정상인지도 확인해야 하며, 그렇다면 아래 지침에 따라 수정합니다.
2.1. ‘/etc/my.cnf’ 파일에 다음 내용을 추가합니다.
설명:
my.cnf 구성 파일의 기본 경로는 /etc/my.cnf입니다. 실제 조건에 따라 입력합니다.
2.2. 데이터베이스를 다시 시작합니다.
2.3. 설정이 적용되는지 확인합니다.
3. 확인 작업을 다시 실행합니다.
SQL Server 수정 방법
방화벽 또는 trigger를 비활성화합니다.
PostgreSQL 수정 방법
1. DTS IP 대역을 허용하는 액세스 정책을 ‘pg_hba.conf’ 파일에 추가하거나 마이그레이션 중에 액세스 정책의 모든 IP 범위를 일시적으로 엽니다. 예를 들어 pg_hba.conf 파일에 다음 라인을 추가합니다.
host all all 0.0.0.0/0 md5
2. 수정이 완료되면 데이터베이스를 다시 시작하여 설정을 적용할 수 있습니다.
pg_ctl -D $PGDATA restart
3. 확인 작업을 다시 실행합니다.
MongoDB 수정 방법
MySQL의 지시에 따라 bind-address를 설정합니다. Redis 수정 방법
1. redis.conf에서 bind 구성을 비활성화하거나 0.0.0.0으로 변경합니다.
2. 데이터베이스를 재시작하여 구성을 적용하고 확인 작업을 다시 실행합니다.
다음은 공통 데이터베이스의 기본 포트입니다. 개방 여부를 확인해야 하며 그렇지 않은 경우 실제 조건에 따라 개방해야 합니다.
원본 데이터베이스가 SQL Server인 경우 파일 공유 서비스 포트 445를 동시에 열어야 합니다.
MySQL:3306
SQL Server:1433
PostgreSQL:5432
MongoDB:27017
Redis:6379
전용 회선 또는 VPN 또는 [CCN](https://www.tencentcloud.com/document/ product/571/42650) 액세스 방법은 문제 해결에 대한 설명서를 참고할 수 있습니다. 원본 데이터베이스에 로그인하여 계정과 비밀번호가 올바른지 확인합니다.
동일한 원본 및 대상 데이터베이스에 대해 ‘공중망’과 같은 액세스 유형을 선택하고 연결 확인을 통과하면 ‘DC(Direct Connect)’와 같은 다른 액세스 유형으로 전환할 수 없습니다. 그렇지 않으면 연결 확인 중에 오류가 보고됩니다.