<?xml version="1.0" encoding="UTF-8"?>
<rss version="2.0">
  <channel>
    <title>고양이중독</title>
    <link>https://omty.tistory.com/</link>
    <description>고양이를 좋아하고 뭐든지 공유하는 것을 좋아하는 사람입니다.</description>
    <language>ko</language>
    <pubDate>Fri, 31 Jul 2026 20:02:26 +0900</pubDate>
    <generator>TISTORY</generator>
    <ttl>100</ttl>
    <managingEditor>고양이중독</managingEditor>
    <image>
      <title>고양이중독</title>
      <url>https://tistory1.daumcdn.net/tistory/2890437/attach/5c4e72f8ba744907995b8d2669337318</url>
      <link>https://omty.tistory.com</link>
    </image>
    <item>
      <title>[MySQL] XA 트랜잭션으로 인해 Kill 되지 않는 트랜잭션 이슈</title>
      <link>https://omty.tistory.com/66</link>
      <description>Aurora MySQL 운영 중 특정 1 건의 Row 데이터를 업데이트했을 경우 Lock으로 인해 데이터가 업데이트되지 않는 문제가 발생했습니다. 어떤 방법으로 XA 트랜잭션을 식별 및 처리하였는지 공유해보겠습니다.
&amp;nbsp;
운영 중인 환경은 Aurora 3 버전입니다.
문제 해결을 위해 가장 먼저 실행 중인 프로세스 리스트를 확인해보지만 문제가 될만한 프로세스는 확인되지 않았습니다. 좀 더 세부적인 트랜잭션 확인을 위해 information_sch..</description>
      <category>DataBase/MySQL</category>
      <category>MySQL XA</category>
      <category>MySQL XA 트랜잭션</category>
      <category>XA ROLLBACK</category>
      <category>XA 분산트랜잭션</category>
      <category>XA 트랜잭션 처리</category>
      <author>고양이중독</author>
      <guid isPermaLink="true">https://omty.tistory.com/66</guid>
      <comments>https://omty.tistory.com/66#entry66comment</comments>
      <pubDate>Fri, 25 Nov 2022 16:41:08 +0900</pubDate>
    </item>
    <item>
      <title>[MySQL] 과하게 작게 설정된 innodb_buffer_pool_size</title>
      <link>https://omty.tistory.com/65</link>
      <description>이번에 Aurora MySQL을 운영하면서 겪기 쉽지 않은 상황을 경험하여 해당 내용을 공유하겠습니다.&amp;nbsp;MySQL innodb 엔진의 경우 innodb_buffer_pool_size 값은 성능에 큰 영향을 미칠 수 있습니다.
&amp;nbsp;
서비스에서 운영하는 DB 스펙은 아래와 같습니다.

db.r5.4xlarge
vCPU 16 / RAM 128

엄청나게 많이 기록되고 있는 Slow Query와 IOPS 수치와 50GB의 가용 메모리... 문제..</description>
      <category>DataBase/MySQL</category>
      <category>MySQL Buffer Pool</category>
      <category>mysql buffer pool size 증가</category>
      <category>mysql 버퍼풀 성능</category>
      <category>mysql 버퍼풀 튜닝</category>
      <author>고양이중독</author>
      <guid isPermaLink="true">https://omty.tistory.com/65</guid>
      <comments>https://omty.tistory.com/65#entry65comment</comments>
      <pubDate>Mon, 31 Oct 2022 19:57:18 +0900</pubDate>
    </item>
    <item>
      <title>[RedShift] 사용자 및 권한 관리 (feat. 계정 삭제시 오류)</title>
      <link>https://omty.tistory.com/64</link>
      <description>개요
Redshift는 사용자와 권한을 관리하는 방법이 조금 복잡하여 권한 부여 및 삭제에서 삽질한(?) 내용을 공유해보겠습니다.&amp;nbsp;
&amp;nbsp;
&amp;nbsp;
사용자와 그룹
Redshift에서는 Postgres와 조금 차이가 있는데 접근제어를 위해 role의 개념을 사용하지 않고 사용자와 그룹을 사용합니다. 그리고 아래의 규칙을 가집니다.

사용자만 그룹의 하위에 속할 수 있습니다. 즉, 그룹은 다른 그룹에 속할 수 없습니다.
그룹이 아닌 사용자..</description>
      <category>DataBase/Redshift</category>
      <category>Redshift 계정</category>
      <category>Redshift 계정 삭제</category>
      <category>Redshift 계정 삭제 오류</category>
      <category>Redshift 권한 제거</category>
      <category>Redshift 권한 조회</category>
      <author>고양이중독</author>
      <guid isPermaLink="true">https://omty.tistory.com/64</guid>
      <comments>https://omty.tistory.com/64#entry64comment</comments>
      <pubDate>Fri, 22 Jul 2022 15:23:37 +0900</pubDate>
    </item>
    <item>
      <title>[MySQL] 복제 구성을 위한 바이너리 로깅 형식</title>
      <link>https://omty.tistory.com/63</link>
      <description>개요
