Firebird 2.5 데이터베이스를 ODS12 형식으로 스트리밍 변환(Firebird 3.0)

Firebird의 각 버전에는 고유한 버전의 데이터베이스 디스크 구조 형식인 O(n)D(isk)S(tructure)가 있습니다. 버전 2.5까지 Firebird 엔진은 이전 버전의 ODS와 함께 작동할 수 있습니다. 즉, 이전 버전의 데이터베이스는 새 버전에서 열리고 호환 모드에서 작동했지만 Firebird 3.0 엔진은 자체 ODS 버전의 데이터베이스에서만 작동합니다. 12.0.

3.0으로 마이그레이션하려면 2.5의 데이터베이스를 백업/복원을 통해 새로운 형식으로 변환해야 합니다. 물론 데이터베이스가 이전에 변환을 위해 준비되었다고 가정합니다. Firebird 3.0과의 호환성을 위해 메타데이터 및 쿼리가 확인되었습니다.

표준 접근 방식을 따르는 경우 버전 2.5에서 백업을 만든 다음 3.0을 설치하고 복원해야 함을 의미합니다. 이러한 절차는 시간이 충분하면 허용되지만 대용량 데이터베이스를 마이그레이션하거나 동시에 수십 개의 데이터베이스를 마이그레이션하는 경우 시간이 부족할 때 스트리밍 변환을 사용하면 30-40% 더 빠릅니다. 이 작업을 정확히 수행하는 방법(Windows 및 Linux에서)은 아래를 읽으십시오.

일반적인 아이디어는 파이프라인을 사용하여 속도를 높이는 것입니다.

gbak -b … база25 stdout | gbak -c … stdin база30

2.5의 Gbak은 선형 형식으로 백업을 생성하고 stdout으로 보냅니다. stdout은 즉시 stdin을 통해 3.0의 gbak를 선택하고 새 데이터베이스를 생성합니다.

로컬(파일) 액세스 방법으로 이러한 파이프라인을 구성해야 합니다. 네트워크 액세스(localhost를 통해서도)로 인해 프로세스 속도가 크게 느려지기 때문입니다.

아래에서 Windows 및 Linux에 대한 세부 정보를 살펴봅니다.

Windows

Windows의 경우 가장 쉬운 방법은 Firebird의 완전한 독립 실행형 빌드를 만드는 것입니다. 이를 위해 우리는 임베디드 아카이브 Firebird 2.5, fbemded.dll을 fbclient.dll로 이름을 바꾸고 "일반" 2.5 아카이브에서 gbak.exe 및 (선택 사항) isql.exe 유틸리티를 추가합니다.

파이어버드 3.0 사용 단일 어셈블리 수정이 필요하지 않습니다.

가장 최소 버전(대상 시스템에 VS2008/VS2010 런타임 라이브러리를 설치할 필요가 없음)에는 다음 파일이 포함되어 있습니다.

25/gbak.exe
25/fbclient.dll
25/firebird.conf
25/firebird.log
25/firebird.msg
25/ib_util.dll
25/icudt30.dll
25/icuin30.dll
25/icuuc30.dll
25/Microsoft.VC80.CRT.manifest
25/msvcp80.dll
25/msvcr80.dll

30/fbclient.dll
30/firebird.conf
30/firebird.msg
30/gbak.exe
30/ib_util.dll
30/icudt52.dll
30/icudt52l.dat
30/icuin52.dll
30/icuuc52.dll
30/msvcp100.dll
30/msvcr100.dll
30/intl/fbintl.conf
30/intl/fbintl.dll
30/plugins/engine12.dll

숙련된 관리자는 2.5에 intl/fbintl.dll 및 intl/fbintl.conf 파일이 포함되어 있지 않음을 알 수 있습니다. 이것은 gbak이 연결 문자셋을 사용하지 않고 문자셋 간에 데이터를 변환하지 않지만 Firebird 3.0의 "수신" 측에서는 인덱스를 생성할 때 이러한 파일이 필요하기 때문에 사실입니다.

firebird.conf에서 Firebird 3.0은 다음을 추가하는 것이 좋습니다.

