hbm2ddl.auto=update프로덕션 환경에서 데이터베이스 스키마를 업데이트 하도록 구성된 Hibernate 애플리케이션을 실행해도 됩니까?
답변
아니요, 안전하지 않습니다.
최대 절전 모드 팀의 최선의 노력에도 불구하고 프로덕션 환경 에서 자동 업데이트 에 의존 할 수는 없습니다 . 직접 패치를 작성하고 DBA로 검토 한 후 테스트 한 후 수동으로 적용하십시오.
이론적으로 hbm2ddl 업데이트 가 개발에서 작동했다면 프로덕션에서도 작동해야합니다. 그러나 실제로는 항상 그런 것은 아닙니다.
제대로 작동하더라도 차선책 일 수 있습니다. DBA는 그 이유 때문에 그만큼 지불됩니다.
답변
미션 크리티컬하지 않고 직원에 대한 고액의 DBA가없는 애플리케이션이지만 프로덕션 환경에서 수행합니다. 인적 오류가 발생할 수있는 수동 프로세스는 하나뿐입니다. 응용 프로그램은 차이를 감지하고 올바른 작업을 수행 할 수 있으며 다양한 개발 및 테스트 환경에서 테스트 할 수 있습니다.
한 가지주의 사항-클러스터 환경에서는 여러 앱이 동시에 나타날 수 있기 때문에 피할 수 있습니다. 또는 하나의 인스턴스 만 스키마를 업데이트 할 수있는 메커니즘을 사용하십시오.
답변
최대 절전 모드 제작자는 “Java Persistence with Hibernate” 책의 프로덕션 환경에서 그렇게하지 않는 것이 좋습니다 .
경고 : 최대 절전 모드 사용자는 SchemaUpdate를 사용하여 프로덕션 데이터베이스의 스키마를 자동으로 업데이트하려고합니다. 이는 재난으로 빠르게 끝날 수 있으며 DBA에서 허용하지 않습니다.
답변
업데이트 변경 로그를 유지하려면 LiquiBase XML을 확인하십시오. 올해까지는 사용해 본 적이 없지만 DB 개정 관리 / 마이그레이션 / 변경 관리를 배우고 매우 쉽게 만들 수 있다는 것을 알았습니다. 저는 Groovy / Grails 프로젝트를 진행하고 있으며 Grails는 모든 ORM ( “GORM”)에 대해 Hibernate를 사용합니다. 우리는 Liquibase를 사용하여 모든 SQL 스키마 변경을 관리합니다. 앱이 새로운 기능으로 발전함에 따라 상당히 자주 수행됩니다.
기본적으로 응용 프로그램이 발전함에 따라 계속 추가하는 변경 세트의 XML 파일을 유지합니다. 이 파일은 나머지 프로젝트와 함께 git (또는 사용중인 모든 것)으로 유지됩니다. 앱이 배포되면 Liquibase는 연결중인 DB의 변경 로그 테이블을 확인하여 이미 적용된 항목을 파악한 다음 파일에서 아직 적용되지 않은 변경 세트를 지능적으로 적용합니다. 실제로는 완벽하게 작동하며 모든 스키마 변경에 사용하면 체크 아웃 및 배포하는 코드가 항상 완벽하게 호환되는 데이터베이스 스키마에 연결할 수 있다고 100 % 확신 할 수 있습니다.
가장 좋은 점은 랩톱에서 완전히 빈 슬레이트 mysql 데이터베이스를 가져 와서 앱을 실행하고 스키마가 즉시 설정 될 수 있다는 것입니다. 또한 로컬 변경 또는 스테이징 db에 먼저 적용하여 스키마 변경을 쉽게 테스트 할 수 있습니다.
시작하는 가장 쉬운 방법은 기존 DB를 가져온 다음 Liquibase를 사용하여 초기 baseline.xml 파일을 생성하는 것입니다. 그런 다음 나중에 추가하면 liquibase가 스키마 변경 관리를 대신 할 수 있습니다.
답변
나는 투표하지 않을 것이다. 최대 절전 모드는 열의 데이터 유형이 변경된 시점을 이해하지 못하는 것 같습니다. 예 (MySQL 사용) :
String with @Column(length=50) ==> varchar(50)
changed to
String with @Column(length=100) ==> still varchar(50), not changed to varchar(100)
@Temporal(TemporalType.TIMESTAMP,TIME,DATE) will not update the DB columns if changed문자열 열의 길이를 255 이상으로 늘리고 텍스트, 중간 텍스트 등으로 변환하는 것과 같은 다른 예제도있을 수 있습니다.
물론 새로운 열을 만들지 않고 데이터를 복사하고 이전 열을 날려 버리지 않고 “데이터 유형을 변환하는”방법이 실제로 없다고 생각합니다. 그러나 데이터베이스에 열이있는 순간 현재 위험한 상태에서 현재 Hibernate 매핑을 반영하지 않습니다 …
Flyway는이 문제를 해결하기위한 좋은 옵션입니다.
답변
Hibernate는 자신이 무엇을하고 있는지 모르는 사람들이 그것을 사용해서는 안되는 상황에서 그것을 사용할 때 스스로를 다루기 위해 자동 업데이트를 사용하지 않는 것에 대해 포기를해야합니다.
사용해서는 안되는 상황이 괜찮은 상황보다 크게 허용됩니다.
나는 많은 다른 프로젝트에서 수년 동안 사용해 왔으며 결코 한 가지 문제가 없었습니다. 그것은 절름발이 답변이 아니며 카우보이 코딩이 아닙니다. 역사적인 사실입니다.
“제작에서 절대로 사용하지 마십시오”라고 말하는 사람은 특정 프로덕션 배포 세트, 즉 자신이 알고있는 회사 (그의 회사, 산업 등)를 생각합니다.
“프로덕션 배포”의 세계는 방대하고 다양합니다.
숙련 된 Hibernate 개발자는 주어진 매핑 구성으로 인해 DDL이 무엇을하는지 정확히 알고 있습니다. DDL에서 예상 한 결과 (dev, qa, staging 등)를 테스트하고 검증하는 한 괜찮습니다.
많은 기능을 추가 할 때 자동 스키마 업데이트가 실시간 절약이 될 수 있습니다.
자동 업데이트가 처리하지 않는 항목 목록은 무한하지만 일부 예는 데이터 마이그레이션, Null을 허용하지 않는 열 추가, 열 이름 변경 등입니다.
또한 클러스터 환경에서주의를 기울여야합니다.
그러나이 모든 것을 알고 있다면이 질문을하지 않을 것입니다. 흠. . . 좋습니다.이 질문을하는 경우 제품에서 사용하기 전에 Hibernate 및 자동 스키마 업데이트에 대한 많은 경험이있을 때까지 기다려야합니다.
답변
이 기사 에서 설명했듯이 hbm2ddl.auto프로덕션 환경 에서 사용하는 것은 좋지 않습니다 .
데이터베이스 스키마를 관리하는 유일한 방법은 다음과 같은 이유로 증분 마이그레이션 스크립트를 사용하는 것입니다.
- 스크립트는 코드베이스와 함께 VCS에 상주합니다. 지점을 체크 아웃하면 전체 스키마를 처음부터 다시 만듭니다.
- 프로덕션에 적용하기 전에 QA 서버에서 증분 스크립트를 테스트 할 수 있습니다.
- Flyway 가 스크립트를 실행할 수 있으므로 수동 개입이 필요하지 않으므로 스크립트를 수동으로 실행하는 것과 관련된 인적 오류 가능성이 줄어 듭니다.
최대 절전 모드 사용 설명서 조차도 hbm2ddl프로덕션 환경에이 도구를 사용하지 않는 것이 좋습니다 .
