[DATABASE] Replication

데이터베이스 성능 최적화와 관리 효율성을 높이기 위한 다양한 전략은 아래와 같이 다양하다.

1) Denormalization(반정규화)

2) Partitioning(파티셔닝)

3) Sharding(샤딩)

4) Replication(리플리케이션)

5) Clustering(클러스터링)

 

이번 시간에는 리플리케이션에 대해 알아보자.

 

1. Replication(리플리케이션)

1-1. 배경

아주 단순한 Database를 구성할 때는 아래 그림처럼 하나의 서버와 하나의 Database를 구성하게 된다.

하지만 사용자는 점점 많아지고 Database는 많은 Query를 처리하기엔 너무 힘든 상황이 오게 된다.

Query의 대부분을 차지하는 `select`를 어느 정도 해결하기 위해 Replication이라는 방법이 나오게 되었다.

 

1-2. 데이터베이스 리플리케이션이란?

`데이터베이스 리플리케이션(Replication)`은 실시간 복제본 데이터베이스 서버를 운용하는 것을 의미한다.

두 개 이상의 DBMS 시스템을 나눠서 동일한 데이터를 저장한다.

 

서버의 용어는 아래 표와 같이 매핑이 되는데, 한 row 단위로 묶어서 한 쌍으로 사용된다고 보면 된다.

예를 들어 Mater 서버는 Slave 서버라는 용어와 한 쌍이다.

기준이 되는 서버	마스터 서버와 동일한 내용을 가지는 또 다른 서버
Master	Slave
Primary	Secondary
Leader	Replica

 

여기서 Master-Slave 쌍은 구시대적인 용어라고 하여 잘 쓰지 않는 추세를 보이고 있다.

 

어플리케이션은 데이터베이스에 SQL 명령을 보내 데이터를 삽입/변경/삭제하게 되는데, 

Primary 서버는 SQL 명령을 수신하면 그 SQL 명령을 Secondary 서버에도 똑같이 보낸다.

이렇게 되면 Primary 서버와 Secondary 서버의 데이터가 동일한 상태로 유지된다.

 

Primary DBMS에는 데이터의 수정사항을 반영만하고, Replication 하여 Secondary DBMS에 실제 데이터를 복사한다.

Secondary 서버는 아래 그림과 같이 1개일수도 있지만, 여러 개로 이루어질 수도 있다.

 

1-2. 데이터베이스 리플리케이션의 목적

1) DB 백업

데이터베이스 리플리케이션은 기본적으로 `데이터 안정성`을 위함이다.

 

어떠한 원인으로 인해 데이터가 손상되었을 때, 가장 기초적인 대처는 가장 최신의 백업본을 복구하여 사용하는 것이다.

하지만 백업본을 이용한 대처는 큰 단점이 있다.

데이터 백업을 주기적으로 자동 업데이트 되도록 설정했다고 하더라도 백업된 시간과 장애가 발생한 시간 사이의 데이터 변경 사항들은 모두 소실된다.

 

Secondary 서버는 `아주 약간의 딜레이가 있긴 하지만` 거의 실시간으로 Primary 서버와 동일한 데이터를 갖고 있기 때문에, 장애 복구 시 데이터 소실이 최소화된다.

Secondary 서버는 Primary 서버로 승격이 가능하기에, Primary 서버로 승격시켜 기존 Primary 서버를 대체하는 방식으로 복구가 진행된다.

Secondary 서버를 Primary 서버로 승격한 후, 이 새로운 Primary 서버에 대한 Secondary 서버를 생성하면 복구가 완료된다.

 

3) 읽기전용 DB로 트래픽 분산

Secondary 서버는 기본적으로 `읽기전용`으로 운용된다.

이러한 특성을 활용하면 데이터베이스 서버의 부하를 줄이고, 데이터베이스를 Access하는 어플리케이션의 동작 성능을 개선할 수 있다.

 

어플리케이션 개발 시, 데이터의 Access 시간이 중요한 `읽기쓰기` SQL 작업은 `Primary 서버`에 접속하여 수행하고,

데이터의 Access 시간이 중요하지 않는 `읽기전용` 작업은 `Secondary 서버`에 접속하여 수행하도록 한다.

예를 들어, 서비스 어플리케이션은 항시 Primary 데이터베이스 서버에서 데이터를 조작하도록 하고,

