콘텐츠로 이동
≡

Administrator

Developer

Tools

External Tools

3.사용법#

이 장에서는 Altibase의 소스 커넥터와 싱크 커넥터를 구동하고 종료하는 방법과 사용하는 방법에 대해 설명한다.

제약조건#

Altibase 커넥터는 Confluent JDBC Connector의 메시지 형식을 사용하기 때문에, 이와 관련된 Confluent JDBC Connector의 제약사항을 적용받는다. Confluent JDBC connector과 관련된 제약조건은 Confluent JDBC connector 공식 문서를 참고하기 바란다.

공통 제약조건#

  • 복제할 테이블에는 반드시 프라이머리 키가 존재해야 한다.
  • 트랜잭션을 지원하지 않는다.
  • DATE 타입은 confluent JDBC Connector 메시지 형식의 제한으로 인해 마이크로초 단위는 제외되고, 밀리초 단위까지만 전달된다.
  • INSERT구문과 UPDATE 구문의 메시지 형식이 동일하다.
  • INSERT 구문과 UPDATE 구문에서 생성되는 메시지 형식이 동일하여 싱크 커넥터에서 두 구문을 구분할 수 없다. 따라서 싱크 커넥터에 입력된 데이터에 대해 INSERT로 처리할지 또는 UPDATE로 처리할지를 insert.mode 설정을 통해 명시적으로 지정해야 한다.

Altibase 소스 커넥터의 제약조건#

  • Altibase 소스 커넥터는 소스 데이터베이스(Altibase 서버)와 동일한 버전을 사용해야 한다.

  • FLOAT 타입은 다른 데이터베이스 간 데이터 형식 차이로 인해, 데이터 전송 및 입력 시 문자열로 처리된다.

  • LOB 타입은 지원하지 않는다.

  • 소스 커넥터는 태스크(task) 수가 1개로만 설정된다. (tasks.max를 1이상으로 설정해도 1로만 동작한다.)

Altibase 싱크 커넥터의 제약조건#

  • 싱크 데이터베이스가 Altibase일 때 싱크 커넥터의 insert.mode의 값을 upsert로 설정할 경우 아래의 제약이 있다.

    • Altibase 의 COERCE_HOST_VAR_IN_SELECT_LIST_TO_VARCHAR 프로퍼티 값을 32000으로 변경해야 한다. 그렇지 않을 경우 오류가 발생할 수 있다. 이 경우 발생한 오류에 대한 해결방안은 부록 A.트러블슈팅 가이드을 확인한다. 이 프로퍼티를 수정할 경우, Altibase 서버를 재시작해야 한다.

    • Altibase 의 DEFAULT_DATE_FORMAT 프로퍼티 값을 ‘YYYY-MM-DD HH:MI:SS.SSSSSS’로 설정해야 한다. 그렇지 않을 경우, DATE 타입의 시간 정보가 누락될 수 있다. 이 프로퍼티를 수정할 경우, Altibase 서버를 재시작해야 한다

커넥터 구동#

Altibase 소스 커넥터 구동하기#

Altibase 소스 커넥터를 구동하기 위해서는 먼저 소스 데이터베이스(Altibase)에서 XLog 송신자를 생성한 다음 등록해야 한다.

1. Altibase 서버에서 XLog 송신자를 생성#

XLog 송신자를 생성하기 위한 SQL 구문은 'Log Analyzer User\'s Manual'의 XLog Sender를 위한 구문을 참고 한다.

  • 예시) XLog 송신자의 이름이 ALA이고, Kafka Connect의 서버 IP가 192.168.0.2, 192.168.0.3, 192.168.0.4 이고, 소스 커넥터의 포트가 21301인 경우 
CREATE REPLICATION ALA FOR ANALYSIS
        WITH ‘192.168.0.2’, 21301
             ‘192.168.0.3’, 21301
             ‘192.168.0.4’, 21301
        FROM SCOTT.TABLE1 TO SCOTT.TABLE1;

2. Kafka Connect REST API를 이용하여 소스 커넥터를 등록#

소스 커넥터의 이름과 프로퍼티를 전달하여 등록한다.

  • 예시) Kafka connect의 IP가 192.168.0.2 이고 소스 데이터베이스의 IP가 192.168.0.11, 이중화 포트 번호가 21300인 경우