MaxUnflushedWrites = -1
MaxUnflushedWriteTime = -1

또한 2.5와 3.0에 대해 서로 다른 IpcName 값을 설정하는 것이 바람직합니다.

firebird.conf의 다른 매개 변수 값을 선택할 때 간단한 고려 사항에서 진행합니다. 데이터 수혈 단계에서 gbak은 한 프로세스에서 2.5를 실행하고 다른 프로세스에서는 3.0을 실행한 다음 2.5가 종료되고 3.0이 빌드를 시작합니다. 색인.

3.0에서 인덱스 구축 단계의 속도를 높이려면 TempCacheLimit 매개변수의 크기를 ~40% RAM으로 늘리는 것이 좋습니다(물론 전용 서버인 경우).

예를 들어 서버에 16GB의 RAM이 있는 경우

TempCacheLimit=6G

물론 이 값은 64비트 Firebird 3에만 설정할 수 있습니다. 32비트 프로세스는 2GB 이상의 메모리를 할당할 수 없기 때문입니다.

2.5에서는 이 매개변수를 변경할 필요가 없습니다. 어쨌든 2GB를 초과할 수 없으며 백업 중 속도에 영향을 주지 않습니다.

작업을 수행하기 전에 데이터베이스 헤더의 페이지 캐시가 0으로 설정되어 있는지 확인해야 합니다(명령 gstat -h databasename, 페이지 버퍼 행 참조).

캐시가 데이터베이스 헤더에 명시적으로 설정되어 있으면 firebird.conf(및 3.0의 경우 databases.conf)의 값을 무시하고 값이 부적절하게 큰 경우 과도한 메모리 소비 및 스와핑이 발생할 수 있습니다.

그런 다음 파일을 대상 시스템에 복사합니다.

변환은 "시스템" Firebird 2.5 서비스를 중지한 후 로컬 관리자에 대한 높은 권한을 가진 명령줄에서 수행됩니다(예).

set ISC_USER=владелец
"25/gbak" -z -b -g -v -st t -y 25.log база25 stdout|^
"30/gbak" -z -c -v -st t -y 30.log stdin база30

이 예제는 따옴표 안에 "정방향 슬래시"를 사용하고(유효한 "unix 스타일") "hat"("^" 문자)은 긴 명령을 입력할 때 유용한 개행 문자를 이스케이프합니다. -st(atus) 옵션은 Firebird 2.5.8에 등장했으며 gbak 프로세스가 실행되는 시간에 대한 데이터를 기록할 수 있습니다(자세한 내용은 설명서 참조).

Linux

Linux에서 Firebird 3는 tommath 라이브러리에 의존합니다. CentOS(RHEL)에서 이 라이브러리는 시스템 저장소의 Ubuntu(Debian)에 있는 epel 저장소에 있습니다.

CentOS의 경우 먼저 epel 저장소를 연결한 다음 수행해야 합니다.

yum install libtommath

Ubuntu는 추가 리포지토리를 포함할 필요가 없지만 Ubuntu 16 및 Ubuntu 18은 각각 다른 버전의 패키지(libtommath0 및 libtommath1)를 설치합니다.

Firebird 3.0은 tommath.so.0을 찾고 Ubuntu 18의 경우 tommath.so.0에서 tommath.so.1로의 링크(symlink)를 생성해야 합니다. 이렇게 하려면 먼저 tommath.so.1을 찾아야 합니다.

우분투에서 검색된 경로 - /usr/lib/x86_64-linux-gnu/, 그러나 다른 데비안 기반 배포판은 다를 수 있습니다.

두 번째 문제는 Firebird 3.0.1까지는 두 가지 서버 버전을 쉽게 설치할 수 없다는 사실과 관련이 있습니다. "필요한 접두사를 사용하여 소스에서 컴파일" 옵션은 상대적으로 복잡하기 때문에 고려하지 않습니다.

Firebird 3.0.2 이상 구현 --enable-binreloc로 빌드 별도의 설치 프로그램 옵션(-path path).