`많은 부하가 유발될 수 있는` 관리자 사이트의 특정 내역 조회 기능에 대해서는 Secondary 데이터베이스 서버로부터 데이터를 가져오도록 하는 것이다.

 

이렇게 하면, 큰 규모의 데이터에서 자료를 추출하게 될 때 발생하는 데이터베이스 서버 부하를 Secondary 서버가 대신 받아 처리하기에 Primary 서버가 받게 되는 부하가 크게 줄어든다.

 

1-4. 복제는 어떻게 일어나나?

1) 바이너리 로그 기반 복제

`바이너리 로그`란 모든 변경사항(이벤트)이 로그 파일에 순서대로 기록되는 것을 말한다.

 

WAS에서 INSERT, UPDATE, DELETE와 같은 요청을 보내면 바이너리 로그에 기록되고, 변경사항이 DB에 전달되는 것이다.

 

따라서 리플리카는 Primary 서버의 바이너리 로그를 Secondary 서버에 복제하는 방식으로 진행하게 된다.

 

Primary 서버에 이벤트가 일어나서 바이너리 로그에 기록이 되면,

이 이벤트를 Secondary 서버가 자신의 로컬디스크에 저장한 뒤, 이 이벤트를 읽어 자신의 데이터 파일에 반영한다.

 

 

참고: 바이너리 로그

바이너리 로그의 내용은 바이너리 형식이기 때문에 직접 읽을 수 없다.

아래 내용은 `mysqlbinlog` 유틸리티를 사용하여 바이너리 로그 파일을 해석한 예시 출력의 간략화된 형태이다.

 

자세한 내용은 아래에서 다시 살펴보도록 하자.

# at 4
#200123 14:22:33 server id 1 end_log_pos 123 CRC32 0xabcdef12 Start: binlog v 4, server v 5.7.21-log created 200123 14:22:33
BINLOG ' gxB7XxMBAAAAdwAAAHsAAAAAAAQANS43LjIxLWxvZwAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAACzElxYEEgNAAgAEgAEBAQEEgAAVHhIYkc= gxB7Xx4BAAAALQAAAJwAAAAAAAQABTEwLjEuMzYtTWFyaWFEQAAAAAAAAAAAAAAAAAAAAAAAKrDs
Yf8= '/*!*/;
#at 123
#200123 14:22:34 server id 1 end_log_pos 456 CRC32 0xabcdef13 Table_map: `test`.`example` mapped to number 64
#200123 14:22:34 server id 1 end_log_pos 789 CRC32 0xabcdef14 Write_rows: table id 64 flags: STMT_END_F

BINLOG ' IHB7XxMBAAAALwAAAKwAAAAAAAQAAHRlc3QAB2V4YW1wbGUAAwADCAgPAhAIAf8= IHB7Xx4BAAAAIQAAAMwAAAAAAAQAAgAC//Q= '/*!*/;
### INSERT INTO `test`.`example`
### SET
### @1=1
### @2='Hello, world!'
### @3='2020-01-23 14:22:34'

 

2) 동기식과 비동기식

데이터베이스에서 데이터를 복제하는 방식은 크게 동기 방식과 비동기 방식이 있다.

 

(1) 동기 방식

Primary 노드에 데이터 변경이 발생할 경우 Secondary 노드까지 (동시에) 적용되는 것을 보장하는 방식

Primary 노드에 장애가 발생하더라도 (데이터 정합성 문제 없이) Secondary 노드를 이용하여 서비스를 이어갈 수 있다.

 

(2) 비동기 방식

Primary 노드의 변경과 Secondary 노드로의 적용이 시차를 두고 동기화되는 방식

비동기 방식은 Primary 노드에서 변경된 데이터가 아직 Secondary 에 반영되지 못한 상황일 수 있기 때문에

곧 바로 Secondary 노드를 이용하여 서비스를 이어갈 경우 데이터 정합성에 문제가 발생할 수 있다.

(3) 반동기(Semi-Sync) 방식

동기와 비동기 방식의 장점을 적절히 취하는 방식

(MySQL 도 Semi-Sync Replication 을 Plug-in 방식으로 사용할 수 있다.)

 

이렇게 동기/비동기의 관점 뿐 아니라 Replication 을 구현하는 방식은 아주 다양할 수 있다.

 

