일 | 월 | 화 | 수 | 목 | 금 | 토 |
---|---|---|---|---|---|---|
1 | 2 | 3 | 4 | |||
5 | 6 | 7 | 8 | 9 | 10 | 11 |
12 | 13 | 14 | 15 | 16 | 17 | 18 |
19 | 20 | 21 | 22 | 23 | 24 | 25 |
26 | 27 | 28 | 29 | 30 | 31 |
- RDBMS
- vacuum
- 6.2.7
- Docker
- Connection
- zabbix
- NOSQL
- percona
- Maria
- cdb
- DML
- NCP
- Cloud DB for MySQL
- MyISAM
- ncloud
- postgresql
- OD
- maxclients
- jmeter
- DELETE
- online ddl
- 성능테스트
- mongo
- InnoDB
- RDS
- opensource
- REDIS
- autovacuum
- slack
- mysql
- Today
- Total
목록전체 글 (95)
개인 공부

■ MySQL Binary File Download MySQL Commucity 버전으로 다운받기 위해서 아래 링크로 접속 www.mysql.com/products/community/ MySQL :: MySQL Community Edition MySQL Community Edition MySQL Community Edition is the freely downloadable version of the world's most popular open source database. It is available under the GPL license and is supported by a huge and active community of open source developers. The MySQL www.my..

innodb_flush_log_at_trx_commit 파라미터는 Transaction이 Commit되었을때 디스크에 저장되는 방법을 지정하는 변수이다. 해당 파라미터를 이용해서 Insert 작업 성능을 높일 수 있다. * innodb_flush_log_at_trx_commit = 0 -MySQL 서버에 문제가 생기면 마지막 1초의 Transaction 유실 발생 * innodb_flush_log_at_trx_commit = 1 - Default 값으로 데이터 유실 발생하지 않는다. * innodb_flush_log_at_trx_commit =2 - OS가 crash되거나 파워가 나가면 마지막 1초(혹은 그 이상..)의 트랜잭션이 유실될 수 있습니다. ■ innodb_flush_log_at_trx_com..

■ 기본 메커니즘 - 아래 사원과 고객 테이블이있다. 이 두 테이블에서 1996년 1월 1일 이후 입사한 사원이 관리하는 고객 테이터를 추출하는 프로그램을 작성해보자 - 일반적으로 NL조인은 Outer(선행)와 Inner(후행) 양쪽 테이블 모두 인덱스를 이용한다. Outer 테이블은 사이즈가 크지 않으면 인덱스를 사용하지않고 Table Full Scan을 하기도한다. Table Full Scan을 하더라도 한번에 그치기 때문이다. 반면 Inner 쪽 테이블은 인덱스를 사용해야 한다. Inner 루프에서는 관리사원번호 INDEX를 읽어야한다. 그렇지 않을시 Outer루프에서 읽은 건수만큼의 Table Full Scan을 반복하게된다. 1. 사원_X1 인덱스에서 입사일자 >= '19960101' 인 첫번째..

고객사에서 PostgreSQL를 이중화를 원하고 있었다. PostgreSQL 이중화에서 고려해봤던 것들은 Streaming replication + pacemaker를 이용해서 Auto Failover + VIP 이동을 해보려 했으나, 구축 후 장애 포인트가 많아질 것 같아 포기하였다. 다음으로 고려했던 Repmgr를 이용해서 이중화와 VIP 이동을 할 수 있도록 구축하기로 하였다. 이번 글은 Repmgr를 이용한 이중화 & Auto Failover & VIP 이동에 관하여 포스팅할 것이다. ■ 테스트 환경 Master : 10.70.101.69 ( lee-pg001 ) Standby : 10.70.101.70 ( lee-pg002 ) Vip : 10.70.101.68 ■ PostgreSQL 설치 ( A..

언제 한번 이중화로 구성된 고객사에 Lock이 심하게걸리고 문제가 생긴적이있다. 해당 Lock을 해결하고나서 Slave에 상태를 보니 Lock이후부터 따라가지 못하고있는것을 확인하였다. 여러가지 확인을 해보다 Master DB쪽의 binary log의 사이즈가 비정상적으로 컸던적이있다. 나의 예상으론 Binary log에 큰 트랜잭션들이 들어갔고 이 값을 max_allowed_packet 보다 커서 보내지 못한걸로 생각하였다. 나의 경우에는 Mariabackup을 이용해서 Replication을 재설정하였다. 이번에는 문제가 발생했던 영역인 Max_binlog_size 를 작게하였음에도 Binary log 사이즈가 커지는 것을 테스트해볼 생각이다. ■ max_binlog_size 확인 MariaDB [(..