Repository navigation
Conversation
|
리뷰 완료 — Blocker 0건, Major 2건, Minor 0건, Question 0건 |
cd19bea to
ad57e65
Compare
|
지적 사항 없음 |
| ### 기존 명령과의 연계 | ||
|
|
||
| `upgrade`를 지원하면서 클러스터 안에 여러 버전이 함께 존재할 수 있습니다. 이에 맞춰 기존 명령의 버전 처리도 다음과 같이 바뀝니다. | ||
|
|
||
| | 명령 | 변경 내용 | | ||
| |-------------|--------------------------------------------------------------------------------------------| | ||
| | `deploy` | 배포 버전을 명령 인자 대신 토폴로지의 `globalConfig.version`으로 지정합니다. 아래 [배포 버전 지정 방식 변경 (예정)](#배포-버전-지정-방식-변경-예정)을 참고하세요. | | ||
| | `start` | 캐시 서버별로 기록된 버전으로 시작합니다. | | ||
| | `stop` | 캐시 서버별로 기록된 버전의 pid 파일(`<path>/<version>/memcached-<port>.pid`)로 중지합니다. | | ||
| | `delete` | 실행 여부 확인과 `--purge` 대상 경로를 캐시 서버별 버전 기준으로 판단합니다. | | ||
| | `list` | 버전 혼용 여부와 버전별 캐시 서버 수를 표시합니다. | | ||
| | `status` | 기존 출력에 캐시 서버별 실행 버전과 업그레이드 진행·실패 단계를 추가합니다. | |
There was a problem hiding this comment.
수정해야하는 작업 기록용으로 코멘트 남깁니다.
There was a problem hiding this comment.
-
start에 버전 인자를 추가하고, stop+start 하는 것과
upgrade 명령의 동작에는 어떤 차이가 있나요? -
내부 토폴로지의 버전은 언제 사용(변경)되나요?
Draft of the rolling upgrade interface for review before implementation. Existing command docs still describe current behavior; planned changes live only in the `cluster upgrade` section. - Targets must be given explicitly with `--node`, `--group` or `--all` to prevent accidental cluster-wide upgrades. `--all` skips targets already running the target version. - Show a plan table with per-target current/target version and action. - Install target binaries on all hosts before stopping any server. - Plan to move the deploy version into `globalConfig.version`. - Plan to show per-server versions in `cluster status`. Co-Authored-By: Claude Opus 5.5 (1M context) <noreply@anthropic.com>
ad57e65 to
0a4ce54
Compare
|
지적 사항 없음 |
|
@jhpark816 업그레이드 인터페이스 확인해주시면 됩니다. |
|
@namsic |
| | 필드 | 설명 | 필수 | | ||
| |------------------------|-------------------|------| | ||
| | `globalConfig.version` | 배포할 Arcus 버전 | 예 | | ||
|
|
||
| `globalConfig.version`은 **최초 배포 버전**으로만 사용합니다. 배포 이후 캐시 서버별 버전과 클러스터 기본 버전은 운영 장비의 `meta.yml`이 관리하며, 저장된 `topology.yml`은 배포 당시 원본 그대로 유지합니다. |
There was a problem hiding this comment.
deploy 이후 사용하지 않는 값이면, 버전을 기존처럼 명령 인자로 받아도 될 것 같은데 별도로 보관하고 유지/관리하도록 변경하는 이유는 무엇인가요?
| |-------------|--------------------------------------------------------------------------------------------| | ||
| | `deploy` | 배포 버전을 명령 인자 대신 토폴로지의 `globalConfig.version`으로 지정합니다. 아래 [배포 버전 지정 방식 변경 (예정)](#배포-버전-지정-방식-변경-예정)을 참고하세요. | | ||
| | `start` | 캐시 서버별로 기록된 버전으로 시작합니다. | | ||
| | `stop` | 캐시 서버별로 기록된 버전의 pid 파일(`<path>/<version>/memcached-<port>.pid`)로 중지합니다. | |
There was a problem hiding this comment.
pid는 <path>/memcached-port.pid 처럼 한 개 경로 공유해도 될 것 같습니다.
| ``` | ||
|
|
||
| - `--group`으로 업그레이드할 replication group을 지정합니다. 여러 group을 지정하면 나열한 순서대로 업그레이드합니다. | ||
| - `--node`는 사용할 수 없습니다. |
There was a problem hiding this comment.
@namsic
enterprise에서 --node 제공하지 않아도 되는지 검토 바랍니다.
| arcusctl cluster upgrade my-cluster --version 1.16.2 --all | ||
| ``` | ||
|
|
||
| - `--node`로 업그레이드할 캐시 서버를 지정합니다. 여러 캐시 서버를 지정하면 나열한 순서대로 업그레이드합니다. |
There was a problem hiding this comment.
캐시 서버 업그레이드 간격은 어떻게 되나요?
고정 값인지 or 설정 가능한 지에 대해서도 정해두면 좋겠습니다.
| arcusctl cluster upgrade my-repl-cluster --version 0.12.2-E --all | ||
| ``` | ||
|
|
||
| - `--group`으로 업그레이드할 replication group을 지정합니다. 여러 group을 지정하면 나열한 순서대로 업그레이드합니다. |
|
|
||
| | 명령 | 변경 내용 | | ||
| |-------------|--------------------------------------------------------------------------------------------| | ||
| | `deploy` | 배포 버전을 명령 인자 대신 토폴로지의 `globalConfig.version`으로 지정합니다. 아래 [배포 버전 지정 방식 변경 (예정)](#배포-버전-지정-방식-변경-예정)을 참고하세요. | |
There was a problem hiding this comment.
버전 명시 방식을 변경하는 것은 upgrade 방식과는 무관하죠?
단순히 globalConfig.version으로 지정하는 것이 좋겠다고 판단하여 변경하는 것이죠?
| |------------------------|-------------------|------| | ||
| | `globalConfig.version` | 배포할 Arcus 버전 | 예 | | ||
|
|
||
| `globalConfig.version`은 **최초 배포 버전**으로만 사용합니다. 배포 이후 캐시 서버별 버전과 클러스터 기본 버전은 운영 장비의 `meta.yml`이 관리하며, 저장된 `topology.yml`은 배포 당시 원본 그대로 유지합니다. |
There was a problem hiding this comment.
최초 배포 버전은 관리할 필요가 없어 보입니다. 개인적 의견입니다.
클러스터 수준에서 최초 배포 버전, 기본 버전을 유지하는 건가요?
| g2 master 192.0.2.23:11211 0.12.1-E running yes | ||
| g2 slave 192.0.2.24:11211 0.12.1-E running yes | ||
| Upgrade in progress: 0.12.1-E -> 0.12.2-E (1/2 groups done) |
There was a problem hiding this comment.
클러스터의 노드는 어느 한 시점에 최대 2개의 버전만 가질 수 있다.
3개의 버전을 가질 수 없는 것으로 제한하는 것인가요?
🔗 Related Issue
⌨️ What I did