같은 동기 방식이라도 모든 변경 데이터마다 Secondary 의 적용에 대한 응답을 수신하는 방식이 있을 수 있고, 

또는 트랜잭션 도중 발생되는 변경에 대해서는 비동기로 작동하다가 Commit 단계에서만 Slave 의 응답을 수신하도록 할 수도 있다.

 

비동기 방식의 경우에도 파일의 로그를 별도의 스레드(프로세스)가 읽어서 Secondary 로 전송하는 방식이 있을 수 있고,

트랜잭션을 수행하는 스레드가 직접 Secondary 로 변경 사항을 전송하도록 구현될 수도 있을 것이다.

 

1-5. MySQL의 Replication

MySQL은 기본적으로 `비동기 복제 방식`을 사용하고 있으며, 반동기 복제 방식도 지원한다.

 

Primary 노드에서 변경되는 데이터에 대한 이력을 바이너리 로그에 기록하면 Primary 서버의 바이너리 로그 덤프 스레드가 비동기적으로 읽어서 Secondary 쪽으로 전송하는 방식이다.

 

1) MySQL에서 Replication을 수행하기 위해 사용하는 요소

- Primary 에서의 변경을 기록하기 위한 `Binary Log`
- Binary Log 를 읽어서 Secondary 쪽으로 데이터를 전송하기 위한 `바이너리 로그 덤프 Thread`
- Secondary 에서 데이터를 수신하여 Relay Log 에 기록하기 위한 `레플리케이션 I/O Thread`
- Relay Log 를 읽어서 해당 데이터를 Secondary 에 Apply(적용)하기 위한 `레플리케이션 SQL Thread`

 

2) 동작방식

 

(1) 초기설정

1. 기본 설정

   먼저, 복제를 위한 MySQL 서버가 Primary와 Secondary로 설정되어야 한다.

   Primary 서버는 데이터의 원본을 보유하고, Secondary 서버는 이 원본 데이터의 복사본을 유지한다.

2. 바이너리 로그 활성화

    Primary 서버에서는 바이너리 로깅(Binary Logging)이 활성화되어야 한다.

    이 로그에는 모든 데이터 변경(DDL/DML) 사항이 기록되며, 이는 Secondary에 복제될 정보를 담고 있다.

3. 로그 위치와 데이터 동기화

    Secondary는 Primary에 연결하여 처음에 전체 데이터를 복사한다.

    이후, Primary의 바이너리 로그 파일과 포지션(position)을 기반으로 변경사항을 동기화한다.

포지션(position)
특정 이벤트가 기록된 위치로, 해당 이벤트가 시작되는 바이트 오프셋을 뜻함

예를 들어, Primary 서버의 바이너리 로그 파일이 mysql-bin.000001이고, Secondary가 이 파일의 1203 바이트 위치까지 변경사항을 적용했다면, Secondary의 복제 메타데이터에는 이 파일 이름과 포지션(1203)이 기록된다.
복제가 재개될 때, Secondary는 mysql-bin.000001 파일의 1204 바이트 위치부터 데이터를 읽기 시작하여, 새로운 변경사항을 자신의 데이터베이스에 적용한다.

 

(2) 복제 수행

1. 클라이언트(Application)에서 Commit 수행

 

2. 트랜젝션 처리 스레드는 Primary 스토리지 엔진에게 해당 트랜젝션에 대한 Prepare(Commit 준비) 수행

 

3. Commit을 수행하기 전, 바이너리 로그 덤프 스레드를 통해 바이너리 로그에 변경사항 전송

    Primary 서버에서 발생하는 모든 변경사항은 바이너리 로그에 기록된다.

    이 로그는 Primary 서버에 있는 바이너리 로그 덤프 스레드를 통해 Secondary 서버로 전송된다.

 

4. Primary 스토리지 엔진에게 트랜젝션 Commit 수행

 

5. Primary 서버의 바이너리 로그 덤프 Thread는 비동기적으로 바이너리 로그를 읽어서 Secondary로 전송