tommath 라이브러리와 필요한 경우 tommath.so.0에 대한 symlink가 시스템에 추가되었다고 가정하면 현재(이 글을 쓰는 시점) Firebird 3.0.4 배포판을 예를 들어 /opt에 설치할 수 있습니다. /fb3:

./install.sh -path /opt/fb3

그런 다음 Firebird 시스템 서비스를 중지하고 스트리밍 변환을 시작할 수 있습니다.

Firebird를 중지할 때 클래식 모드의 Firebid 2.5 프로세스는 일반적으로 xinetd에 의해 시작되므로 xinetd에 대한 firebird 서비스를 비활성화하거나 xinetd를 완전히 중지해야 합니다.

Linux의 3.0용 firebird.conf에서 MaxUnflushed 매개변수(Windows에서만 작동)를 설정하고 Firebird 2.5 설정을 변경할 필요가 없습니다.

Linux에서 Firebird 2.5 로컬(파일) 액세스는 Windows의 내장 버전과 동일하지 않습니다. 2.5 서버는 gbak 프로세스(네트워크 부분 없이)에서 실행되지만 액세스 권한은 사용자 기반에 대해 확인됩니다. 로그인뿐만 아니라 비밀번호도 필요합니다.

export ISC_USER=username ISC_PASSWORD=password
/opt/firebird/bin/gbak -b … база25 stdout
|/opt/fb3/bin/gbak -c … stdin база30

성공적으로 변환한 후에는 먼저 "추가" Firebird 3.0을 제거한 다음 "기본" Firebird 2.5를 제거한 다음 Firebird 2.5를 새로 설치해야 합니다. 일반 tar.gz 설치 프로그램을 사용하는 것이 가장 좋습니다. 저장소 때문입니다. 리포지토리의 버전이 뒤쳐질 수 있습니다.

또한 Linux에서 데이터베이스를 복원하고 다시 설치한 후 새 데이터베이스가 Firebird 사용자에게 소유되어 있는지 확인해야 합니다.

그렇지 않은 경우 수정해야 합니다.

chown firebird.firebird database

합계

시간과 디스크 공간을 절약하는 것 외에도 스트리밍 변환에는 또 다른 중요한 이점이 있습니다. 기존 Firebird 2.5를 삭제하지 않고 데이터베이스 변환이 수행되므로 변환에 실패한 경우 롤백이 크게 단순화됩니다(대부분 마이그레이션 중 공간 부족 또는 예기치 않은 재부팅으로 인해). 프로세스).

시간 절약은 "클래식" 변환이 "백업 시간"에 "복구 시간"을 더한 것이기 때문입니다. 복구는 백업 파일에서 데이터 읽기와 인덱스 작성의 두 부분으로 구성됩니다.

스트리밍 변환으로 총 시간은 "백업 시간 + XNUMX~XNUMX%" 및 "인덱스 구축 시간"으로 얻습니다.

구체적인 결과는 데이터베이스 구조에 따라 다르지만 평균적으로 복구 시간은 백업 시간의 약 XNUMX배입니다. 따라서 백업 시간을 단위로 사용하면 "클래식 변환"은 시간 단위가 XNUMX개이고 스트리밍은 시간 단위가 XNUMX개입니다. TempCacheLimit를 늘리면 시간을 더 줄이는 데 도움이 됩니다.

일반적으로 실제로 스트리밍 변환을 사용하면 대체 백업 및 복원 시간의 30-40%를 절약할 수 있습니다.

질문이 있으십니까?

의견에 모든 질문을 작성하거나 방법론의 저자이자 이 기사의 공동 저자인 iBase ru의 bs에서 iBase Leading System Engineer인 Vasily Sidorov에게 보내주십시오.

등록된 사용자만 설문 조사에 참여할 수 있습니다. 로그인제발

어떤 버전의 Firebird를 사용하고 있습니까?

• 파이어버드 3.x

• 불새 2.5

• 불새 2.1

• 파이어버드 2.0, 1.5 또는 1.0

16명의 사용자가 투표했습니다. 1명의 사용자가 기권했습니다.

출처 : habr.com