$ curl -m 30 --location --request POST 'http://192.168.0.2:8083/connectors' \
--header 'Content-Type: application/json' \
--data '{
    “name”: “Altibase-source-connector”,
    “config”: {
        “connector.class” : “com.altibase.connect.AltibaseSourceConnector”,
        “ala.sender.ip” : “192.168.0.11”,
        “tasks.max” : “1”,
        “ala.receiver.port” : “21300”
    }
}'

3. XLog 송신자를 시작시킨다.#

iSQL> ALTER REPLICATION ALA START;

Altibase 싱크 커넥터 구동하기#

Altibase 싱크 커넥터는 KafKa Connect REST API를 이용하여 Altibase 싱크 커넥터를 등록하기만 하면 사용할 수 있다. 단, 싱크 커넥터를 구동하기 전에 싱크 데이터베이스(Altibase)가 실행 중인지 확인한 후 진행한다.

1. 싱크 데이터베이스(Altibase)가 실행 중인지 확인#

2. Kafka Connect REST API를 이용하여 싱크 커넥터를 등록#

싱크 커넥터의 이름과 프로퍼티를 전달하여 싱크 커넥터를 등록한다.

  • 예시) Kafka connect의 IP가 192.168.0.2, 싱크 데이터베이스 서버의 IP가 192.168.0.12, 이중화 포트가 21300, 데이터베이스 이름이 mydb인 경우
$ curl -m 30 --location --request POST 'http://192.168.0.2:8083/connectors' \
--header 'Content-Type: application/json' \
--data '{
    “name”: “Altibase-sink-connector”,
    “config”: {
        “connector.class” : “io.confluent.connect.jdbc.JdbcsinkConnector”,
        “tasks.max” : “1”,
        “connection.user” : “scott”,
        “connection.password” : “tiger”,
        “connection.url” : “jdbc:Altibase://192.168.0.12:21300/mydb”,
        “topics” : “TABLE1”,
        “insert.mode” : “upsert”,
        “delete.enabled” : “true”,
        “pk.mode” : “record_key”
    }
}'

커넥터 상태 확인#

Altibase 커넥터는 Kafka 에서 제공하는 REST API와 로그 메시지를 통해 상태를 확인할 수 있다. 이 API는 커넥터가 정상 작동 중인지, 실행 중인지, 실패했는지 등을 확인할 때 사용된다.

REST API를 통한 상태 확인 방법#

  • 예시) Kafka connect의 IP가 192.168.0.2 일 때, Altibase-source-connector의 상태를 확인하는 요청
$ curl -m 30 --location --request GET 'http://192.168.0.2:8083/connectors/Altibase-source-connector/status' 2>/dev/null | tail -n 1 | python3 -m json.tool 2>/dev/null | sed 's/\\n/\n/g' | sed 's/\\t/\t/g'

결과

{
    “name“: “Altibase-source-connector“,
    “connector“: {
        “state“: “RUNNING“,
        “worker_id“: “connect-1:8083“
    },
    “tasks“: [
        {
            “id“: 0,
            “state“: “RUNNING“,
            “worker_id“: “connect-1:8083“
        }
    ],
    “type“: “source“
}

커넥터 또는 태스크의 상태가 FAILED 인 경우는 어떠한 예외 상황이 발생했했는지를 trace 속성의 로그에서 확인할 수 있다. FAILED 상태에서 발생할 수 있는 예외 상황 및 해결 방안에 대해서는 부록 A를 참고하기 바란다.