6. Secondary의 레플리케이션 I/O 스레드를 통해 Primary 서버의 바이너리 로그 내용을 수신하고, 릴레이 로그에 저장

    Secondary 서버는 레플리케이션 I/O 스레드를 통해 받은 바이너리 로그 내용을 자신의 릴레이 로그(Relay Log)에 저장한다.

    `릴레이 로그`는 Primary 서버에 있는 바이너리 로그의 복사본이라고 볼 수 있다.

    따라서 기록하는 방식은 Primary의 바이너리 로그와 동일하다.

7. 레플리케이션 SQL 스레드 실행

    Secondary에서는 SQL 스레드가 릴레이 로그를 읽고, 그 안에 기록된 변경사항을 Secondary의 데이터베이스에 적용한다.

    이 과정을 통해 Primary와 Secondary의 데이터베이스가 동기화된다.

8. 오류 관리와 복구

    복제 중에 발생할 수 있는 오류(예: 네트워크 문제, SQL 오류 등)를 감지하고 처리한다.

    필요한 경우, Secondary는 Primary와의 동기화를 재개할 수 있도록 복구 메커니즘이 있다.

 

3) 복제 타입

소스 서버의 바이너리 로그에 기록된 변경 내역들을 식별하는 방식에 따라 구분

 

(1) 바이너리 로그 파일 위치 기반 복제

'소스 서버의 로그 파일명 + offset'으로 식별한다.

하지만 이 방식은 Primary 서버에서만 유효한 식별 방법이라는 문제가 있다.

 

Primary 서버에 문제가 생겨 다른 Secondary 서버가 Primary 서버로 승격된 경우, 복제에 참여하는 다른 서버들은 이 위치를 다시 찾아야하기 때문에 복구에 시간이 걸린다.

 

즉, 동일한 이벤트가 레플리카 서버에서도 동일한 파일명의 동일한 위치에 저장된다는 보장이 없다.

 

따라서 MySQL 5.6 버전부터는 글로벌 트랜젝션 ID 기반 복제가 도입되었다.

 

(2) 글로벌 트랜젝션 ID(GTID) 기반 복제

'서버가 속한 복제 토폴로지에서 고유한 값'으로 식별한다.

GTID(Global Transaction Identifier)
MySQL에서 트랜잭션을 고유하게 식별하기 위해 사용되는 식별자

각 GTID는 복제 환경 내에서 한 번만 발생하며, 이를 통해 Primary와 Secondary 서버 간의 트랜잭션을 일관되고 정확하게 동기화할 수 있음

GTID는 'UUID:숫자' 형식을 가지며, 여기서 UUID는 트랜잭션이 발생한 Primary 서버를 고유하게 식별하는 값이고, 숫자는 해당 서버에서의 트랜잭션 순서를 나타냄
예를 들어, '3E11FA47-71CA-11E1-9E33-C80AA9429562:23'는 특정 Primary 서버에서 23번째 트랜잭션을 나타냄

GTID를 사용하면, Secondary는 Primary에서 실행된 트랜잭션을 놓치거나 중복 없이 순차적으로 적용할 수 있으며, 이는 특히 장애 복구나 복제 서버의 재구성 시 유용함

 

 

글로벌 트랜젝션 ID는 복제에 참여한 모든 데이터베이스들이 동일하게 고유한 식별값을 가진다.

 

따라서 소스 서버에서 장애가 발생하여 Secondary 서버A가 새로운 Primary 서버가 되더라도 문제 없이 작동할 수 있다.

 

4) 복제 데이터 포맷(바이너리 로그 포맷)

Statement 기반, Row 기반, Mixed 기반으로 3가지 방식이 있다.

 

(1) Statement 기반 방식

실행된 SQL 문을 바이너리 로그에 그대로 저장하는 방식이다.

 

장점

- 여러 개의 데이터를 수정하는 쿼리여도 바이너리 로그에 SQL문 하나만 기록되기 때문에

   저장 공간에 대한 부담이 감소하고, 빠른 처리가 가능하다.

 

단점

- 비확정적 처리 쿼리의 경우 데이터 동기화 문제가 발생할 수 있다.

   ex) Delete, Update, Order by 절 없이 Limit 사용

- 하나의 트랜잭션 내에서도 각 쿼리가 실행되는 시점마다 데이터 스냅샷이 달라질 수 있다.

- 트랜잭션 격리 수준이 Repeatable-read 이상만 가능하다.

 

즉, 일관되지 않은 데이터가 저장될 위험이 있다.

 

