<T>Story <T>Story

1. Take a backup of the etcd cluster and save it to /opt/etcd-backup.db etcd 클러스터를 backup 후 /opt/etcd-backup.db 해당 경로의 해당 파일명으로 저장 Docs keyword : etcd backup https://kubernetes.io/docs/tasks/administer-cluster/configure-upgrade-etcd/#backing-up-an-etcd-cluster # help ETCDCTL_API=3 etcdctl -h # spanshot 생성 예시(옵션 사용) ETCDCTL_API=3 etcdctl \ --endpoints=https://127.0.0.1:2379 \ --cacert= \ --cert= ..

양방향 연관관계와 연관관계의 주인 양방향 매핑 객체와 테이블이 관계를 맺는 차이 객체 연관관계 = 2개 회원 -> 팀 연관관계 1개(단방향) 팀 -> 회원 연관관계 1개(단방향) 테이블 연관관계 = 1개 회원 팀의 연관관계 1개(양방향) 객체의 양방향 관계 객체의 양방향 관계는 사실 양방향 관계가 아니라 서로 다른 단뱡향 관계 2개다. 객체를 양방향으로 참조하려면 단방향 연관관계를 2개 만들어야 한다 테이블의 양방향 연관관계 테이블은 외래 키 하나로 두 테이블의 연관관계를 관리 MEMBER.TEAM_ID 외래 키 하나로 양방향 연관관계 가짐 양쪽으로 조인 가능 둘 중 하나로 외래 키를 관리해야 한다. 객체의 두 관계중 하나를 연관관계의 주인으로 정해서 관리를 해야한다 Member 에서 값을 바꿀 수도 있..

연관관계 매핑 기초 연관관계가 필요한 이유 객체를 테이블에 맞추어 데이터 중심으로 모델링하면 협력 관계를 만들 수 없다 요구사항 회원과 팀이 있다. 회원은 하나의 팀에만 소속될 수 있다. 회원과 팀은 다대일 관계다 객체를 테이블에 맞춰서 모델링 연관관계가 없는 객체 // 참조 대신에 외래 키를 그대로 사용하는 방식 @Entity @Table(name = "TEST_MEMBER") public class TestMember { @Id @GeneratedValue @Column(name = "test_member_id") private Long id; @Column(name = "user_name") private String name; @Column(name = "TEAM_ID") private Long ..

기본 키 매핑 방법 직접 할당 @Id 만 사용 하면 됨 자동 생성(@GeneratedValue) IDENTITY: 데이터베이스에 위임, MYSQL SEQUENCE: 데이터베이스 시퀀스 오브젝트 사용, ORACLE @SequenceGenerator 필요 TABLE: 키 생성용 테이블 사용, 모든 DB에서 사용 @TableGenerator 필요 AUTO: 방언에 따라 자동 지정, 기본값 IDENTITY 전략 기본 키 생성을 데이터베이스에 위임 주로 MySQL, PostgreSQL, SQL Server, DB2에서 사용 (예: MySQL의 AUTO_ INCREMENT) JPA는 보통 트랜잭션 커밋 시점에 INSERT SQL 실행 AUTO_ INCREMENT는 데이터베이스에 INSERT SQL을 실행 한 이후에..

필드와 컬럼 매핑 맵핑 어노테이션 @Column 컬럼 매핑 @Temporal 날짜 타입 매핑 @Enumerated enum 타입 매핑 @Lob BLOB, CLOB 매핑 @Transient 특정 필드를 컬럼에 매핑하지 않음(매핑 무시) @Column @Enumerated 자바 enum 타입을 맵핑하는 경우 사용한다 ORDINAL 은 사용하지 말자 (순서를 저장하기 때문에 실제 Enum 코드 변경시 잘못된 데이터를 바라볼 수 있음) @Temporal 날짜 타입(java.util.Date, java.util.Calendar)을 매핑할 때 사용 참고: LocalDate, LocalDateTime 사용시 생략 가능 @Lob 데이터베이스 BLOB, CLOB 타입과 매핑 @Lob에는 지정할 수 있는 속성이 없다. 매..