아래는 싱크 커넥터에서 예외 상황이 발생했을 때의 connector 상태의 예시이다.

  • 예시) trace 속성에서 로그를 확인한다.
{
    “connector“: {
        “state“: “RUNNING“,
        “worker_id“: “WORKER_ID:WORKER_PORT“
    },
    “name“: “confluent-JDBC-sink-connector-Altibase“,
    “tasks“: [
        {
            “id“: 0,
            “state“: “FAILED“,
            “trace“: “org.apache.kafka.connect.errors.ConnectException: Exiting WorkerSinkTask due to unrecoverable exception.
        at org.apache.kafka.connect.runtime.WorkerSinkTask.deliverMessages(WorkerSinkTask.java:635)
        at org.apache.kafka.connect.runtime.WorkerSinkTask.poll(WorkerSinkTask.java:344)
        at org.apache.kafka.connect.runtime.WorkerSinkTask.iteration(WorkerSinkTask.java:246)
        at org.apache.kafka.connect.runtime.WorkerSinkTask.execute(WorkerSinkTask.java:215)
        at org.apache.kafka.connect.runtime.WorkerTask.doRun(WorkerTask.java:225)
        at org.apache.kafka.connect.runtime.WorkerTask.run(WorkerTask.java:280)
        at org.apache.kafka.connect.runtime.isolation.Plugins.lambda$withClassLoader$1(Plugins.java:237)
        at java.base/java.util.concurrent.Executors$RunnableAdapter.call(Unknown Source)
        at java.base/java.util.concurrent.FutureTask.run(Unknown Source)
        at java.base/java.util.concurrent.ThreadPoolExecutor.runWorker(Unknown Source)
        at java.base/java.util.concurrent.ThreadPoolExecutor$Worker.run(Unknown Source)
        at java.base/java.lang.Thread.run(Unknown Source)
Caused by: org.apache.kafka.connect.errors.ConnectException: java.sql.SQLException: Exception chain:
java.sql.SQLException: SQL syntax error
line 1: missing or invalid syntax
UPDATE \“T1\“ SET  WHERE \“I1\“ = ?
                 ^   ^
        at io.confluent.connect.jdbc.sink.JdbcSinkTask.put(JdbcSinkTask.java:132)
        at org.apache.kafka.connect.runtime.WorkerSinkTask.deliverMessages(WorkerSinkTask.java:605)
        ... 11 more
Caused by: java.sql.SQLException: Exception chain:
java.sql.SQLException: SQL syntax error
line 1: missing or invalid syntax
UPDATE \“T1\“ SET  WHERE \“I1\“ = ?
                 ^   ^
        at io.confluent.connect.jdbc.sink.JdbcSinkTask.getAllMessagesException(JdbcSinkTask.java:165)
        at io.confluent.connect.jdbc.sink.JdbcSinkTask.put(JdbcSinkTask.java:111)
        ... 12 more
“,
            “worker_id“: “ WORKER_ID:WORKER_PORT “
        }
    ],
    “type“: “sink“
}

로그를 통한 상태 확인 방법#

Altibase 커넥터에서 생성하는 로그는 Kafka Connect의 설정에 따라 출력이 되며, Kafka Connect 또는 다른 커넥터와 같이 stdout또는 로그 파일에 출력될 수 있다.

커넥터 종료#

소스 커넥터 종료하기#

Note

소스 커넥터를 종료할 때는, Altibase 서버의 XLog 송신자도 함께 중지 해야 한다. XLog 송신자를 종료하지 않고 소스 커넥터만 종료할 경우, XLog 송신자는 소스 커넥터와의 접속을 계속 시도하므로 주의한다.

STEP 1: XLog 송신자 종료#

ALTER REPLICATION ALA STOP;

STEP 2: 소스 커넥터 종료 요청#

$ curl -m 30 --location --request PUT 'http://192.168.0.2:8083/connectors/Altibase-source-connector/stop'

싱크 커넥터 종료하기#

싱크 커넥터 종료 요청#

$ curl -m 30 --location --request PUT 'http://192.168.0.2:8083/connectors/Altibase-sink-connector/stop'

커넥터 제거#

  • 예시) Kafka Connector의 IP가 IP가 192.168.0.2 일 때, Altibase-source-connector를 제거하는 경우
$ curl -m 30 --location --request DELETE 'http://192.168.0.2:8083/connectors/Altibase-source-connector'

커넥터 재시작#

커넥터를 재시작하는 것은 커넥터의 현재 상태에 따라 수행 방법이 다르다.

resume#

커넥터가 STOPPED 상태인 경우, resume 요청을 보내 다시 시작한다. 예시) Kafka Connector의 IP가 IP가 192.168.0.2 일 때, STOPPED 상태인 Altibase-source-connector를 재시작하는 경우