(2) Row 기반 방식

MySQL 5.7.7 버전부터는 Row 기반 바이너리 로그 포멧을 기본으로 사용하고 있다.

 

이 방식은 변경 값 자체가 바이너리 로그에 그대로 저장되는 방식이다.

 

장점

- 모든 트랜잭션 격리 수준에서 사용 가능

 

단점

- 어떤 쿼리들이 넘어왔는지 육안으로 확인 불가능

- 데이터를 대량으로 변경하는 SQL문이 실행될 경우 바이너리 로그 파일 크기가 커질 수 있다.

   -> 위와 같은 단점을 해결하기 위해 MySQL에서는 용량 최적화 방식을 지원한다.

        용량을 최적화 하는 방식으로는 크게 바이너리 `로그 Row 이미지 최적화`와 `바이너리 로그 트랜잭션을 압축하는 방식`이 있다.

<용량 최적화 방식>

(1) 바이너리 로그 Row 이미지
MySQL은 바이너리 로그에 저장되는 로우 이미지의 양을 최적화하기 위해 몇 가지 옵션을 제공한다.
이는 binlog_row_image 설정을 통해 조절할 수 있으며, 다음 세 가지 옵션 중에서 선택할 수 있다.

- FULL: 모든 컬럼의 데이터를 로그한다. 이는 기본값이다.
- MINIMAL: 변경이 있는 컬럼의 데이터만 로그한다. 즉, 변경되지 않은 컬럼은 로그에서 제외하여 용량을 절약할 수 있다.
- NOBLOB: 변경이 있는 컬럼 중에서도 BLOB과 TEXT 타입의 컬럼은 제외하고 로그한다. 이는 데이터 크기가 큰 BLOB 또는 TEXT 컬럼의 변경이 자주 발생하지 않는 경우 유용할 수 있다.

(2) 바이너리 로그 트랜잭션 압축
MySQL 8.0 버전부터는 바이너리 로그 트랜잭션 압축 기능을 도입했다.
이 기능은 크기가 큰 트랜잭션을 압축하여 바이너리 로그의 용량을 줄일 수 있도록 설계되었다.
이를 사용하려면 binlog_transaction_compression 시스템 변수를 ON으로 설정해야 한다.
트랜잭션 압축은 특히 대량의 데이터를 다루는 작업에서 바이너리 로그의 크기를 상당히 줄일 수 있어 유용하다.

 

Row 기반 방식은 데이터를 일관되게 저장하는 가장 안전한 방식이다.

 

(3) Mixed 형식

사용자가 위 두 가지 방식을 커스텀하여 사용하는 방식이다.

 

예를 들어 아래 그림과 같이 쿼리는 Statement 방식을 사용하고, 비확정적 쿼리인 경우 Row 방식을 사용하도록 설정할 수 있다.

 

5) 복제 동기화 방식

앞서, MySQL은 비동기 방식과 반동기 방식을 지원한다고 했다.

MySQL의 복제 방식에 대해 더 자세히 알아보자

 

(1) 비동기 복제

소스 서버가 레플리카 서버에서 변경 이벤트가 정상적으로 전달됐는지 확인하지 않는다.

 

따라서 성능은 빠르지만, 동기화는 보장하지 않는다.

 

 

(2) 반동기 복제

따라서 MySQL 5.5 버전부터는 반동기 방식이 도입되었다.

Primary 서버는 Secondary 서버가 Primary 서버로부터 전달 받은 변경 이벤트를 릴레이 로그에 기록한 후, 응답을 보내면 그때 트랜잭션을 완전히 커밋한다.

 

Secondary 서버에서 Primary 서버로 보내는 ACK는 변경 이벤트를 잘 받았다는 응답이지, 이 이벤트가 Secondary에 적용되었다는 응답을 보내는 것은 아니다.

 

6) 복제 구성 형태(복제 토폴로지)

 

(1) 싱글 레플리카

- 가장 기본적인 복제 형태
- 한 대의 Primary 서버에서 한 대의 Secondary 서버로 데이터를 복제
- 데이터 백업, 읽기 쿼리 부하 분산 등에 사용될 수 있음

 

(2) 멀티 레플리카

- 한 대의 Primary 서버에서 여러 대의 Secondary 서버로 데이터를 복제
- 읽기 부하를 여러 Secondary에 분산시키고, 높은 가용성과 데이터 백업을 제공

 