데이터베이스 스키마 자동생성 옵션 (hibernate.hbm2ddl.auto) create 기존테이블 삭제 후 다시 생성 (DROP + CREATE) create-drop create와 같으나 종료시점에 테이블 DROP update 변경분만 반영 운영 DB에는 사용하면 안됨 validate 엔티티와 테이블이 정상 매핑되었는지만 확인 none 사용하지 않음 자동생성 주의사항 운영 장비에는 절대 create, create-drop, update 사용하면 안됨 개발 초기 단계는 create 또는 update 테스트 서버는 update 또는 validate 스테이징과 운영 서버는 validate 또는 none

클라우드를 써야 백업, 리스토어, 보안 등이 더 유리하다 스타트업부터 큰 기업까지 다 클라우드 사용한다 요즘엔 글로벌 서비스를 하는 기업일수록 클라우드를 사용해야 더 유리하다 (ID 센터를 만들어서 직원 뽑고 운영하기 힘듬) 도커 환경에서 개발시 장점 드라이버를 신경 쓰지 않고 윈도우 컨테이너, 리눅스 컨테이너 구분만 해서 올리면 된다 운영자 입장에서는 스케일아웃(서버 증설)과 스케일업에 유리하다 컨테이너를 사용하면 스케일 아웃, 스케일인 모두 유리하다 컨테이너로 개발하고 클라우드 환경에 올려서 관리하는 경우가 많다 버츄얼 박스 설치 1) Oracle Virtual Box 프로그램 준비 https://www.virtualbox.org/wiki/Downloads 2) CentOS 7 ISO 파일 준비 (최..

ITEM 90 직렬화된 인스턴스 대신 직렬화 프록시 사용을 검토하라 Serializable을 구현하기로 결정한 순간 언어의 정상 메커니즘인 생성자 이외의 방법으로 인스턴스 생성이 가능해진다 버그와 보안 문제가 일어날 가능성이 커진다 직렬화 프록시 패턴을 사용하면 버그와 보안 문제가 줄어든다 적절한 프록시 패턴은 별로 복잡하지 않다 바깥 클래스의 논리적 상태를 정밀하게 표현하는 중첩 클래스를 설계해 private static으로 선언한다 이 중첩 클래스가 바로 바깥 클래스의 직렬화 프록시다 중첩 클래스의 생성자는 단 하나여야 하며 바깥 클래스를 매개변수로 받아야 한다 이 생성자는 단순히 인수로 넘어온 인스턴스의 데이터를 복사한다 일관성 검사나 방어적 복사도 필요 없다 설계상 직렬화 프록시의 기본 직렬화 형..

ITEM 89 인스턴스 수를 통제해야 한다면 readResolve 보다는 열거 타입을 사용하라 바깥에서 생성자를 호출하지 못하게 막는 방식으로 싱글턴을 보장한 코드 public class Elvis { public static final Elvis INSTANCE = new Elvis(); private Elvis() { .. } public void leaveTheBuilding() { .. } } 위 코드는 클래스 선언에 implements Serializable을 추가하면 더이상 싱글턴이 아니게 된다 기본 직렬화를 쓰지 않더라도, 명시적인 readObject를 제공하더라도 소용 없다 어떤 readObject를 사용하든 이클르새가 초기화될 때 만들어진 인스턴스와는 별개인 인스턴스를 반환하게 된다 re..

ITEM 88 readObject 메서드는 방어적으로 작성하라 객체를 역직렬화할 때는 클라이언트가 소유해서는 안 되는 객체 참조를 갖는 필드를 모두 반드시 방어적으로 복사해야 한다 readObject 메서드를 작성할 때는 언제나 public 생성자를 작성하는 자세로 임하자 readObject는 어떤 바이트 스트림이 넘어오더라도 유효한 인스턴스를 만들어내야 한다 바이트 스트림이 진짜 직렬화된 인스턴스라고 가정해서는 안 된다 여기서는 기본 직렬화 형태를 사용한 클래스를 예로 들었지만 커스텀 직렬화를 사용하더라도 모든 문제가 그대로 발생할 수 있다 안전한 readObject 메서드를 작성하는 지침 private이어야 하는 객체 참조 필드는 각 필드가 가리키는 객체를 방어적으로 복사하라 불변 클래스 내의 가변 ..