$ curl -m 30 --location --request PUT 'http://192.168.0.2:8083/connectors/Altibase-source-connector/resume' 2>/dev/null

restart#

커넥터가 FAILED 상태인 경우, restart 요청을 보내 다시 시작할 수 있다. 예시) Kafka Connector의 IP가 IP가 192.168.0.2 일 때, FAILED 상태인 Altibase-source-connector를 재시작하는 경우

$ curl -m 30 --location --request POST 'http://192.168.0.2:8083/connectors/Altibase-source-connector/restart?includeTasks=true' 2>/dev/null

기타 커넥터 상태에 대한 설명은 Confluent 공식문서- Kafka Connect 및 모니터링 과 Confluent 플랫폼용 Kafka Connect REST API를 참고한다.

커넥터 프로퍼티#

Altibase 커넥터에서 설정할 수 있는 프로퍼티를 설명한다. 각 프로퍼티는 커넥션 생성 시 또는 설정 변경시 JSON 형식으로 전달할 수 있으며, 명시적으로 지정하지 않은 경우 기본값이 적용된다.

커넥터 생성시 프로퍼티 설정#

커넥터를 신규로 등록할 때는 Kafka Connect REST API의 /connectors 엔드포인트에 프로퍼티를 포함하여 요청한다.

$ curl -m 30 --location --request POST 'http://192.168.0.11:8083/connectors' \
   --header 'Content-Type: application/json' \
   --data '{
     “name“: “Altibase-source-connector“,
     “config“: {
        “connector.class“ : “com.altibase.connect.AltibaseSourceConnector“,
        “ala.sender.ip“ : “192.168.0.21“,
        “tasks.max“ : “1“,
        “ala.receiver.port“ : “21300“
      }
    }'

커넥터 프로퍼티 변경#

이미 등록된 커넥터의 설정을 변경하려면 /connectors/{name}/config 엔드포인트로 전체 프로퍼티를 다시 전달해야 한다. 다음은 ala.xlog.pool.size를 10000으로 변경하는 예시이다.

$ curl -m 30 --location --request PUT 'http://192.168.0.11:8083/connectors/config' \
   --header 'Content-Type: application/json' \
   --data '{
     “connector.class“ : “com.altibase.connect.AltibaseSourceConnector“,
     “ala.sender.ip“ : “192.168.0.21“,
     “tasks.max“ : “1“,
     “ala.receiver.port“ : “21300“,
     “ala.xlog.pool.size”: “10000”
   }'

Note

커넥터 설정 변경시 일부 프로퍼티만 수정할 수 없으며, 변경될 프로퍼티를 포함하여 기존에 설정한 모든 프로퍼티를 함께 전달해야 한다. 전달되지 않은 프로퍼티의 값은 기본값으로 설정된다.

소스 커넥터 프로퍼티#

Altibase 의 소스 커넥터에서 지원하는 프로퍼티를 소개한다.

ala.sender.ip#

항목 설명
데이터 타입 String
기본값 127.0.0.1
설명 XLog 송신자의 IP 주소를 지정하는 프로퍼티이다. Altibase가 설치된 서버의 IP 주소 를 설정한다.

ala.sender.port#

항목 설명
데이터 타입 Int
기본값 0
범위 [0, 65535]
설명 Altibase 서버에 XLog 송신자를 시작한 다음 소스 커넥터를 구동할 때 XLog 송신자와 접속되는 방식을 지정한다.
- 0: XLog 송신자가 접속을 시도할 때까지 소스 커넥터가 대기한다.
- 1 이상: 명시된 포트번호로 소스 커넥터가 XLog와 직접 접속을 시도한다.

ala.receiver.port#

항목 설명
데이터 타입 Int
기본값 47146
범위 [1024, 65535]
설명 XLog 콜렉터가 XLog를 수신하기 위해 사용하는 포트 번호를 지정하는 프로퍼티 이다.

ala.handshake.timeout#

항목 설명
데이터 타입 Int
기본값(초) 600
범위 [1, 2147483647]
설명 XLog 콜렉터가 XLog를 수신하기 위해 사용하는 포트 번호를 지정하는 프로퍼티 이다.

