휴지 상태: hbm2dl.auto=업데이트를 실가동 중입니까?

휴지 상태: hbm2dl.auto=업데이트를 실가동 중입니까?

Hibernate 어플리케이션을 실행해도 될까요?hbm2ddl.auto=update운영 환경에서 데이터베이스 스키마를 업데이트하려면 어떻게 해야 합니까?

아니, 안전하지 않아.

Hibernate 팀의 최선의 노력에도 불구하고 프로덕션에서 자동 업데이트에 의존할 수 없습니다.자체 패치를 작성하여 DBA와 함께 검토하고 테스트한 후 수동으로 적용합니다.

이론적으로 hbm2dl 업데이트가 개발 중에 작동했다면 생산에서도 작동해야 합니다.하지만 실제로는 항상 그런 것은 아닙니다.

정상 작동하더라도 차선일 수 있습니다.DBA가 그렇게 많은 돈을 받는 데는 이유가 있습니다.

미션 크리티컬하지 않은 애플리케이션과 높은 급여를 받는 DBA가 없는 경우에도 운영 환경에서 작업을 수행합니다.수동 프로세스가 하나 적기 때문에 사람의 실수가 발생하기 쉽습니다.어플리케이션은 차이를 검출하여 적절한 처리를 할 수 있습니다.또한 다양한 개발 및 테스트 환경에서 테스트한 것으로 생각됩니다.

한 가지 주의: 클러스터 환경에서는 여러 개의 앱이 동시에 실행되어 스키마를 수정하려고 할 수 있으므로 이를 피하는 것이 좋습니다.또는 하나의 인스턴스만 스키마를 업데이트할 수 있는 메커니즘을 추가합니다.

동면기의 크리에이터는, 「동면기를 사용한 Java 퍼시스텐스」라고 하는 저서에서, 실가동 환경에서 동면하는 것을 추천합니다.

경고: 사용자가 SchemaUpdate를 사용하여 프로덕션 데이터베이스의 스키마를 자동으로 업데이트하려고 시도하는 것을 볼 수 있습니다.이는 곧 재해로 끝날 수 있으며 DBA는 이를 허용하지 않습니다.

업데이트의 Changelog를 보관하려면 LiquiBase XML을 확인하십시오.올해까지 사용해 본 적은 없지만, DB 리비전 제어/이행/변경 관리를 익히고 쉽게 할 수 있다는 것을 알게 되었습니다.저는 Groovy/Grails 프로젝트에서 일하고 있으며 Grails는 모든 ORM(GORM)에 Hibernate를 사용하고 있습니다.우리는 모든 SQL 스키마 변경을 관리하기 위해 Liquibase를 사용합니다.이러한 변경은 앱이 새로운 기능으로 진화함에 따라 자주 이루어집니다.

기본적으로 응용 프로그램이 발전함에 따라 계속 추가할 변경 집합의 XML 파일을 보관합니다.이 파일은 프로젝트의 나머지 부분과 함께 git(또는 사용하고 있는 것)에 보관됩니다.앱이 전개되면 Liquibase는 접속하고 있는 DB의 Changelog 테이블을 체크하여 이미 적용된 내용을 파악한 후 파일에서 아직 적용되지 않은 변경 사항을 지능적으로 적용합니다.실제로는 매우 효과적이며 스키마 변경에 모두 사용할 경우 체크아웃 및 전개하는 코드가 항상 완전히 호환되는 데이터베이스 스키마에 연결할 수 있다는 것을 100% 확신할 수 있습니다.

놀라운 점은 노트북에 완전히 빈 slate mysql 데이터베이스를 가져와 앱을 실행하면 스키마가 바로 설정된다는 것입니다.또한 스키마 변경을 local-dev에 적용하거나 먼저 스테이징 DB에 적용함으로써 스키마 변경을 쉽게 테스트할 수 있습니다.

가장 쉬운 방법은 기존 DB를 가져와서 Liquibase를 사용하여 초기 baseline.xml 파일을 생성하는 것입니다.그런 다음 나중에 여기에 추가하여 스키마 변경 관리를 리키베이스에 맡길 수 있습니다.

http://www.liquibase.org/

휴지 상태에서는, 자동 업데이트를 사용하지 않는 것에 관한 면책 사항을, 자신이 무엇을 하고 있는지 모르는 사람이 사용하지 않는 상황에서 자동 업데이트를 사용하고 있는 경우에, 그 자체를 커버하기 위해서 삽입할 필요가 있습니다.

