Skip to content

[fix] Flyway V9 마이그레이션 실패로 인한 502 에러 수정#108

Merged
k3vin7 merged 1 commit intomainfrom
fix/flyway-migration-502
Mar 20, 2026
Merged

[fix] Flyway V9 마이그레이션 실패로 인한 502 에러 수정#108
k3vin7 merged 1 commit intomainfrom
fix/flyway-migration-502

Conversation

@k3vin7
Copy link
Copy Markdown
Contributor

@k3vin7 k3vin7 commented Mar 20, 2026

Summary

  • V9 마이그레이션 SQL에 IF NOT EXISTS 추가 → role 컬럼 중복 시 에러 방지
  • FlywayConfig 빈 추가 → 앱 시작 시 repair()migrate() 실행하여 실패 기록 및 체크섬 불일치 자동 복구

원인

V9__add_role_to_users.sqlALTER TABLE users ADD COLUMN role ...을 실행할 때, 프로덕션 DB에 이미 해당 컬럼이 존재하면 Flyway가 실패 상태로 기록하고 앱 기동을 중단 → 리버스 프록시에서 502 발생

Test plan

  • 앱 정상 기동 확인
  • /banners GET 정상 응답 확인
  • 로그인 후 인증 필요 API 정상 작동 확인

@k3vin7 k3vin7 merged commit 0d42ee1 into main Mar 20, 2026
1 check passed
@k3vin7 k3vin7 deleted the fix/flyway-migration-502 branch March 20, 2026 08:11
@gemini-code-assist
Copy link
Copy Markdown

Summary of Changes

Hello, I'm Gemini Code Assist1! I'm currently reviewing this pull request and will post my feedback shortly. In the meantime, here's a summary to help you and other reviewers quickly get up to speed!

이 PR은 Flyway V9 마이그레이션 실패로 인해 발생하던 502 에러를 해결합니다. 기존에는 role 컬럼이 이미 존재하는 프로덕션 환경에서 V9__add_role_to_users.sql 스크립트가 에러를 발생시켜 애플리케이션 기동이 중단되고 502 에러가 발생했습니다. 이 문제를 해결하기 위해 SQL 스크립트에 IF NOT EXISTS 조건을 추가하여 컬럼 중복 추가를 방지하고, Flyway 설정에 repair()migrate() 전략을 도입하여 마이그레이션 실패 시 자동 복구 및 재시도를 통해 애플리케이션의 안정적인 시작을 보장합니다.

Highlights

  • Flyway V9 마이그레이션 SQL 수정: V9__add_role_to_users.sql 파일에 IF NOT EXISTS 구문을 추가하여 role 컬럼이 이미 존재하는 경우 발생할 수 있는 중복 에러를 방지했습니다.
  • FlywayConfig 빈 추가: FlywayConfig 클래스를 새로 추가하여 애플리케이션 시작 시 Flyway의 repair()migrate() 메서드를 순차적으로 실행하도록 구성했습니다. 이는 실패한 마이그레이션 기록 및 체크섬 불일치를 자동으로 복구하고 마이그레이션을 재시도하여 안정적인 데이터베이스 스키마 관리를 가능하게 합니다.

🧠 New Feature in Public Preview: You can now enable Memory to help Gemini Code Assist learn from your team's feedback. This makes future code reviews more consistent and personalized to your project's style. Click here to enable Memory in your admin console.

Using Gemini Code Assist

The full guide for Gemini Code Assist can be found on our documentation page, here are some quick tips.

Invoking Gemini

You can request assistance from Gemini at any point by creating a comment using either /gemini <command> or @gemini-code-assist <command>. Below is a summary of the supported commands on the current page.

Feature Command Description
Code Review /gemini review Performs a code review for the current pull request in its current state.
Pull Request Summary /gemini summary Provides a summary of the current pull request in its current state.
Comment @gemini-code-assist Responds in comments when explicitly tagged, both in pull request comments and review comments.
Help /gemini help Displays a list of available commands.

Customization

To customize Gemini Code Assist for GitHub experience, repository maintainers can create a configuration file and/or provide a custom code review style guide (such as PEP-8 for Python) by creating and adding files to a .gemini/ folder in the base of the repository. Detailed instructions can be found here.

Limitations & Feedback

Gemini Code Assist may make mistakes. Please leave feedback on any instances where its feedback is incorrect or counter productive. You can react with 👍 and 👎 on @gemini-code-assist comments. If you're interested in giving your feedback about your experience with Gemini Code Assist for GitHub and other Google products, sign up here.

Footnotes

  1. Review the Privacy Notices, Generative AI Prohibited Use Policy, Terms of Service, and learn how to configure Gemini Code Assist in GitHub here. Gemini can make mistakes, so double check it and use code with caution.

Copy link
Copy Markdown

@gemini-code-assist gemini-code-assist bot left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Code Review

Flyway V9 마이그레이션 실패 문제를 해결하기 위한 변경 사항 잘 보았습니다. SQL 마이그레이션 스크립트에 IF NOT EXISTS를 추가하여 멱등성을 보장한 것은 좋은 접근입니다. 하지만, 애플리케이션 시작 시마다 flyway.repair()를 자동으로 실행하도록 FlywayConfig를 추가한 부분은 몇 가지 잠재적인 위험을 가지고 있습니다. repair()는 실패한 마이그레이션 기록을 삭제하고 체크섬 불일치를 강제로 동기화하는데, 이로 인해 실제 DB 스키마와 Flyway가 인식하는 상태 간의 불일치가 발생할 수 있으며, 중요한 마이그레이션 실패를 인지하지 못하고 넘어갈 수 있습니다. 이는 장기적으로 데이터 정합성 문제를 야기할 수 있으므로, 해당 설정은 제거하고 마이그레이션 실패는 수동으로 처리하는 것을 권장합니다. 자세한 내용은 파일 리뷰에 남겼습니다.

Comment on lines +13 to +16
return flyway -> {
flyway.repair();
flyway.migrate();
};
Copy link
Copy Markdown

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

critical

애플리케이션 시작 시마다 flyway.repair()를 실행하는 것은 위험할 수 있습니다. repair()는 다음과 같은 동작을 수행하는데, 이는 의도치 않은 부작용을 일으킬 수 있습니다.

  1. 실패한 마이그레이션 기록 삭제: 마이그레이션이 중간에 실패한 경우, repair는 실패 기록만 제거합니다. 이 상태에서 다시 migrate를 실행하면, 멱등성이 보장되지 않은 스크립트는 다시 실패하거나 데이터를 손상시킬 수 있습니다. 모든 마이그레이션을 멱등성 있게 작성하도록 강제하는 것은 좋지만, 실수를 방지하는 안전장치가 사라지는 셈입니다.

  2. 체크섬 불일치 자동 해결: 이미 적용된 마이그레이션 파일의 내용이 변경되면 체크섬 오류가 발생합니다. repair는 이를 현재 파일 기준으로 강제 업데이트하는데, 이는 배포된 DB 스키마와 Flyway가 관리하는 버전 간의 불일치를 유발할 수 있습니다. 이는 매우 위험하며, 어떤 변경이 적용되었는지 추적하기 어렵게 만듭니다.

Flyway의 마이그레이션 실패는 중요한 이벤트이며, 개발자가 직접 원인을 파악하고 수동으로 repair나 다른 조치를 취하는 것이 안전합니다. 이번 문제의 경우 V9 스크립트를 멱등적으로 수정한 것으로 충분하며, 이 자동 복구 로직은 제거하는 것을 강력히 권장합니다.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

None yet

Projects

None yet

Development

Successfully merging this pull request may close these issues.

1 participant