MySQL의 복제 데이터 포맷에는 어떤 방식이 있는지 알아보고 간단한 테스트를 통해 유의점을 확인해보겠습니다.
&amp;nbsp;
복제 포맷
MySQL의 복제 포맷에는 Statement, Row, Mixed 3가지 형태가 있습니다. Statement 방식은 MySQL 바이너리 로그 도입 당시부터 존재한 복제 포맷이며 5.7.7 이후 버전 부터는 Row 형태가 기본 포맷으로 변경되었습니다.

Statement : 명령문 기반의 로깅 방식
Row : 행 기반..</description>
      <category>DataBase/MySQL</category>
      <category>Mysql bin_format</category>
      <category>MySQL ROW 포맷</category>
      <category>MySQL 바이너리 로깅</category>
      <category>MySQL 복제 구성</category>
      <category>MySQL 복제 모드</category>
      <author>고양이중독</author>
      <guid isPermaLink="true">https://omty.tistory.com/63</guid>
      <comments>https://omty.tistory.com/63#entry63comment</comments>
      <pubDate>Fri, 3 Jun 2022 19:15:44 +0900</pubDate>
    </item>
    <item>
      <title>[MySQL] Docker-compose를 이용한 초간단 서버 구성</title>
      <link>https://omty.tistory.com/61</link>
      <description>개요
Docker-Compose로 간단하게 MySQL 테스트 환경을 구성해보도록 하겠습니다. 사전에 Docker 및 Docker-Compose에 대한 이해가 필요합니다.
&amp;nbsp;
테스트 환경

Centos7
Docker 20.10.14
Docker-compose 1.29.2

&amp;nbsp;
구성
docker 구성을 위한 디렉토리를 생성합니다.
$ mkdir mysql_test
$ cd mysql_test
&amp;nbsp;
컨테이너 내의 파일을 동기화할 디렉..</description>
      <category>DataBase/MySQL</category>
      <category>docker mysql</category>
      <category>MySQL Docker-compose</category>
      <category>MySQL 간단 설치</category>
      <author>고양이중독</author>
      <guid isPermaLink="true">https://omty.tistory.com/61</guid>
      <comments>https://omty.tistory.com/61#entry61comment</comments>
      <pubDate>Fri, 20 May 2022 19:00:30 +0900</pubDate>
    </item>
    <item>
      <title>[MySQL] 클러스터 인덱스 미생성 테이블</title>
      <link>https://omty.tistory.com/60</link>
      <description>개요
MS-SQL에서는 클러스터 인덱스가 없는 힙 테이블이란 개념이 존재했었는데 MySQL은 테이블 생성 시 내부적으로 클러스터 인덱스가 생성되어 어떤 경우에 해당 인덱스가 생성되는지 알아보겠습니다.
&amp;nbsp;
&amp;nbsp;
클러스터 인덱스가 없는 테이블 생성
MySQL의 InnoDB의 경우 Primary Key. 즉 클러스터 인덱스가 없는 테이블을 생성할 경우 칼럼이 NOT NULL로 구성된 UNIQUE KEY가 있을 경우 클러스터로 사용합니다. 별도..</description>
      <category>DataBase/MySQL</category>
      <category>GEN_CLUST_INDEX</category>
      <category>MySQL 클러스터 인덱스 없음</category>
      <category>MySQL 힙테이블</category>
      <author>고양이중독</author>
      <guid isPermaLink="true">https://omty.tistory.com/60</guid>
      <comments>https://omty.tistory.com/60#entry60comment</comments>
      <pubDate>Thu, 19 May 2022 01:38:44 +0900</pubDate>
    </item>
    <item>
      <title>[MySQL] Innodb Change Buffer를 통한 보조 인덱스 I/O 개선</title>
      <link>https://omty.tistory.com/59</link>
      <description>개요
