> ## Documentation Index
> Fetch the complete documentation index at: https://private-7c7dfe99-vortex-format.mintlify.site/llms.txt
> Use this file to discover all available pages before exploring further.

# 서버 재시작 시 갱신 가능 구체화 뷰는 어떻게 되나요?

> 서버 재시작 시 갱신 가능 구체화 뷰가 한꺼번에 갱신될 수 있는 이유와 이를 하나씩 다시 시작하는 방법을 설명합니다.

<Warning>
  ClickHouse Keeper를 통해 갱신을 조정하지 않는 갱신 가능 구체화 뷰(Refreshable Materialized View)는 마지막 갱신 시점을 기억하지 못하므로, 서버가 준비되자마자 다시 갱신될 수 있습니다. 이러한 뷰가 많거나 대규모 데이터셋을 대상으로 하는 뷰가 있는 서버에서는 부하를 감당하기 가장 어려운 시점에 전체 데이터셋 갱신이 동시에 여러 건 실행될 수 있습니다.
</Warning>

<h2 id="which-views-keep-their-schedule">
  어떤 뷰가 스케줄을 유지합니까?
</h2>

[`Replicated`](/ko/reference/engines/database-engines/replicated) 데이터베이스에 있는 뷰의 갱신(refresh)은 ClickHouse Keeper를 통해 조정됩니다. ClickHouse Cloud에서는 [`Shared`](/ko/cloud/reference/shared-catalog) 데이터베이스도 마찬가지입니다. 두 Cloud 데이터베이스 모두에서 `APPEND` 계열 뷰는 `SETTINGS all_replicas = 1`을 지정하여 조정 대상에서 제외할 수 있습니다. 오픈 소스 ClickHouse 서버에서는 `Replicated` 데이터베이스에서만 이러한 조정이 이루어집니다. 조정되지 않는 뷰는 마지막 갱신 시각을 메모리에만 보관하므로, 일반 스케줄을 사용하는 경우 재시작 후에는 항상 갱신 시점이 이미 지난 상태가 됩니다. `RANDOMIZE FOR`를 사용해도 이러한 갱신은 분산되지 않습니다.

<h2 id="the-extra-refreshes-can-also-duplicate-data">
  추가로 발생하는 갱신은 데이터 중복을 일으킬 수도 있습니다
</h2>

`APPEND` 뷰는 전체 결과를 한 번 더 추가합니다. 조정되지 않은 `APPEND INCREMENTAL` 뷰는 트랜잭션을 지원하는 대상 테이블이 커서를 커밋하지 않았다면 재시작 시 인메모리 커서를 잃습니다. 그 결과 이미 추가했던 행을 다시 처리하게 됩니다.

아래 설명처럼 시작 시점을 단계적으로 분산하면 동시에 실행되는 갱신 수를 제한할 수 있지만, 갱신 자체는 여전히 실행됩니다. `APPEND` 뷰는 어차피 다음 갱신 시점이 되었을 때에만 시작하면 불필요한 추가 작업을 피할 수 있습니다. 반면 커서를 잃은 `APPEND INCREMENTAL` 뷰는 시점을 조정해도 얻는 이점이 없습니다. 언제 다시 실행되든 원본 테이블 전체를 다시 처리하고 그 결과를 추가하기 때문입니다. 따라서 중복된 행을 감당하거나 제거할 수 있을 때까지 중지된 상태로 두십시오.

<h2 id="keep-every-view-stopped-when-the-server-comes-up">
  서버 시작 시 모든 뷰를 중지된 상태로 유지하기
</h2>