사용해서는 안 되는 상황이 괜찮다는 상황보다 훨씬 많다는 것을 인정한다.

여러 프로젝트에서 수년간 사용해왔고 단 한 번도 문제가 없었습니다.어설픈 대답도 아니고 카우보이 코드도 아니야그것은 역사적인 사실이다.

「생산에서는 절대로 하지 않는다」라고 하는 사람은, 특정의 생산 배치, 즉 자신이 알고 있는 것(회사, 업계등)을 생각하고 있습니다.

「실가동 도입」의 세계는 방대하고 다양합니다.

경험이 풍부한 하이버네이트 개발자는 특정 매핑 구성에서 DDL이 어떤 결과를 가져올지 정확히 알고 있습니다.DDL(개발, QA, 스테이징 등)에 도달하는 것을 테스트 및 검증하기만 하면 됩니다.

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

자동 업데이트로 처리할 수 없는 항목의 목록은 무한하지만 데이터 마이그레이션, Null이 아닌 열 추가, 열 이름 변경 등이 있습니다.

클러스터 환경에서도 주의가 필요합니다.

하지만 이 모든 것을 알았다면 이런 질문을 하지 않았을 겁니다음... 좋아요. 이 질문을 하는 경우 하이버네이트 및 자동 스키마 업데이트에 대한 경험이 풍부해질 때까지 기다렸다가 실행 시 사용하는 것을 고려해 보십시오.

사용하는 것은 좋지 않습니다.hbm2ddl.auto실가동 중입니다.

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

• 스크립트는 코드베이스와 함께 VCS에 저장됩니다.지점을 체크아웃할 때 스키마 전체를 처음부터 다시 만듭니다.
• 증분 스크립트는 운영 환경에 적용되기 전에 QA 서버에서 테스트할 수 있습니다.
• 스크립트는 Flyway에서 실행할 수 있기 때문에 수동으로 조작할 필요가 없습니다.따라서 스크립트를 수동으로 실행할 때 발생할 수 있는 인위적인 오류의 가능성을 줄일 수 있습니다.

휴지 상태 유저 가이드에서도,hbm2ddl실제 가동 환경을 위한 도구입니다.