MySQL InnoDB에는 보조 인덱스 I/O 성능 향상을 위한 체인지 버퍼가 존재합니다. 해당 버퍼를 통해 어떻게 보조 인덱스 I/O 최적화가 진행되는지 알아보겠습니다.
&amp;nbsp;
체인지 버퍼
체인지 버퍼는 보조 인덱스 페이지가 버퍼 풀에 없을 때 변경 사항을 캐시하는 특수한 데이터 구조입니다. INSERT, UPDATE 등 DML 작업으로 인해 발생할 수 있는 버퍼링된 변경 사항은 추후 읽기 작업에 의해 페이지가 버퍼 풀에 로드될 때 병합됩니..</description>
      <category>DataBase/MySQL</category>
      <category>InnoDB Chage Buffer</category>
      <category>MySQL Chage Buffer</category>
      <category>MySQL 체인지 버퍼</category>
      <category>보조 인덱스 IO</category>
      <category>보조인덱스 성능 향상</category>
      <author>고양이중독</author>
      <guid isPermaLink="true">https://omty.tistory.com/59</guid>
      <comments>https://omty.tistory.com/59#entry59comment</comments>
      <pubDate>Thu, 19 May 2022 01:11:59 +0900</pubDate>
    </item>
    <item>
      <title>[MySQL] Innodb Buffer Pool 구조 및 캐시 전략</title>
      <link>https://omty.tistory.com/58</link>
      <description>개요
MySQL은 빠른 성능을 위해 메모리 영역의 Buffer Pool을 사용합니다. 해당 영역의 구조 및 동작 방식에 대해 알아보도록 하겠습니다.&amp;nbsp;
&amp;nbsp;
Buffer Pool이란
Innodb 엔진에서 테이블이나 인덱스 데이터를 캐시 하는 메모리 영역을 말합니다. 데이터를 메모리에서 직접 액세스 하여 속도가 I/O 작업 시 속도가 빠릅니다.
&amp;nbsp;
LRU 알고리즘
MySQL 캐시 전략은 변형된 LRU(Least Recently Us..</description>
      <category>DataBase/MySQL</category>
      <category>MySQL Buffer</category>
      <category>MySQL Buffer Pool</category>
      <category>MySQL LRU</category>
      <category>MySQL 버퍼풀</category>
      <author>고양이중독</author>
      <guid isPermaLink="true">https://omty.tistory.com/58</guid>
      <comments>https://omty.tistory.com/58#entry58comment</comments>
      <pubDate>Tue, 17 May 2022 21:13:17 +0900</pubDate>
    </item>
    <item>
      <title>[Aurora] ZDP(제로 다운타임) 엔진 업그레이드</title>
      <link>https://omty.tistory.com/57</link>
      <description>개요
Aurora DB 엔진 업그레이드 시 Aurora 2 일부 버전, Aurora 3 전체 버전에서 특정 상황을 충족할 경우 다운타임 없이 업그레이드가 가능합니다. 어떤 경우에 ZDP 가 동작하는지 알아보겠습니다.
&amp;nbsp;
업그레이드 전 고려 사항
허용 가능한 가동 중지 시간
업그레이드 시 다운타임으로 인해 서비스가 중단될 수 있기 때문에 실제 서비스에 허용 가능한 중단 시간을 파악해야 합니다.
&amp;nbsp;
특정 버그 또는 새로운 기능이 업그레이드..</description>
      <category>DataBase/MySQL</category>
      <category>Aurora ZDP</category>
      <category>Aurora 무중단 업그레이드</category>
      <category>Aurora 엔진 업그레이드</category>
      <category>Aurora 제로 다운 타임</category>
      <author>고양이중독</author>
      <guid isPermaLink="true">https://omty.tistory.com/57</guid>
      <comments>https://omty.tistory.com/57#entry57comment</comments>
      <pubDate>Mon, 16 May 2022 23:58:23 +0900</pubDate>
    </item>
    <item>
      <title>[Aurora] 스토리지 용량 축소를 통한 비용 절감</title>
      <link>https://omty.tistory.com/56</link>
      <description>개요
Aurora MySQL 2.09 미만 버전의 경우 CloudWatch의 용량과 INFORMATION_SCHEMA의 통계 용량의 상당한 차이가 발생하는 경우가 있어 버전 업그레이드 후 용량을 테스트해보았습니다.
&amp;nbsp;
문제
CloudWatch의 사용된 바이트는 약 143GB인데 INFORMATION_SCHEMA는 약 58GB 입니다.

Aurora의 경우 클러스터 볼륨은 128TB 까지 확장될 수 있으며 Aurora 클러스터 볼륨에 대해 사용한..</description>
      <category>DataBase/MySQL</category>
      <category>Aurora MySQL 용량</category>
      <category>Aurora 스토리지 비용</category>
      <category>Aurora 스토리지 축소</category>
      <author>고양이중독</author>
      <guid isPermaLink="true">https://omty.tistory.com/56</guid>
      <comments>https://omty.tistory.com/56#entry56comment</comments>
      <pubDate>Mon, 16 May 2022 23:38:05 +0900</pubDate>
    </item>
  </channel>
</rss>