서버 자체의 설정 프로필(settings profile)에 [`stop_refreshable_materialized_views_on_startup`](/ko/reference/settings/session-settings/other#stop_refreshable_materialized_views_on_startup)을 설정하십시오. 서버의 설정 프로필은 `system_profile`에 지정된 프로필이며, 지정되지 않은 경우 `default_profile`, 그다음 `default` 순으로 폴백합니다. 이 설정은 실험적 기능입니다:

```xml title="/etc/clickhouse-server/users.d/refreshable_materialized_views.xml" theme={null}
<clickhouse>
    <profiles>
        <default>
            <stop_refreshable_materialized_views_on_startup>1</stop_refreshable_materialized_views_on_startup>
        </default>
    </profiles>
</clickhouse>
```

이 예시에서는 기본 `default` 프로필을 사용합니다. 사용자 정의 `system_profile`을 사용한다면 이를 해당 프로필로 바꾸십시오.

[`SYSTEM STOP VIEWS`](/ko/reference/statements/system#stop-view-stop-views)는 대안이 될 수 없습니다. 이 SQL 문으로 설정한 중지 상태는 재시작하면 유지되지 않기 때문입니다.

<h2 id="start-the-views-one-at-a-time">
  뷰를 하나씩 시작하기
</h2>

[`SYSTEM START VIEWS`](/ko/reference/statements/system#start-view-start-views)는 모든 뷰를 한꺼번에 시작하므로 동일한 부하 급증이 발생합니다. 따라서 각 뷰를 이름으로 지정해 하나씩 시작하고, 해당 뷰의 갱신이 끝난 뒤 다음 뷰를 시작하십시오. 뷰 목록은 [`system.view_refreshes`](/ko/reference/system-tables/view_refreshes)에서 확인할 수 있습니다. ClickHouse Cloud에서는 이 시스템 테이블이 노드 로컬이므로 노드별로 각각 확인하십시오:

```sql theme={null}
SYSTEM START VIEW my_database.my_view;
SYSTEM WAIT VIEW my_database.my_view;
```

뷰를 시작하면 해당 뷰의 스케줄만 재개될 뿐이며, [`SYSTEM REFRESH VIEW`](/ko/reference/statements/system#refresh-view)와 달리 별도의 갱신을 추가로 수행하지 않습니다. 중지된 동안 갱신 시점이 지난 뷰는 이미 스케줄상 기한을 넘긴 상태이므로 시작하는 즉시 갱신되며, [`SYSTEM WAIT VIEW`](/ko/reference/statements/system#wait-view)는 해당 갱신이 실행되는 동안 블로킹됩니다.

[`REFRESH ... DEPENDS ON`](/ko/reference/statements/create/view#refresh-dependencies)으로 지정된 선행 뷰를 기다리는 뷰는 아직 갱신되지 않으므로, 이러한 뷰는 의존 대상 뷰를 먼저 시작한 뒤에 시작하십시오. 순환 의존성에는 이러한 순서가 없으며, 뷰들이 서로 조정되지 않은 상태에서 재시작하면 사이클이 끊어집니다. 이 경우 모든 멤버 뷰를 시작한 다음, 사이클을 처음 생성할 때 사이클을 시작하기 위해 실행했던 것과 동일한 `SYSTEM REFRESH VIEW`를 실행하고 해당 갱신이 완료될 때까지 기다리십시오. 처음 시작할 때 이러한 갱신이 두 번 이상 필요했던 그래프라면 같은 갱신들을 다시 실행해야 합니다. 다른 멤버를 트리거하면 사이클이 유휴 상태로 남을 수 있는데, 뷰는 모든 선행 뷰가 갱신된 후에야 재개되기 때문입니다. 일단 트리거되면 사이클은 자체적으로 갱신되므로, 뷰를 하나씩 시작하는 절차는 트리거 시점에서 끝납니다.

<h2 id="what-this-means-for-your-automation">
  자동화에 미치는 영향
</h2>

이 설정이 적용된 동안 예기치 않은 재시작이 발생하면 모든 갱신 가능 구체화 뷰(refreshable materialized view)가 중지된 상태로 남으며, 새로 생성한 뷰도 시작하기 전까지는 갱신되지 않습니다. 단, 갱신이 조정(coordinated)되지 않는 뷰에는 `RESTORE`가 예외로 적용됩니다. `RESTORE`는 복원 대상에 포함된 이러한 뷰를 모두 시작하며, 이때 해당 뷰는 곧바로 예정 시각을 넘긴 상태가 되어 소스 데이터를 다시 처리할 수 있습니다. 조정되는 뷰는 복원 시 시작되지 않으므로 직접 시작하기 전까지 중지된 상태로 유지됩니다. 서버를 재시작하고 뷰를 생성하는 자동화가 뷰 시작까지 담당하도록 구성하십시오.