반대표를 던지겠어요최대 절전 모드에서 열의 데이터 유형이 변경된 시기를 인식하지 못하는 것 같습니다.예(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

String 열의 길이를 255개 이상으로 늘리거나 텍스트, 중간 텍스트 등으로 변환하는 등 다른 예도 있을 수 있습니다.

물론 새로운 컬럼을 작성하거나 데이터를 복사하거나 오래된 컬럼을 삭제하지 않고 데이터 타입을 변환하는 방법은 없다고 생각합니다.그러나 데이터베이스에 현재 휴지 상태 매핑을 반영하지 않는 열이 있는 순간 매우 위험한 삶을 살고 있습니다.

플라이웨이는 이 문제에 대처하기 위한 좋은 옵션입니다.

http://flywaydb.org

당신이 보존했어야 할 데이터를 잃게 될 수도 있기 때문에 위험을 감수하지 않을 것입니다.hbm2dl.auto=update는 개발 데이터베이스를 최신 상태로 유지하는 단순한 방법입니다.

현재 몇 달째 생산 중인 프로젝트에서 진행 중이며 지금까지 문제가 발생한 적은 없습니다.이 레시피에 필요한 2가지 재료를 기억하십시오.

1. 개체와 속성을 제거/변경하지 않고 사용하지 않는 하위 호환성 접근 방식으로 개체 모델을 설계합니다.즉, 오브젝트 또는 Atribute의 이름을 변경해야 할 경우 이전 Atribute를 그대로 두고 새 Atribute를 추가한 후 일종의 이행 스크립트를 작성합니다.오브젝트간의 관련성을 변경할 필요가 있는 경우는, 이미 실가동하고 있는 경우는, 처음부터 설계가 잘못되어 있는 것을 의미하기 때문에, 낡은 데이터에 영향을 주지 않고 새로운 관계를 표현하는 새로운 방법을 생각해 주세요.

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

이 글을 읽은 후, 이 토론에 참가한 사람들의 90%는 실제 가동 환경에서 이와 같은 자동화를 사용할 생각만 해도 공포에 떨고 있다고 생각합니다.일부는 DBA에게 공을 던집니다.그러나 모든 운영 환경에서 DBA를 제공하는 것은 아니며, DBA를 제공할 수 있는 개발 팀은 많지 않습니다(적어도 중간 규모 프로젝트의 경우).그러니까, 모두가 모든 것을 해야 하는 팀을 말하는 거라면, 공은 그들에게 있습니다.

이 경우, 왜 두 세계의 장점을 모두 가지려고 하지 않는가?이와 같은 툴은 도움이 됩니다.구체적인 설계와 계획을 통해 많은 상황에서 도움이 됩니다.그리고 처음에는 관리자가 납득하기 어려울 수도 있지만, 책임져야 할 일이 아니라는 것을 알게 되면 관리자는 매우 기뻐할 것입니다.

개인적으로 스키마를 확장하기 위해 손으로 스크립트를 작성하는 일은 없을 것입니다만, 그것은 제 의견일 뿐입니다.그리고 최근 NoSQL 스키마리스 데이터베이스를 도입하기 시작한 후, 조만간 이러한 스키마 기반 작업이 모두 과거에 속하게 될 것임을 알 수 있습니다. 따라서 관점을 바꾸고 미래를 내다보는 것이 좋습니다.

• 내 경우(Hibernate 3.5.2, Postgresql, Ubuntu), 설정hibernate.hbm2ddl.auto=update기존 테이블에 새 테이블과 새 열만 생성했습니다.

• 테이블도, 컬럼도, 컬럼도, 변경도 변경하지 않았습니다.안전한 선택이라고 할 수 있지만hibernate.hbm2ddl.auto=create_tables add_columns좀 더 명확해질 거예요.

안전하지도 않고 추천하지도 않지만 가능해요

생산 시 auto-update 옵션을 사용한 어플리케이션 경험이 있습니다.

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

• 잘못된 데이터베이스에 배포합니다.잘못된 데이터베이스에서 이전 버전의 애플리케이션(EAR/WAR 등)을 사용하여 애플리케이션 서버를 실행하는 오류를 범한 경우...새로운 열, 테이블, 외부 키 및 오류가 많이 발생합니다.데이터 소스 파일의 단순한 오류(파일의 복사/붙여넣기 및 데이터베이스 변경을 잊어버린 경우)에서도 같은 문제가 발생할 수 있습니다.재개 시에는 데이터베이스에 장애가 발생할 수 있습니다.
• 응용 프로그램 서버를 시작하는 데 시간이 너무 오래 걸립니다.이 문제는 응용 프로그램을 시작할 때마다 Hibernate가 작성된 모든 테이블/컬럼 등을 검색하려고 하기 때문에 발생합니다.작성해야 할 항목(테이블, 컬럼 등)을 알아야 합니다.이 문제는 데이터베이스 테이블이 커질수록 악화될 뿐입니다.
• 데이터베이스 툴은 거의 사용할 수 없습니다.새 버전에서 실행할 데이터베이스 DDL 또는 DML 스크립트를 작성하려면 응용 프로그램서버를 기동한 후 자동 갱신에 의해 작성되는 내용에 대해 고려해야 합니다.예를 들어 새 열에 데이터를 입력해야 할 경우 애플리케이션 서버를 시작하고 새 열을 휴지 상태로 만들 때까지 기다린 후 SQL 스크립트를 실행해야 합니다.보시는 바와 같이 데이터베이스 마이그레이션 도구(Flyway, Liquibase 등)는 자동 업데이트를 활성화하면 거의 사용할 수 없습니다.
• 데이터베이스 변경이 중앙 집중화되지 않습니다.휴지 상태에서는 테이블 작성 등의 가능성이 있기 때문에 어플리케이션의 각 버전의 데이터베이스 변경은 대부분 자동으로 이루어지기 때문에 감시하기가 어렵습니다.
• 데이터베이스의 가비지를 권장합니다.자동 업데이트는 "쉽게" 사용할 수 있기 때문에 팀에서는 오래된 열과 오래된 테이블을 삭제하지 않을 수 있습니다.동면 상태의 자동 업데이트에서는 삭제할 수 없기 때문입니다.
• 재해가 임박했다.프로덕션에서 재해가 발생할 위험이 임박했습니다(다른 답변에 언급된 일부 사람들처럼).애플리케이션을 몇 년 동안 실행하고 업데이트해도 안전한 선택은 아니라고 생각합니다.이 옵션을 사용하는 것에 대해 안심할 수 없었습니다.

따라서 생산 시 자동 업데이트를 사용하는 것은 권장하지 않습니다.

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

• 분리된 네트워크테스트 환경에서 호몰로그 환경에 액세스할 수 없습니다.이렇게 하면 테스트 환경에 있어야 할 배포가 호몰로게이션 데이터베이스를 변경하는 것을 방지할 수 있습니다.
• 스크립트 순서를 관리합니다.배포 전에 실행할 스크립트(구조 테이블 변경, 테이블/컬럼 삭제)와 배포 후 스크립트(새 열/테이블 정보 입력)를 구성해야 합니다.

그리고 다른 투고와 달리 자동 업데이트는 (다른 투고에서 언급한 바와 같이) "매우 높은 급여" DBA와 관련이 없다고 생각합니다.DBA는 SQL 문을 작성하여 테이블 및 열을 작성/변경/삭제하는 것보다 더 중요한 작업을 수행해야 합니다.이러한 간단한 일상 작업은 개발자에 의해 수행 및 자동화할 수 있으며, DBA 팀이 검토하는 데만 전달할 수 있습니다. Hibernate 및 DBA가 "고액의 급여"를 지불할 필요는 없습니다.

아니, 절대 하지 마.휴지 상태에서는 데이터 이행은 처리되지 않습니다.예, 스키마는 올바르게 표시되지만 프로세스 중에 귀중한 프로덕션 데이터가 손실되지 않습니다.

• 일반적으로 대규모 조직에서는 엔터프라이즈애플리케이션이 축소된 권한으로 실행됩니다.

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

나도 블라디미르 말에 동의해제가 그런 강좌를 제안해도 저희 회사 관리자는 당연히 좋아하지 않을 것입니다.

또한 Hibernate를 맹목적으로 신뢰하는 대신 SQL 스크립트를 작성하면 더 이상 사용되지 않는 필드를 제거할 수 있습니다.휴지 상태에서는 그렇지 않습니다.

또한 프로덕션 스키마와 새로운 스키마를 비교하면 데이터 모델에서 변경한 와트를 더 잘 파악할 수 있습니다.물론, 당신이 해냈기 때문에, 하지만 이제 당신은 모든 변화를 한번에 볼 수 있습니다.'뭐야!'라고 하는 것도 그렇고

스키마 델타를 만들 수 있는 툴이 있기 때문에 어려운 일도 아닙니다.그러면 무슨 일이 일어날지 정확히 알 수 있어요

애플리케이션의 스키마는 시간이 지남에 따라 진화할 수 있습니다.여러 개의 인스톨이 있는 경우(다른 버전일 수도 있음)에는, 사용의 애플리케이션이나 툴이나 스크립트의 종류에 따라서, 스키마와 데이터를 단계적으로 이행 할 수 있는 방법이 있습니다.

휴지 상태 매핑(또는 주석)을 모두 유지하는 것은 스키마의 진화를 제어하는 매우 좋은 방법입니다.

스키마의 진화에는 고려해야 할 몇 가지 측면이 있습니다.

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

2. dropping of old columns, tables and relations

3. filling new columns with defaults

Hibernate tools are important in particular in case (like in my experience) you have different versions of the same application on many different kinds of databases.

Point 3 is very sensitive in case you are using Hibernate, as in case you introduce a new boolean valued property or numeric one, if Hibernate will find any null value in such columns, if will raise an exception.

So what I would do is: do indeed use the Hibernate tools capacity of schema update, but you must add alongside of it some data and schema maintenance callback, like for filling defaults, dropping no longer used columns, and similar. In this way you get the advantages (database independent schema update scripts and avoiding duplicated coding of the updates, in peristence and in scripts) but you also cover all the aspects of the operation.

So for example if a version update consists simply in adding a varchar valued property (hence column), which may default to null, with auto update you'll be done. Where more complexity is necessary, more work will be necessary.

This is assuming that the application when updated is capable of updating its schema (it can be done), which also means that it must have the user rights to do so on the schema. If the policy of the customer prevents this (likely Lizard Brain case), you will have to provide the database - specific scripts.

ReferenceURL : https://stackoverflow.com/questions/221379/hibernate-hbm2ddl-auto-update-in-production