ala.replication.name#

항목 설명
데이터 타입 String
기본값 ALA
설명 XLog 송신자의 이름을 지정하는 프로퍼티이다. 소스 커넥터를 구동할 때 생성한 XLog의 이름으로 설정한다.

ala.xlog.pool.size#

항목 설명
데이터 타입 Int
기본값 100000
범위 [1000, 2147483647]
설명 XLog 콜렉터가 할당할 수 있는 XLog의 개수이다.

Important

XLog 콜렉터에는 Altibase 서버의 트랜잭션이 커밋되기 전의 레코드 변경 작업 내용이 XLog로 각각 쌓인다. 만약, Altibase 서버에 발생하는 트랜잭션이 다수의 레코드를 변경시키는 경우에는 XLog 콜렉터가 할당할 수 있는 XLog가 부족하여 정상적으로 복제할 수 없다. 따라서, Altibase 서버의 트랜잭션 유형에 따라서 이 프로퍼티 값을 조정해야 한다. XLog 송신자를 통해 Sync 작업을 수행할 경우 ala.xlog.pool.size 값은 Altibase의 REPLICATION_SYNC_TUPLE_COUNT 프로퍼티 값보다 크게 설정해야 한다. 이 프로퍼티 값을 크게 설정할 경우 JVM 힙(Heap) 크기가 필요한 메모리에 비해 작게 설정되어 있으면 Out Of Memory 오류가 발생할 수 있다. 따라서 Kafka Connect의 힙 크기도 적절한 수준으로 함께 늘려야 한다.

ala.receive.xlog.timeout#

항목 설명
데이터 타입 Long
기본값(초) 300
범위 [1, 4294967294]
설명 XLog 콜렉터가 XLog를 수신하기 위해 대기하는 시간을 지정하는 프로퍼티이다.

ala.log.directory#

항목 설명
데이터 타입 String
기본값 /tmp
설명 ALA가 트레이스 로그를 저장하는 디렉토리를 지정하는 프로퍼티이다.

data.skip.insert#

항목 설명
데이터 타입 Boolean
기본값 false
설명 Altibase 서버에서 실행된 INSERT 구문을 Kafka에 스킵할 지 여부를 결정하는 프로퍼티이다. 이 프로퍼티를 true로 설정하면 Altibase에서 실행된 INSERT 구문이 Kafka에는 전송되지 않는다.
- false: 구문 실행을 스킵하지 않는다. 즉, 정상적으로 구문을 실행한다.
- true: 구문 실행을 스킵한다.

data.skip.update#

항목 설명
데이터 타입 Boolean
기본값 false
설명 Altibase 서버에서 실행된 UPDATE구문을 Kafka에 스킵할 지 여부를 결정하는 프로퍼티이다. 이 프로퍼티를 true로 설정하면 Altibase에서 실행된 UPDATE구문이 Kafka에는 전송되지 않는다.
- false: 구문 실행을 스킵하지 않는다. 즉, 정상적으로 구문을 실행한다.
- true: 구문 실행을 스킵한다.

data.skip.delete#

항목 설명
데이터 타입 Boolean
기본값 false
설명 Altibase 서버에서 실행된 DELETE구문을 Kafka에 스킵할 지 여부를 결정하는 프로퍼티이다. 이 프로퍼티를 true로 설정하면 Altibase에서 실행된 DELETE구문이 Kafka에는 전송되지 않는다.
- false: 구문 실행을 스킵하지 않는다. 즉, 정상적으로 구문을 실행한다.
- true: 구문 실행을 스킵한다.

poll.data.count#

항목 설명
데이터 타입 Int
기본값(밀리초) 1000
범위 [1, 2147483647]
설명 XLog 처리 시, 한 번에 Kafka로 전송할 최대 레코드의 수를 설정하는 프로퍼티이다. 값이 너무 작을 경우, 소스 커넥터에서 시간당 처리되는 XLog의 수가 줄어들 수 있다.

poll.ignore.commit#

