터미널을 새로 하나 열어서

find /var/opt/gitlab/git-data/repositories -exec chown git:git {} \;

입력하고 컨테이너를 재시작한다.

 

출처: https://gitlab.com/gitlab-org/charts/gitlab/-/issues/5546#note_2017038672

원인은 세션별 동시에 읽어들일 수 있는 파일수가 정해져 있는데 초과할 경우 발생한다.

해결은 mac이나 linux면 그 숫자를 늘려주면 된다고 한다.

문제는 windows

범인은 swc였다.

babel을 활성화하면 해결된다.

느린 게 때론 괜찮을 때도 있다.

1. 현재버전 확인하기

docker image의 버전이 lastest라면 도움말에서 현재 사용중인 버전을 확인할 수 있다.
/help

 

2. 업그레이드 계획 세우기

https://gitlab-com.gitlab.io/support/toolbox/upgrade-path

에서  

현재버전부터 올리고 싶은 버전까지 선택

 

summary 와 18.3.1 사이의 … 을 누르면 단계별로 거쳐야하는 버전이 나온다
이렇게....

    각 버전들의 이미지를 미리미리 받아놓는게 편하다. 

3. 컨테이너 교체
    시놀로지 도커에서 기존 컨테이너를 지우고 2번에서 알려주는 다음버전으로 새 컨테이너를 생성한다.
    폴더 경로는 당연히 기존과 같아야 한다.

4. 컨테이너 생성후 시작한지 대충 3-4분 이후부터는 웹 로그인이 가능하다.

5. 관리자 영역 => 모니터링 => 백그라운드 마이그레이션 메뉴에서 Queued에 있는 것들이 완료로 다 가면 컨테이너 종료.
     /admin/background_migrations

6. 2번에서 그 다음버전 확인하고 3번부터 반복.
    2에서 제공하는 각 버전들의 이미지들을 미리 받아놨다면 완료된 이미지는 지우면서 하면 할만하다.

캡쳐는 15.0.5부터로 되어있지만 14부터 올리고 있었는데 15.0.5까지는 얼마 안 걸리길래 우습게 봤더니 15.4.6으로 올리고 있는데 5번이 오래걸리는 꼴이 버전 1개 올릴때마다 대략 30분 걸린다는 말이 허언이 아닌 것 같다. 나스라서 그런지 40분 이상 걸릴때도 있다.
이러다보니 하루 날잡아서 하기 보다는 점심시간이나 퇴근하기 직전에 하나씩 올리는 것이 낫겠다 싶다.

요약: 애초에 인코딩은 꼭 utf8로 설치하고 데이터베이스 생성시 collate는 "C.utf8"로 하자
백업복원으로 재생성할 수 없다면 일일히 수정해야 한다

ALTER TABLE [테이블명]
ALTER COLUMN [컬럼명]
SET DATA TYPE character varying(10) COLLATE "C.utf8";

테스트링크: https://onecompiler.com/postgresql/43pk5sws4

테스트코드

SHOW lc_collate;

SELECT * FROM pg_collation WHERE collname like 'ko%' or collname like '%utf%';

-- create
CREATE TABLE test_table (
  seq SERIAL PRIMARY KEY,
  cd VARCHAR(10) NOT NULL,
  nm VARCHAR(10)  NOT NULL,
  nm2 VARCHAR(10)  NOT NULL COLLATE "C.utf8"
);

-- insert
INSERT INTO test_table (cd, nm, nm2) VALUES ('BROWN', '브라운', '브라운');
INSERT INTO test_table (cd, nm, nm2) VALUES ('FUBAO', '푸바오', '푸바오');
INSERT INTO test_table (cd, nm, nm2) VALUES ('ETC', 'ETC', 'ETC');
INSERT INTO test_table (cd, nm, nm2) VALUES ('NO', '123', '123');

-- fetch 
SELECT a.* FROM test_table as a ORDER BY nm;
SELECT a.* FROM test_table as a ORDER BY nm2;

 

 

이하는 삽질로 얻은 지식 정리

1. 데이터베이스 스키마의 locale 확인

SHOW lc_collate

- 이것은 변경이 불가능하다. 데이터베이스 스키마를 새로 생성해야한다. 그리고 이것으로 기본 정렬된다.

- SELECT * FROM pg_database 에서는 모든 데이터베이스 스키마의 정보를 확인할 수 있고 UPDATE pg_database  SET  어쩌고 해서 수정할 수도 있으나 정렬 자체는 변하지 않았다.

 

2. 해당 스키마에서 사용할 수 있는 collate 확인

SELECT * FROM pg_collation 

한글 윈도우에서 기본 로케일로 설치한 것(이하 윈도우)은 utf8 관련은 전혀 없으나
docker로 설치한 것(이하 도커)은 collname기준 "C.utf8", "en_US.utf8" 두가지 있었다

=> 결론. 윈도우라도 인코딩 utf8로 설치해놔야 배포서버와의 환경차이로 인한 혼란을 줄일 수 있다.

 

3. 2의 테이블에 없는 것은 추가할 수 있다.

https://postgresql.kr/docs/13/sql-createcollation.html

ex) CREATE COLLATION [collation이름] (provider = icu, locale = 'ko_KR.utf8')

 

4. 데이터베이스의 collate를 바꾸지 않고 쿼리문에서 일시적으로 collate를 적용해서 정렬하는 방법

SELECT * FROM [테이블명] ORDER BY [컬럼명] COLLATE "ko-KR-x-icu"

collate 이름은 반드시 쌍따옴표로 해야 하며, 3의 테이블에서 collname컬럼을 사용해야 한다.
그런데 ko로 시작하는 것들로 정렬해보니 영어보다 한글이 먼저 나온다ㅠㅠ

 

'DB' 카테고리의 다른 글

InfluxDB2 backup  (0) 2024.02.06

1. 데이터타입: geography

2. 저장: 

INSERT INTO [테이블명] ([geography컬럼명]) values (geography::Point([위도], [경도], 4326));
-- 4326은 우리가 흔히 사용하는 좌표 CRS임

3. 문자열로 변환 조회
단, 이 경우 "POINT ([경도] [위도])" 형태로 반환되므로, 각각 decimal type의 컬럼으로 저장하는 편이 나았음 (다른 방법이 있을 수 있음)

SELECT convert(nvarchar(50), [geography컬럼명]) as [별칭] FROM [테이블명];
-- POINT ([경도] [위도])

4. 특정 위치를 기준으로 반경 5km 조회하기 - geography 타입을 사용한 이유

-- STDistance는 차이를 미터로 반환함

-- 1. 변수선언이 가능한 경우
DECLARE @Origin GEOGRAPHY
SET @Origin = GEOGRAPHY::Point([위도], [경도])
SELECT * FROM [테이블명] WHERE @Origin.STDistance([geography컬럼명]) <= (5 * 1000);

-- 2. DB에서 바로 조회할 경우.
SELECT * FROM [테이블명] WHERE (SELECT [geography컬럼명] FROM [테이블명] WHERE [관리키컬럼명]=[관리키]).STDistance([geography컬럼명]) <= (5 * 1000);

 

'DB > MSSQL' 카테고리의 다른 글

트리거 소스보기  (0) 2016.10.31
초간단 트리거 문법  (0) 2016.08.24
테이블 명세서 쿼리문  (0) 2014.09.23
0을 나누기 에러 대신 null 반환되도록 하기  (0) 2014.09.19
숫자 앞에 0으로 채우기  (0) 2014.09.04

+ Recent posts