member-merge
DB: chat_test2

사용 가이드

member-merge를 사용해 안전하게 유저 머지/복구를 수행하는 운영 절차를 정리합니다.

1) 솔루션 개요

- 목적: Tinode(MongoDB) 데이터에서 A(남겨둘 계정)를 유지한 채, 실제 참조/대화/구독의 기준을 B(기준 계정)로 이동합니다.
- A에는 merge 메타(merge.to/merge.at/merge.by/merge.sub_topics 등)와 태그를 남겨 롤백 근거로 사용합니다.
- 충돌이 감지되면 "합치지 않고" 토픽 단위로 스킵하여 안정성을 우선합니다.

2) 메뉴 역할

3) 권장 운영 절차(강력 권장)

Step 0. 테스트 DB 초기화
  • DB 백업/복구에서 "복구 실행"으로 테스트 데이터베이스를 초기화합니다.
  • 테스트 DB에서 먼저 리허설한 뒤 운영 DB에 적용하는 것을 권장합니다.
Step 1. 머지 영향 범위 확인(dry run)
  • 유저 머지에서 A/B 유저를 선택합니다.
  • 기본값은 dry_run 체크(ON) 상태입니다. 이 상태로 먼저 "머지 실행"을 눌러 보고서(카운트)를 확인합니다.
  • p2p 1:1 대화까지 "상대방 화면에서도 B로 보이게" 해야 한다면 migrate_all이 필요합니다(아래 참고).
Step 2. 실제 머지 실행
  • 문제가 없다면 dry_run 체크를 해제(OFF)하고 다시 "머지 실행"합니다.
Step 3. 머지 결과 검증(수동 확인)
  • 머지 완료 후 보고서에 표시되는 버튼을 사용해 A 대화방 목록 보기 / B 대화방 목록 보기로 이동해 정상 동작을 확인합니다.
  • 채팅 보기에서도 유저/토픽/메시지를 직접 확인할 수 있습니다.
Step 4. (선택) 복구(rollback)로 원복 검증
  • 정상 머지가 완료되면, 유저 복구에서 머지된 A 유저가 노출됩니다.
  • 해당 A에서 "복구(rollback)"를 눌러 원복이 정상 동작하는지 확인합니다(테스트 DB에서 권장).

체크리스트(작업 전/후 확인 항목)

작업 전
  • 가능하면 테스트 DB에서 먼저 리허설(도구 → DB 백업/복구로 초기화)
  • 유저 머지에서 A/B가 서로 다른지 확인
  • dry_run ON으로 먼저 실행해서 변경 카운트/스킵 여부 확인
  • migrate_all ON이면 상대방(X) 데이터도 변경될 수 있음을 사전 인지/승인
작업 후(머지 검증)
  • 머지 보고서가 OK인지 확인
  • 보고서의 A 대화방 목록 보기 / B 대화방 목록 보기로 이동해 토픽/메시지가 정상인지 확인
  • 채팅 보기로 추가 확인(필요 시)
작업 후(복구 검증, 테스트 DB 권장)
  • 유저 복구에서 머지된 A가 노출되는지 확인
  • dry_run ON으로 롤백 영향 범위를 먼저 확인 후, 문제 없으면 OFF로 실제 롤백 수행
  • 롤백 후 A/B 대화방 목록을 다시 열어 원복이 반영됐는지 확인

4) P2P 마이그레이션(migrate_all) 설명 요약

이 섹션은 P2P_MIGRATION.md의 내용을 운영 관점에서 요약한 것입니다.
왜 필요한가?
  • Tinode의 p2p 토픽명은 참여자 UID를 인코딩한 규칙 기반 문자열이라, 단순 구독 이동만으로는 상대방(X) 화면에서 계속 p2p(A,X)로 남을 수 있습니다.
  • migrate_all=true는 토픽 자체를 p2p(A,X) → p2p(B,X)로 재구성해서 "상대방도 앞으로 B로 보이게" 하는 방식입니다.
가장 중요한 위험
  • 상대방(X)의 데이터도 변경됩니다. (X의 subscriptions까지 수정)
  • 서비스 정책상 제3자의 대화방/구독 데이터 변경에 해당할 수 있어, 공지/동의/감사 범위 확인이 필요합니다.
무엇을 변경하나?
  • 주요 컬렉션: subscriptions, messages, dellog, (best-effort) topics, 그리고 A의 users.merge 메타
  • 토픽 1건 처리 흐름: 새 토픽명 계산 → 충돌/기존 메시지 존재 여부 검사 → (가능하면) 새 구독 2개(B, X) insert 후 기존 구독 2개(A, X) delete → messages/dellog의 topic을 새 토픽으로 update
왜 "겹치면 합치지 않고 스킵"하나?
  • p2p(B,X)에 이미 메시지가 있으면 seqid/정렬/삭제 범위 정합성이 깨질 수 있어 스킵합니다.
  • subscriptions._id = topic:user라서 새로 만들려는 구독 ID가 이미 존재하는 경우도 스킵합니다.
  • 즉, 안전하게 "병합"이 아니라 "이동"만 수행하며, 병합이 필요한 경우는 별도 정책/UX/정합성 설계가 먼저 필요합니다.
롤백은 어떻게 되나?
  • A의 users.merge.p2p_topics에 기록된 목록을 단일 진실 소스로 사용해, /v1/rollback에서 p2p 토픽을 되돌립니다.
  • use_cutoff=true면 (설정된 경우) UPDATED_AT_FIELD와 merge 시각을 기준으로 이번 작업으로 바뀐 것만 되돌리려고 시도합니다.
언제 켜야 하나?
  • p2p 1:1 대화에서 "상대방 화면에서도 B로 보여야" 하는 요구가 있을 때만 켜는 것을 권장합니다.
  • 그룹 채팅(grp/chn/joi)은 보통 기본 merge 동작(구독 이동 + messages.from 변경)만으로도 충분합니다.