(3) 체인 복제

- 복제가 연쇄적으로 이루어지는 형태

   ex) Primary가 Secondary A에 데이터를 복제하고, Secondary A는 다시 Secondary B에 데이터를 복제하는 구조
- 데이터 분산과 부하 분산에 유리하지만, 연쇄적 오류 전파나 지연 시간 증가 등의 문제가 발생할 수 있음

 

(4) 듀얼 소스

- 두 대의 Primary 서버가 서로를 Secondary로 설정하여 상호 복제하는 구조
- 데이터가 양방향으로 복제되어, 높은 가용성과 데이터 동기화를 제공하지만, 충돌 관리가 중요한 과제가 됨

 

(5) 멀티 소스

- 여러 대의 Primary 서버에서 한 대의 Secodary 서버로 데이터를 복제하는 구성
- 다양한 데이터 소스를 통합하거나 집계하는 데 유용하며, MySQL 5.7 이상에서 지원
- 데이터 충돌 관리와 복잡성 관리가 주요 고려 사항

 

7) MySQL 복제 고급 설정

(1) Secondary 서버에 장애가 생긴다면? -> Crash-Safe 복제

- 크래시-세이프 복제는 Primary 또는 Secondary 서버가 예기치 않게 중단되었을 때 복제 상태를 보호하고,

   서버 재시작 후 자동으로 복제를 계속할 수 있도록 설계
- 이를 위해 MySQL은 바이너리 로그와 릴레이 로그에 상태 정보를 저장하며, 이 정보를 사용해 중단된 위치에서 복제를 재개할 수 있음

 

(2) 지연된 복제

- 지연된 복제를 사용하면 Secondary가 Primary의 변경 사항을 적용하기 전에 지정된 시간만큼 대기할 수 있음
- 이 기능은 데이터 손실을 방지하거나, Primary에서 발생한 우발적인 오류(예: 잘못된 데이터 삭제)로부터 복구 시간을 확보하기 위해

  사용될 수 있음

 

(3) 멀티 스레드 복제

- 멀티 스레드 복제는 Secondary에서 복제를 처리하는데 여러 스레드를 사용하여 성능을 향상시키는 기능
- MySQL 5.6부터 도입되어, 각 스레드가 다른 데이터베이스의 변경 사항을 병렬로 처리할 수 있게 함으로써

   복제 지연을 줄이고 Secondary의 처리량을 높일 수 있음

 

(4) 필터링된 복제

- 필터링된 복제를 통해 특정 데이터베이스나 테이블의 복제를 제외하거나 포함시키는 것이 가능
- 이는 복제 설정 시 replicate-ignore-db, replicate-do-db, replicate-ignore-table, replicate-do-table 등의 옵션을 통해 구성
- 필터링된 복제는 네트워크 대역폭을 절약하고, Secondary 서버의 부하를 줄이며, 특정 데이터만 복제하고자 할 때 유용

 

 

2. 파티셔닝 VS 샤딩 VS 리플리케이션

---

출처

https://www.youtube.com/watch?v=P7LqaEO-nGU

https://www.coovil.net/db-replication/

데이터베이스 리플리케이션(Replication)이란 무엇인가?

https://nesoy.github.io/articles/2018-02/Database-Replication

Database의 리플리케이션(Replication)이란?

https://velog.io/@zpswl45/DB-Replication-%EA%B0%9C%EB%85%90-%EC%A0%95%EB%A6%AC

[DB] Replication이란 무엇이고 장점과 한계점 정리

https://mangkyu.tistory.com/97

[Database] 리플리케이션(Replication) vs 클러스터링(Clustering)

https://velog.io/@kyeun95/%EB%8D%B0%EC%9D%B4%ED%84%B0%EB%B2%A0%EC%9D%B4%EC%8A%A4-%EB%A6%AC%ED%94%8C%EB%A6%AC%EC%BC%80%EC%9D%B4%EC%85%98-Replication%EC%9D%B4%EB%9E%80

[데이터베이스] 리플리케이션 (Replication)이란?

https://www.youtube.com/watch?v=NPVJQz_YF2A

http://cloudrain21.com/mysql-replication

MySQL - Replication 구조 - Rain.i