최대 절전 모드 : hbm2ddl.auto = 생산시 업데이트?

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가 스키마 변경 관리를 대신 할 수 있습니다.

http://www.liquibase.org/

나는 투표하지 않을 것이다. 최대 절전 모드는 열의 데이터 유형이 변경된 시점을 이해하지 못하는 것 같습니다. 예 (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는이 문제를 해결하기위한 좋은 옵션입니다.

http://flywaydb.org

Hibernate는 자신이 무엇을하고 있는지 모르는 사람들이 그것을 사용해서는 안되는 상황에서 그것을 사용할 때 스스로를 다루기 위해 자동 업데이트를 사용하지 않는 것에 대해 포기를해야합니다.

사용해서는 안되는 상황이 괜찮은 상황보다 크게 허용됩니다.

나는 많은 다른 프로젝트에서 수년 동안 사용해 왔으며 결코 한 가지 문제가 없었습니다. 그것은 절름발이 답변이 아니며 카우보이 코딩이 아닙니다. 역사적인 사실입니다.

"제작에서 절대로 사용하지 마십시오"라고 말하는 사람은 특정 프로덕션 배포 세트, 즉 자신이 알고있는 회사 (그의 회사, 산업 등)를 생각합니다.

"프로덕션 배포"의 세계는 방대하고 다양합니다.

숙련 된 Hibernate 개발자는 주어진 매핑 구성으로 인해 DDL이 무엇을하는지 정확히 알고 있습니다. DDL에서 예상 한 결과 (dev, qa, staging 등)를 테스트하고 검증하는 한 괜찮습니다.

많은 기능을 추가 할 때 자동 스키마 업데이트가 실시간 절약이 될 수 있습니다.

자동 업데이트가 처리하지 않는 항목 목록은 무한하지만 일부 예는 데이터 마이그레이션, Null을 허용하지 않는 열 추가, 열 이름 변경 등입니다.

또한 클러스터 환경에서주의를 기울여야합니다.

그러나이 모든 것을 알고 있다면이 질문을하지 않을 것입니다. 흠. . . 좋습니다.이 질문을하는 경우 제품에서 사용하기 전에 Hibernate 및 자동 스키마 업데이트에 대한 많은 경험이있을 때까지 기다려야합니다.

이 기사 에서 설명했듯이 hbm2ddl.auto프로덕션 환경 에서 사용하는 것은 좋지 않습니다 .

데이터베이스 스키마를 관리하는 유일한 방법은 다음과 같은 이유로 증분 마이그레이션 스크립트를 사용하는 것입니다.

• 스크립트는 코드베이스와 함께 VCS에 상주합니다. 지점을 체크 아웃하면 전체 스키마를 처음부터 다시 만듭니다.
• 프로덕션에 적용하기 전에 QA 서버에서 증분 스크립트를 테스트 할 수 있습니다.
• Flyway 가 스크립트를 실행할 수 있으므로 수동 개입이 필요하지 않으므로 스크립트를 수동으로 실행하는 것과 관련된 인적 오류 가능성이 줄어 듭니다.

최대 절전 모드 사용 설명서 조차도 hbm2ddl프로덕션 환경에이 도구를 사용하지 않는 것이 좋습니다 .

우리는 현재 몇 달 동안 프로덕션에서 실행되는 프로젝트에서 수행하며 지금까지 아무런 문제가 없었습니다. 이 레시피에 필요한 두 가지 재료를 명심하십시오.

1. 이전 버전과의 호환성 접근 방식으로 객체 모델을 설계하십시오. 즉 객체와 속성을 제거 / 변경하지 않고 폐기 합니다. 즉, 객체 또는 속성 이름을 변경해야하는 경우 기존 이름을 그대로두고 새 이름을 추가하고 마이그레이션 스크립트를 작성하십시오. 개체간에 연결을 변경해야하는 경우 이미 프로덕션 환경에있는 경우 디자인이 처음에 잘못되었음을 의미하므로 이전 데이터에 영향을주지 않고 새로운 관계를 표현하는 새로운 방법을 생각해보십시오.

2. 배치하기 전에 항상 데이터베이스를 백업 하십시오.

이 글을 읽은 후,이 토론에 참여하는 사람들의 90 %가 프로덕션 환경에서 이와 같은 자동화를 사용한다는 생각만으로도 겁이납니다. 일부 는 DBA에서 공 을 던졌습니다 . 모든 프로덕션 환경이 DBA를 제공하는 것은 아니며, 많은 개발 팀이 하나 이상의 (적어도 중간 규모 프로젝트)를 감당할 수있는 것은 아닙니다. 모든 사람이 모든 것을해야하는 팀에 대해 이야기하고 있다면 공이 그들 위에 있습니다.

이 경우, 두 세계를 모두 최대한 활용하려고 노력하는 것이 어떻습니까? 이와 같은 도구는 신중한 디자인과 계획으로 많은 상황에서 도움을 줄 수있는 도움의 손길을주기 위해 여기에 있습니다. 그리고 관리자들은 처음에 설득하기가 어려울 수 있지만 공이 자신의 손에 있지 않다는 것을 알고 있다면 그것을 좋아할 것입니다.

개인적으로, 나는 모든 유형의 스키마를 확장하기 위해 손으로 스크립트를 작성하는 것으로 돌아 가지 않았지만 그것은 단지 내 의견 일뿐입니다. 그리고 최근에 NoSQL 스키마없는 데이터베이스를 채택하기 시작한 후,이 스키마 기반 작업이 모두 과거에 속한다는 것을 알 수 있습니다. 따라서 관점을 바꾸고 미리 살펴 보는 것이 좋습니다.

보존해야 할 데이터가 손실 될 수 있으므로 위험하지 않습니다. hbm2ddl.auto = update는 순수하게 개발 데이터베이스를 최신 상태로 유지하는 쉬운 방법입니다.

• 필자의 경우 (Hibernate 3.5.2, Postgresql, Ubuntu), 설정 hibernate.hbm2ddl.auto=update은 이미 존재하는 테이블에서 새로운 테이블과 생성 된 열 만 생성했습니다.

• 테이블을 삭제하거나 열을 삭제하거나 열을 변경하지 않았습니다. 안전한 옵션이라고 할 수 있지만 hibernate.hbm2ddl.auto=create_tables add_columns더 분명합니다.

안전하지는 않지만 권장하지는 않지만 가능합니다.

프로덕션 환경에서 자동 업데이트 옵션을 사용하는 응용 프로그램에 경험이 있습니다.

이 솔루션에서 발견되는 주요 문제와 위험은 다음과 같습니다.

• 잘못된 데이터베이스에 배포하십시오 . 잘못된 데이터베이스에서 이전 버전의 응용 프로그램 (EAR / WAR / etc)으로 응용 프로그램 서버를 실행하려고 실수를 저지른 경우 ... 새 열, 테이블, 외래 키 및 오류가 많이 발생합니다. 데이터 소스 파일 (복사 / 붙여 넣기 파일에서 데이터베이스를 변경하는 것을 잊었습니다)에서 간단한 실수로 동일한 문제가 발생할 수 있습니다. 다시 시작하면 데이터베이스에서 상황이 재앙이 될 수 있습니다.
• 응용 프로그램 서버를 시작하는 데 시간이 너무 오래 걸립니다 . 이것은 Hibernate가 어플리케이션을 시작할 때마다 생성 된 모든 테이블 / 컬럼 / 등을 찾으려고 시도하기 때문에 발생합니다. 그는 무엇을 만들어야하는지 (테이블, 열 등) 알아야합니다. 이 문제는 데이터베이스 테이블이 커질 때만 악화됩니다.
• 데이터베이스 도구 사용이 거의 불가능합니다 . 새 버전으로 실행할 데이터베이스 DDL 또는 DML 스크립트를 작성하려면 애플리케이션 서버를 시작한 후 자동 업데이트로 작성 될 내용을 고려해야합니다. 예를 들어, 일부 데이터로 새 컬럼을 채워야하는 경우 애플리케이션 서버를 시작하고 새 컬럼을 최대 절전 모드로 작성하고 그 이후에만 SQL 스크립트를 실행해야합니다. 보다시피, 데이터베이스 마이그레이션 도구 (Flyway, Liquibase 등)는 자동 업데이트가 활성화 된 상태에서는 거의 불가능합니다.
• 데이터베이스 변경은 중앙 집중식이 아닙니다 . Hibernate create 테이블과 그 밖의 모든 것들이 가능하기 때문에, 대부분의 버전이 자동으로 만들어지기 때문에 각 버전의 애플리케이션에서 데이터베이스의 변화를 관찰하는 것은 어렵다.
• 데이터베이스의 가비지를 권장합니다 . 자동 업데이트를 "쉽게"사용하기 때문에 최대 절전 모드 자동 업데이트에서는이를 수행 할 수 없으므로 팀에서 이전 열과 이전 테이블을 삭제하지 않을 가능성이 있습니다.
• 임박한 재앙 . 프로덕션에서 발생할 수있는 재난의 임박한 위험 (다른 답변에서 언급 한 일부 사람들과 같은). 몇 년 동안 응용 프로그램을 실행하고 업데이트하더라도 안전한 선택이라고 생각하지 않습니다. 나는이 옵션을 사용하는 것이 안전하다고 생각하지 않았습니다.

따라서 프로덕션 환경에서는 자동 업데이트를 사용하지 않는 것이 좋습니다.

프로덕션 환경에서 자동 업데이트를 사용하려면 다음을 권장합니다.

• 분리 된 네트워크 . 테스트 환경이 동종 환경에 액세스 할 수 없습니다. 이렇게하면 테스트 환경에있는 배포가 Homologation 데이터베이스를 변경하지 못하게됩니다.
• 스크립트 순서 관리 . 배포 (구조 테이블 변경, 테이블 삭제 / 열) 및 배포 후 스크립트 (새 열 / 테이블에 대한 정보 채우기) 전에 실행되도록 스크립트를 구성해야합니다.

그리고 다른 게시물과는 달리, 자동 업데이트가 다른 게시물에서 언급 한 것처럼 "매우 지불 된"DBA와 관련이 있다고 생각하지 않습니다. DBA는 테이블과 컬럼을 작성 / 변경 / 삭제하기 위해 SQL 문을 작성하는 것보다 더 중요한 일을합니다. 이 간단한 일상적인 작업은 개발자가 수행하고 자동화 할 수 있으며 DBA 팀이 검토를 위해 전달하기 만하면되지만 Hibernate와 DBA는이를 작성하기 위해 "매일 지불"할 필요가 없습니다.

아니요, 절대하지 마십시오. 최대 절전 모드는 데이터 마이그레이션을 처리하지 않습니다. 예, 스키마가 올바르게 보이지만 프로세스에서 중요한 프로덕션 데이터가 손실되지는 않습니다.

• 일반적으로 대규모 조직의 엔터프라이즈 응용 프로그램은 축소 된 권한으로 실행됩니다.

• 데이터베이스 사용자 이름 에는 필요한 DDL열을 추가 할 권한 이 없을 수 있습니다 hbm2ddl.auto=update.

나는 Vladimir에 동의합니다. 회사의 관리자는 내가 그러한 과정을 제안하더라도 분명히 감사하지 않을 것입니다.

또한, 맹목적으로 Hibernate를 신뢰하는 대신 SQL 스크립트를 생성하면 더 이상 사용하지 않는 필드를 제거 할 수 있습니다. 최대 절전 모드는 그렇게하지 않습니다.

그리고 프로덕션 스키마와 새로운 스키마를 비교하면 데이터 모델에서 변경 한 내용을보다 잘 파악할 수 있습니다. 물론, 당신이 그것을 만들었 기 때문에 알지만 이제는 모든 변경 사항을 한 번에 볼 수 있습니다. 당신을 "뭐 도대체?!"

스키마 델타를 만들 수있는 도구가 있으므로 어렵지 않습니다. 그리고 무슨 일이 일어날 지 정확히 알 수 있습니다.

응용 프로그램의 스키마는 시간이 지남에 따라 발전 할 수 있습니다. 여러 버전으로 설치 될 수있는 여러 설치가있는 경우 응용 프로그램, 도구 또는 스크립트 종류가 스키마 및 데이터를 한 버전에서 다음 버전으로 단계별로 마이그레이션 할 수있는 방법이 있어야합니다.

최대 절전 모드 매핑 (또는 주석)에서 모든 지속성을 유지하는 것은 스키마 진화를 제어 할 수있는 매우 좋은 방법입니다.

스키마 진화에는 몇 가지 측면이 고려되어야합니다.

1. 더 많은 열과 테이블을 추가 할 때 데이터베이스 스키마의 진화

2. 오래된 열, 테이블 및 관계 삭제

3. 기본값으로 새 열 채우기

최대 절전 모드 도구는 (내 경험과 같이) 여러 종류의 데이터베이스에 동일한 버전의 동일한 응용 프로그램이있는 경우 특히 중요합니다.

포인트 3은 Hibernate를 사용하는 경우에 매우 민감합니다. Hibernate가 그러한 열에서 널값을 찾은 경우 예외를 발생시키는 경우, 새로운 부울 값 특성 또는 숫자 특성을 도입 할 경우와 같습니다.

그래서 내가 할 일은 : 실제로 스키마 업데이트의 Hibernate 도구 용량을 사용하지만 기본값 채우기, 더 이상 사용되지 않는 열 삭제 등과 같은 일부 데이터 및 스키마 유지 관리 콜백을 함께 추가해야합니다. 이러한 방식으로 장점 (데이터베이스 독립 스키마 업데이트 스크립트 및 업데이트의 중복 코딩을 방지, 지속성 및 스크립트 사용)을 얻을 수 있지만 작업의 모든 측면을 다루기도합니다.

예를 들어 버전 업데이트가 단순히 varchar 값 속성 (따라서 열)을 추가하는 것으로 구성되어 있으면 자동 업데이트를 사용하면 기본적으로 null로 설정 될 수 있습니다. 더 많은 복잡성이 필요한 경우 더 많은 작업이 필요합니다.

이것은 업데이트 될 때 응용 프로그램이 스키마를 업데이트 할 수 있다고 가정하고 (이는 수행 할 수 있음) 이는 스키마에서이를 수행 할 수있는 사용자 권한이 있어야 함을 의미합니다. 고객 정책으로이를 방지 할 수있는 경우 (Lizard Brain과 같은 경우) 데이터베이스 별 스크립트를 제공해야합니다.