proxy를 사용하는 환경에서 아래와 같은 커맨드를 사용해 실행하는데, 


$ setproxy sudo -E  docker service create  \

 --name myservice --network overnet --replicas 2 alpine sleep 1d

 

 

아래와 같이 에러가 발생할 수 있다. 


unable to pin image alpine to digest: Get https://registry-1.docker.io/v2/: net/http: request canceled while waiting for connection (Client.Timeout exceeded while awaiting headers)


문제를 해결하려면. proxy 이슈를 해결해야 한다.


https://docs.docker.com/config/daemon/systemd/#httphttps-proxy



/etc/systemd/system/docker.service.d/http-proxy.conf 설정 파일을 수정한다.



$ sudo mkdir /etc/systemd/system/docker.service.d

  

$ sudo vi /etc/systemd/system/docker.service.d/http-proxy.conf

$ cat  /etc/systemd/system/docker.service.d/http-proxy.conf

[Service]

Environment="HTTP_PROXY=http://proxy.daumkakao.io:3128" "HTTPS_PROXY=http://proxy.daumkakao.io:3128" "NO_PROXY=idock.daumkakao.io,mdock.daumkakao.io,docker-auth.daumkakao.io,mirror.kakao.com,repo.kakao.com,pdr.kakaopay.com,hw-repo.daumkakao.io"





systemctl 데몬을 릴로드 한다.


$ sudo systemctl daemon-reload


다음과 같이 확인한다.


$ sudo systemctl show --property Environment docker

Environment=GOTRACEBACK=crash DOCKER_HTTP_HOST_COMPAT=1 PATH=/usr/libexec/docker:/usr/bin:/usr/sbin HTTP_PROXY=http://proxy.google.io:1111 HTTPS_PROXY=http://proxy.google.io:2222


도커 데몬을 재시작한다.


$ sudo systemctl restart docker




Posted by '김용환'
,


도커 환경을 정리하는 커맨드는 다음과 같다.


docker container prune은 중지된 모든 컨테이너를 삭제한다.

docker image prune은 이름 없는 모든 이미지를 삭제한다.

docker network prune은 사용되지 않는 도커 네트워크를 모두 삭제한다.


docker volume prune은 도커 컨테이너에서 사용하지 않는 모든 도커 볼륨을 삭제한다.

docker system prune -a는 중지된 모든 컨테이너, 사용되지 않은 모든 네트워크, 하나 이상의 컨테이너에서 사용되지 않는 모든 이미지를 삭제한다. 따라서 남아 있는 컨테이너 또는 이미지는 현재 실행 중인 컨테이너에서 필요한 것이다.


Posted by '김용환'
,

gtid = source id : transaction id로 구성


source id는 서버 식별자(server_uuid)
transaction_id는 해당 서버에서 커밋된 트랜잭션의 순서에 따라 순차적인 숫자로 결정된다.
예로 첫 번째 트랜잭션은 transaction_id=1이 되고, 동일한 서버에서 열 번째 트랜잭션은 transaction_id=10이 된다.



gtid 설명한 좋은 블로그 : https://minsugamin.tistory.com/entry/MySQL-57-GTID


MySQL 5.7 GTID

GTID(Global Transaction Identifiers) GTID를 사용하게 되면, 각각의 트렌젝션들은 고유한 전역식별자를 갖게 된다 master 서버에서 수행된(commited) 트랜젝션들이 slave 서버(들)에 적용되어 지는 것에대한 추..

minsugamin.tistory.com



Posted by '김용환'
,


JPA를 사용하는 애플리케이션에서 

debezium에 저장된 데이터를 kafka consume할 때 null이 나오는 경우를 확인했다. 


JPA에서 delete 쿼리를 보낼 때 delete record와 null이 나옴



JPA에서 

 update hibernate_sequence set next_val= 501367 where next_val=501366 실행되지만, 

debezium에서 읽을 수 있는 데이터가 아니라 카프카 토픽에 null이 저장된다.

이런 쿼리가 DB에 실행되고 transaction id가 늘어난다.

Posted by '김용환'
,