반응형
시스템 계정과 일반 계정SYSTEM_USER 권한을 가지고 있느냐 없느냐에 따라 시스템 계정과 일반 계정으로 구분된다.시스템 계정은 DB 서버 관리자(DBA)를 위한 계정이고 일반 계정은 개발자를 위한 계정이다.시스템 계정은 다음과 같이 DBMS 관리와 관련된 중요 작업을 수행할 수 있는 권한이 있다.데이터베이스 관리 작업일반 계정 관리다른 세션 또는 그 세션에서 실행 중인 쿼리 강제 종료참고로 MySQL 서버에는 다음과 같이 내장된 계정들이 있다.SELECT user, host, account_locked FROM mysql.user WHERE user LIKE 'mysql.%';root@localhost를 제외한 위 3개의 계정은 내부적으로 다음과 같은 목적으로 사용된다. mysql.infoschem..
시스템 변수 (글로벌, 세션)시스템 변수는 MySQL 서버의 설정과 동작을 제어하는 변수들이다.MySQL 서버는 이러한 값이 설정된 파일 my.cnf(또는 my.ini)을 읽어 작동 방식, 메모리, 성능, 보안 등을 초기화한다. 시스템 변수 값을 확인하려면 다음과 같이 MySQL 서버에서 조회할 수 있다.SHOW VARIABLES; 시스템 변수(설정) 값이 어떻게 MySQL 서버와 클라이언트에 영향을 미치는지 판단하기 위해선다음과 같이 글로벌, 세션 변수를 구분할 수 있어야한다.GLOBAL 변수 : MySQL 서버에서 단 하나의 값을 가지며, 시스템에 영향을 미치는 변수이다.SESSION 변수 : 각 세션에만 적용되는 값으로 커넥션 단위로 값을 변경할 수 있다. 이제 시스템 변수에 대해 알아보자.시스템 ..
다음과 같은 Server - DB 아키텍처가 있다고 가정해보자.Source / Replica 구조의 Replication 통해 가용성과 읽기/쓰기 작업의 부하 분산을 확보했다.Replication에 대해 알아보고 싶다면 아래 포스팅을 참고하자.2024.11.09 - [◼ CS 기초 지식/[데이터베이스]] - [MySQL] DB 레플리케이션에 대해 알아보자. 하지만 데이터는 지속적으로 축적될 것이고 10억건의 데이터가 쌓였을 때도 문제가 없을까?인덱싱을 적절히 적용한다 하더라도 인덱스도 디스크 용량을 먹고 디스크 용량에도 제한이 있다.Scale Up에도 한계가 있는 것이다. 이 문제를 해결할 수 있는 파티셔닝과 샤딩에 대해 한번 알아보자.Partitioning (파티셔닝)테이블을 더 작은 테이블들로 쪼개는..
레디스를 캐시로 잘 활용하기 위해서는 어떤 캐싱 전략을 적절히 도입하느냐에 따라 다르다.이 적절히라는 말은 캐싱 전략을 데이터의 특성과 엑세스 패턴을 잘 고려해 적용하냐는 것이다.어떤 캐싱 전략들이 있는지 한 번 알아보고 자신의 목적에 맞는 캐싱 전략을 선택할 수 있도록 하자. Redis에 대해 알아보고 싶다면 아래 포스팅을 참고하자.2023.09.11 - [◼ CS 기초 지식/[데이터베이스]] - [Redis] 레디스란? 특징, 활용예시, 비교 정리읽기 전략 Look Aside 전략1. cache에서 원하는 cache 데이터가 있는지 조회 (Cache Hit)2. 없다면 DB에서 조회 (Cache Miss)3. DB에서 조회한 데이터를 cache에 업데이트 데이터를 반복적으로 읽는 작업이 많을 때 사용..
DB Replication(레플리케이션)이란?Replication이란 번역하면 ‘복제’라는 뜻으로 DB를 복제한다는 뜻이다.기준이 되는 서버를 Source(원본) 서버라 하고, Source 서버와 동일한 내용을 갖는 또 다른 서버를 Replica(복제본)라 한다.즉, DB를 복제해서 여러 대의 DB 서버에 저장하는 방식이다.위는 Replication 기본 형태로 Source는 쓰기 작업만, Replica는 읽기 작업만 수행하도록 구성한다.(이외에도 다양한 Replication 방식이 있는데 ‘MySQL Replication 구성 형태’ 목차에서 설명한다.) - 참고로 기존에는 Master/Slave라는 용어를 사용해왔지만 위키백과에서 다음과 같은 문제로 Source/Replica와 같은 용어가 채택되고 ..
왜 저장 순서와 다르게 조회가 되지..? (MySQL 시간 타입의 정밀도)현재 진행하고 있는 프로젝트에서 저장된 순서데로 조회가 되길 기대했던 기능이 있었다.저장된 순서는 아래의 createdAt 필드를 사용해 오름차순으로 구분했다.알림 1을 저장하고, 알림 2를 저장하면 createdAt 기준으로 조회시 [알림1, 알림2] 순서로 조회가 되야 하는데의도와 다르게 [알림2, 알림1]이 조회되고 있었다.뭐가 문제였을까 ? 기본적으로 나노초가 포함되어 시간이 저장될 것을 기대했지만 초까지만 저장되고 있었고저장된 순서는 나노초 단위로는 구분이 되더라도 초는 같아서 의도와 다르게 조회되고 있었던 것이다. 저장 순서데로 조회가 가능하도록 해보자MySQL의 공식문서를 살펴본 결과 시간 타입에 (fsp) 정밀도를 ..