항목 설명
데이터 타입 Boolean
기본값 true
설명 XLog 처리 중에 수신된 COMMIT XLog에 대한 처리를 무시할지 여부를 결정하는 프로퍼티이다. 값이 false인 경우, COMMIT XLog 호출 빈도에 따라 소스 커넥터에서 시간당 처리되는 XLog의 수가 줄어들 수 있다.
- true: COMMIT XLog를 무시하고 다음 XLog를 처리한다.
- false: COMMIT XLog 수신 시 해당 XLog 이전에 수신한 레코드들을 Kafka에 전송한다.

poll.interval.ms#

항목 설명
데이터 타입 Int
기본값(밀리초) 1000
범위 [0, 50000]
설명 XLog 송신자가 새로운 XLog를 전송하지 않는 경우, 다음 XLog 확인을 위해 대기하는 시간을 설정하는 프로퍼티이다.

restart.ddl#

항목 설명
데이터 타입 Boolean
기본값 flase
설명 Altibase 서버에서 DDL 수행 시 소스 커넥터를 자동으로 재시작할지를 결정하는 프로퍼티이다.
- false: DDL 수행 시 소스 커넥터가 FAILED 상태로 전환되며, 재시작되지 않는다.
- true: DDL 수행 시 소스 커넥터가 FAILED 상태로 전환되지 않으며, 자동으로 재시작된다.

topic.prefix#

항목 설명
데이터 타입 String
기본값
설명 Altibase 서버에서 실행된 구문을 Kafka에 전송할 때 사용되는 토픽은 기본적으로 테이블 이름으로 사용하는데, 테이블 이름 앞에 접두사를 붙이고 싶은 경우, 이 프로퍼티의 값을 설정하여 접두사를 붙일 수 있다.

싱크 커넥터 프로퍼티#

싱크 커넥터는 Confluent JDBC connector 의 설정 프로퍼티를 그대로 사용하며, Altibase에서 별도로 추가된 프로퍼티는 없다. Confluent JDBC Connector에서 제공하는 설정 프로퍼티에 대한 자세한 내용은 https://docs.confluent.io/Kafka-connectors/jdbc/10.7/sink-connector/sink_config_options.html 를 참고한다.

허용된 DDL#

일반적으로 복제 대상 테이블에 데이터 정의어(DDL)를 수행하면, 소스 커넥터는 현재 DDL 이전에 발생한 모든 변경 사항을 Kafka에 전달한 후 FAILED 상태로 변경된다.

소스 커넥터가 FAILED 상태가 되면, 싱크 데이터베이스에 동일한 DDL을 수행하여 테이블 스키마를 동일하게 만든 후 소스 커넥터를 재시작하여 복제를 다시 수행할 수 있다.

단, 다음에 해당하는 DDL들은 예외적으로 수행해도 소스 커넥터가 FAILED 상태로 전환되지 않는다.

  • ALTER INDEX SET PERSISTENT = ON/OFF
  • ALTER INDEX REBUILD PARTITION
  • GRANT OBJECT
  • REVOKE OBJECT
  • CREATE TRIGGER
  • DROP TRIGGER

그 외 수행할 수 있는 DDL은 Replication Manual 의 '수행할 수 있는 DDL문'을 참조하기 바란다.

Note

restart.ddl 프로퍼티의 값을 true로 설정하면 모든 DDL 수행 시 소스 커넥터가 FAILED 상태로 전환되지 않고 재시작된다.

오프라인 옵션#

Altibase 커넥터를 이용하여 Altibase에서 변경된 데이터를 싱크 데이터베이스에 적용하는 환경에서, 서비스를 제공하는 Altibase 서버에서 장애가 발생하면 싱크 데이터베이스에 적용하지 못한 로그를 전송할 수 없게 된다.

이 때 Altibase 서버에 META_LOGGING Option을 수행 중이고, Altibase 서버와 동일한 데이터베이스 구성을 가진 Standby 서버가 있다면 Standby 서버에서 오프라인 옵션으로 장애가 발생한 Altibase 서버의 로그 파일에 직접 접근하여 미전송 로그를 가져와서 싱크 데이터베이스에 반영할 수 있다.

  • META_LOGGING

송신자 메타 정보와 재시작 SN 정보를 파일로 남겨서 장애 발생시 Standby 서버에서 미전송 로그를 읽어 올 때 필요한 메타 정보를 구성할 수 있게 한다. 파일은 로그 파일 경로의 ala_meta_files 폴더 안에 생성된다.

  • SET OFFLINE ENABLE WITH 'log_dir'

오프라인 이중화 옵션을 사용할 수 있도록 설정한다. 이중화가 중지되어 있는 상태에서만 이 구문을 수행할 수 있다. 장애가 발생한 Altibase 서버의 로그 파일 경로를 설정하여 Standby 서버가 직접 로그 파일에 접근하도록 한다.

  • SET OFFLINE DISABLE

오프라인 이중화 옵션을 사용하지 못하도록 설정한다. 이중화가 중지되어 있는 상태에서만 이 구문을 수행할 수 있다.

  • BUILD OFFLINE META

설정된 로그 파일 경로의 ala_meta_files 폴더에서 송신자 메타 파일과 재시작 SN 파일을 읽어 오프라인 이중화에 필요한 메타 정보를 구성한다.

  • RESET OFFLINE META

RESET OFFLINE META 명령어는 BUILD OFFLINE META 실행 후 오프라인 이중화의 메타 정보를 초기화할 때 사용한다. 다음과 같은 상황에서 수행할 수 있다.

  • 오프라인 이중화 수행 중 에러가 발생해서 메타 정보를 새로 구성해야 하는 경우

  • 오프라인 이중화를 수행할 필요가 없어 메타 정보가 더 이상 필요하지 않은 경우

    단, 오프라인 이중화를 수행하는 중에 DDL 로그로 인해 에러가 발생할 때는 RESET OFFLINE META를 수행하지 않아도 된다. 이 경우 RESET OFFLINE META를 실행하면 DDL 로그를 계속 다시 읽어 에러가 반복 발생할 수 있다.

  • START WITH OFFLINE

설정된 오프라인 경로를 이용하여 이중화를 수행한다. 오프라인 이중화는 일회성 작업으로써, 미전송된 로그를 모두 반영한 후 바로 종료된다. 오프라인 이중화가 종료된 후에는 다시 이중화를 시작할 수 있다.

오프라인 이중화를 수행 할 때 이중화 갭에 DDL 로그가 포함되어 있으면 작업이 중단된다. 이때, 사용자는 Active 서버에서 수행한 DDL 문을 오프라인 이중화를 수행하는 서버에서도 수행했는지 확인하고 다시 오프라인 이중화를 수행해야 한다.

제약사항#

  • 송신자 메타 정보 파일과 재시작 SN 파일의 읽기, 쓰기 기능은 ALA만 사용할 수 있다.

  • 오프라인 이중화를 수행할 Standby 서버의 ALA 객체 이름은 Active 서버의 ALA 객체 이름과 동일해야 한다.

  • 압축 테이블을 이중화 대상으로 가지는 ALA 객체에 대해서는 오프라인 이중화를 지원하지 않는다.

  • 오프라인 이중화가 디스크 이상으로 Active 서버의 로그 파일과 송신자 메타 파일 경로에 접근하지 못할 경우에는 실패한다.

  • Active 서버와 Standby 서버의 로그 파일 크기는 동일해야 한다. 로그 파일 크기는 데이터베이스 생성 시에 정해지므로 오프라인 옵션을 사용하기 전에 이를 꼭 확인하여야 한다.

  • 로그 파일과 송신자 메타 파일을 사용자 임의로 변경(이름 변경, 다른 시스템에 로그 파일을 복제, 삭제)할 경우 비정상 종료와 같은 문제를 발생시킬 수 있다.

  • Standby 서버에 BUILD OFFLINE META 수행 후 재 구동할 경우 로그를 분석하는데 사용할 Remote Meta 정보가 사라지기 때문에 BUILD OFFLINE META를 다시 수행해야 한다.

  • META_LOGGING Option을 사용할 경우 ALA도 이중화와 동일하게 갭을 Archive 로그로 처리 하지 않는다.

  • 두 Altibase 서버의 SM버전, OS, OS비트수 (32또는 64) 또는 로그 파일의 크기가 서로 다르면, 오프라인 이중화를 시작하거나 오프라인 옵션으로 ALA 객체를 생성할 때 실패한다.