출처 : https://mariadb.com/kb/ko/mariadb-mysql/#mariadb와-mysql-proxy의-비호환성

MariaDB는 MySQL을 즉시 교체할 수 있는 바이너리이다

모든 실용적인 목적에서 MariaDB는 동일한 MySQL 버전을 즉시 교체할 수 있다. (예를 들어 MySQL 5.1은 MariaDB 5.1MariaDB 5.2MariaDB 5.3과 호환되며, MySQL 5.5은 MariaDB 5.5와 호환된다.) 이는 다음과 같은 것을 의미한다.

  • 데이터와 테이블 정의 파일 (.frm) 파일들이 호환된다
  • 모든 클라이언트 API, 프로토콜 및 구조가 동일하다
  • 모든 파일이름, 바이너리, 경로, 포트, 소켓이 모두 동일해야 한다
  • 모든 MySQL 커넥터(PHP, Perl, Python, Java, .NET, MyODBC, Ruby, MySQL C connector 등)는 아무런 변화없이 MySQL에서 잘 작동한다
  • 몇몇 PHP5에서의 설치 이슈가 존재한다. (오래된 PHP 클라이언트가 라이브러리 호환성을 검사하는 데서 발생하는 버그이다)
  • 클라이언트 공유 라이브러리는 MySQL 클라이언트 라이브러리와 호환된다.

이는 대부분의 경우에서 MySQL을 언인스톨한 뒤, MariaDB를 설치해도 잘 작동한다는 것을 의미한다. (동일한 메인 버전에서는 데이터 파일을 변환할 필요없다.)

우리는 월간 주기로 MySQL 코드를 병합하여 호환성을 보장하며 오라클이 추가하는 기능 및 버그 수정도 MariaDB에 포함된다.

우리는 업그레이드 스크립트에 많은 작업을 완료하여 MySQL 5.0에서 MySQL 5.1로 업그레이드하는 것보다 MySQL 5.0에서 MariaDB 5.1로 업그레이드하는 것이 더 쉽도록 하였다.

하지만, MariaDB는 MySQL에 없는 새로운 옵션, 확장, 저장 엔진, 버그 수정도 많이 포함하고 있다. 서로 다른 MariaDB 버전별 기능은 MariaDB 릴리즈별 차이 에서 확인할 수 있다.

MariaDB 5.1과 MySQL 5.1의 비호환성

일부 경우 MariaDB는 MySQL보다 더 많은 정보를 보여주기 위하여 비호환성을 허용하고 있다.

다음 목록은 MySQL 5.1 대신 MariaDB 5.1을 사용하는 경우에 알려진 모든 사용자 레벨의 비호환성 목록이다.

  • 설치 패키지 이름은 MySQL 대신 MariaDB로 시작한다.
  • Timings may be different as MariaDB is in many cases faster than MySQL.
  • MariaDB의 mysqld는 my.cnf에서 [mariadb] 섹션을 읽는다.
  • You can't use a binary only storage engine library with MariaDB if it's not compiled for exactly the same MariaDB version. (This is because the server internal structure THD is different between MySQL and MariaDB. This is common also between different MySQL versions). This should not be a problem as most people don't load new storage engines and MariaDB comes with more storage engines than MySQL.
  • CHECKSUM TABLE은 다른 결과를 출력할 수 있다. MariaDB는 NULL을 무시하지 않지만, MySQL 5.1은 NULL을 무시하기 때문에 이러한 차이가 발생한다. (향후 MySQL은 MariaDB가 계산하는 방식대로 체크섬을 계산해야 할 것이다) 옛날 방식의 체크섬을 얻길 원한다면 --old 옵션으로 MariaDB를 실행하면 된다. 하지만, MariaDB의 MyISAM과 Aria 저장 에닌은 내부적으로 새로운 체크섬을 이용한다. 따라서 --old 옵션을 이용하는 경우 CHECKSUM 명령은 매 레코드마다 체크섬을 계산하기 때문에 속도가 느릴 것이다.
  • 슬로우 쿼리 로그는 쿼리에 대한 더 많은 정보를 제공하는데, 이는 슬로우 쿼리 로그를 직접 파싱하는 경우 문제가 될 수 있다.
  • MariaDB는 내부에서 사용하는 임시 테이블을 기본으로 Aria 저장 엔진을 사용하기 때문에 MySQL보다 메모리를 좀 더 사용한다. MariaDB가 최소한의 메모리만 더 사용하길 원하는 경우 aria_pagecache_buffer_size 를 1M 로 설정하면 된다. (기본 값은 128M).
  • 만약 새로운 명령 옵션MariaDB의 새로운 기능 혹은 새로운 저장 엔진, 을 사용하는 경우 더 이상 MySQL과 MariaDB 사이를 오갈 수 없다.

MariaDB 5.2와 MySQL 5.1의 비호환성

Incompatibilities between MariaDB 5.2 and MySQL 5.1

MariaDB 5.1과 MySQL 5.1의 비호환성과 동일하며 1가지가 추가된다.

SQL_MODE에 새로운 값이 추가되었다. 새롭게 추가된 값은 IGNORE_BAD_TABLE_OPTIONS이며, 이 값이 설정되지 않은 경우, 현재 사용 중인 저장 엔진에서 지원되지 않는 테이블, 필드, 인덱스의 속성을 사용하는 경우 에러를 발생한다. 이런 변화로 인해 에러 로그에는 다음과 같은 경고 메시지가 발생할 수 있다. "mysql 데이터베이스에 잘못 정의된 테이블이 있음. mysql_update를 이용하려 수정하시오"

모든 실용적인 목적에서 MySQL 5.2는 MariaDB 5.1과 MySQL 5.1을 즉시 대체 가능하다.

MariaDB 5.3, MySQL 5.1, MariaDB 5.2의 비호환성

  • 잘못된 변환에 관련된 일부 에러 메시지가 MariaDB에서 좀 더 자세히 제공된다.
  • MariaDB에 특화된 오류 번호는 1900번부터 시작하여 MySQL 오류 번호와 충돌되지 않는다.
  • MySQL은 일부 문맥에서 datetime과 time에서 마이크로초를 손실했지만, MariaDB는 모든 문맥에서 마이크로초가 잘 작동한다.
  • UNIX_TIMESTAMP (상수 날짜 문자열)은 MariaDB에서는 마이크로초 단위까지 표현이 가능히지만 MySQL은 그렇지 못하다. 이는 UNIX_TIMESTAMP()를 파티션 함수로 사용하는 경우 문제가 될 수 있는데, FLOOR(UNIX_TIMESTAMP(..)) 를 이용하거나 날짜 문자열을 숫자형 (예를 들어 20080101000000 형식)으로 바꿔서 해결할 수 있다.
  • MariaDB는 date, datetime, timestamp 값에 대해 더 엄격한 검사 수행한다. 예를 들어 UNIX_TIMESTAMP('x') 는 0이 아닌 NULL을 반환한다.
  • --maria- 시작 옵션은 제거되었다. 대신에 --aria- prefix를 사용해야 한다. (MySQL 5.2는 --maria--와 --aria- 모두 지원함)
  • SHOW PROCESSLIST는 Progress라는 추가적인 컬럼이 존재하며 일부 명령에 대해 진행 상황을 보여준다. 이 기능은mysqld 시작 시 --old 옵션을 이용하여 끌 수 있다.
  • INFORMATION_SCHEMA.PROCESSLIST는 진행 보고를 위해 다음과 같은 3개의 추가적인 컬럼을 출력한다: STAGEMAX_STAGE, and PROGRESS.
  • /*M! 혹은 <<code>>/*!#<</code>로 시작하는 긴 주석은 주석이 아니라 실제 실행이 된다.
  • max_user_connections=0 는 연결 수를 제한 두지 않는 것을 의미하는데, mysqld 시작 시 이 옵션을 사용하는 경우 mysqld가 실행 중인 경우는 이 전역 변수를 수정할 수 없다. <<code>>max_user_connections=s<</code>로 mysqld가 시작된 경우 연결 개수를 위한 구조체를 할당하지 않기 때문이다. mysqld 실행 중에 이 값을 바꾸고 싶다면 0이 아닌 큰 값을 지정하는 것이 좋다.
  • max_user_connections를 -1로 설정하여 (전역 변수인 GRANT 옵션도 동시에) 사용자가 서버에 접속하는 것을 중지시킬 수 있다. 전역 변수 max_user_connections는 SUPER 권한을 가진 사용자에게는 영향을 미치지 않는다.
  • |IGNORE 지시자는 모든 오류를 무시하지 않는다 (예:FATAL 오류). 무시를 해도 안전한 오류만 무시한다.

MariaDB 5.3과 MySQL 5.3의 비호환성

XtraDB

XtraDB를 제공하는 Percona는 5.5 코드 기반에게 초기 기능의 모든 것을 제공하지 않았따. 따라서 MariaDB 5.5 또한 그 기능을 제공하지 못한다.

5.5에 없는 XtraDB 옵션들

다음의 옵션들은 XtraDB 5.5에서 지원되지 않는다. 만약 당신이 my.cnf에서 아래의 옵션을 사용 중이라면 5.5로 업그레이드 전에 제거해야 한다.

  • innodb_adaptive_checkpoint ; Use innodb_adaptive_flushing_method instead.
  • innodb_auto_lru_dump ;Use innodb_buffer_pool_restore_at_startup instead.
  • innodb_blocking_lru_restore ; Use innodb_blocking_buffer_pool_restore instead.
  • innodb_enable_unsafe_group_commit
  • innodb_expand_import ; Use innodb_import_table_from_xtrabackup instead.
  • innodb_extra_rsegments ; Use innodb_rollback_segment instead.
  • innodb_extra_undoslots
  • innodb_fast_recovery
  • innodb_flush_log_at_trx_commit_session
  • innodb_overwrite_relay_log_info
  • innodb_pass_corrupt_table ; Use innodb_corrupt_table_action instead.
  • innodb_use_purge_thread
  • xtradb_enhancements

기본 값이 변경된 XtraDB의 옵션

XtraDB options that has changed default value

옵션기존 값새로운 값
innodb_adaptive_checkpointTRUE?FALSE
innodb_change_bufferinginserts?all
innodb_flush_neighbor_pages1?area

XtraDB 5.5의 새로운 옵션

다음의 옵션들은 XtraDB / InnoDB 5.5에 새롭게 추가된 옵션이다. (Listed here just to have all XtraDB information in the same place)

  • innodb_adaptive_flushing_method
  • innodb_adaptive_hash_index_partitions
  • innodb_blocking_buffer_pool_restore
  • innodb_buffer_pool_instances
  • innodb_buffer_pool_restore_at_startup
  • innodb_change_buffering_debug
  • innodb_corrupt_table_action
  • innodb_flush_checkpoint_debug
  • innodb_force_load_corrupted
  • innodb_import_table_from_xtrabackup
  • innodb_large_prefix
  • innodb_purge_batch_size
  • innodb_purge_threads
  • innodb_recovery_update_relay_log
  • innodb_rollback_segments
  • innodb_sys_columns
  • innodb_sys_fields
  • innodb_sys_foreign
  • innodb_sys_foreign_cols
  • innodb_sys_tablestats
  • innodb_use_global_flush_log_at_trx_commit
  • innodb_use_native_aio

5.5로 업그레이를 위한 Percona의 가이드 도 참조하는 것이 좋다.

MariaDB 5.5MariaDB 5.3과 MySQL 5.5의 비호환성

  • 중복 키 오류에서 INSERT IGNORE 는 경고 메시지를 출력한다.

MariaDB 10.0과 MySQL 5.6의 비호환성

  • MySQL의 모든 바이너리 (mysqldmyisamchk 등)은 예를 들어 --big-tables 대신 --big-table 옵션을 사용하는 경우 경고 메시지를 출력하는 반면, MariaDB 바이너리는 다른 대부분의 유닉스 명령들과 동일한 방식으로 작동하며, 유일한 prefix로 사용될 경우 경고를 출력하지 않는다.

지원되지 않는 설정

my.cnf에서 다음의 옵션을 사용 중인 경우 해당 변수를 제거해야 한다. 이는 MySQL 5.1 및 그 이후 버전에서도 마찬가지다.

  • skip-bdb

MySQL RPM 교체

만약 MySQL RPM을 제거하고 MariaDB를 설치하고자 하는 경우 MySQL RPM은 /etc/my.cnf를 /etc/my.cnf.rpmsave로 이름을 변경한다.

MariaDB를 설치한 뒤에는 다음과 같이 MySQL RPM 당시의 my.cnf를 복원할 수 있다.

mv -vi /etc/my.cnf.rpmsave /etc/my.cnf

MariaDB와 MySQL-Proxy의 비호환성

MySQL 클라이언트 API는 MySQL-Proxy를 통하여 MariaDB에 연결할 수 있다. 그러나 MariaDB 클라이언트 API는 "진행 보고(progress reporting)"을 MySQL-Proxy가 지원하지 않는다는 정보를 받게 된다. 완벽한 호환성을 위해서는 "진행 보고"를 클라이언트 측이나 서버 측에서 중지시키면 된다.


반응형

MySQL의 버전별 기능(Features) 변경 이력



출처 : http://intomysql.blogspot.kr/2011/01/mysql-features.html


VersionFeatures
추가변경삭제
5.5
  • MyISAM 대신 InnoDB가 MySQL의 기본 스토리지 엔진으로 채택
  • 5.4.2
  • Plugin버전의 InnoDB가 Builtin 버전으로 다시 적용
  • 5.1.38
  • InnoDB Plugin
  • 5.1.24
    (Enterprise version)

  • "SHOW PROFILE"
  • 5.1.12
  • "general_log" 파라미터

  • General query log를 동적으로 변경 가능
  • 5.1.8
  • "Mixed" 복제 모드
  • 5.1.6
  • Partition pruning 기능
  • 5.1.5
  • EXPLAIN PARTITIONS(파티션 테이블의 실행 계획) 지원
  • "RBR"(Row Based Replication) 복제 모드
  • 5.1
  • Plugin API 도입
  • Plugin버전의 InnoDB 릴리즈 (InnoDB 의 많은 성능 개선과 변화가 있음)

  • BDB 스토리지 엔진
  • 5.0.32
    (Community version)

  • "SHOW PROFILES"
  • 5.0.7
  • LIMIT의 파라미터도 PreparedStatement에서 변수화 가능
  • 5.0.5
  • BIT 데이터 타입이 MEMORY, InnoDB, BDB, NDBCLUSTER 스토리지 엔진에 구현됨
  • 5.0.3
  • FEDERATED 스토리지 엔진
  • 신규 함수 추가
    STDDEV_POP()
    STDDEV_SAMP()
    VAR_POP()
    VAR_SAMP()

  • BIT 데이터 타입이 TINYINT와 호환성 없어짐


  • NUMERIC와 DECIMAL 타입의 저장 방식이 String에서 Binary로 변경
  • 5.0.2
  • TRIGGER 도입

  • HAVING 조건에 SELECT컬럼, GROUP-BY컬럼, OUTER-서브쿼리의 값 사용 가능(ANSI 표준)
  • 5.0.1
  • VIEW 도입

  • HAVING 조건에 SELECT컬럼, GROUP-BY컬럼, OUTER-서브쿼리의 값 사용 가능(ANSI 표준)
  • 5.0
  • StoredRoutine (Procedure,Function) 도입
  • CURSOR 도입
  • Archive 스토리지 엔진
  • INFORMATION_SCHEMA 딕셔너리 데이터베이스 도입 (ANSI 표준)

  • ISAM 스토리지 엔진 제거
  • 4.1.11
  • Blackhole 스토리지 엔진
  • 4.1.4
  • CVS 스토리지 엔진
  • 4.1
  • SubQuery 도입
  • WHOW WARNINGS
  • CREATE TABLE ... LIKE ...
  • GROUP_CONCAT() 구현
  • 유니코드(UTF8, UCS2) 지원
  • GIS 관련 기능(Spatial extension) 지원
  • ALTER DATABASE 명령 지원
  • DUAL 테이블 내부 지원(타 DBMS와의 호환성 유지)
    "SELECT 1" 명령과 "SELECT 1 FROM DUAL" 명령은 동일
  • Memory 스토리지 엔진에서 B-Tree 허용
  • EXPLAIN EXTENDED 구현

  • Column 코멘트 구현(CREATE TABLE...)
  • PASSWORD() 함수의 알고리즘 업그레이드
    기존 알고리즘은 OLD_PASSWORD()로 변경됨
  • CHAR, VARCHAR 타입의 길이가 바이트수에서 문자수로 변경됨
  • 파생 테이블(Derived tables) 내에서 UNION 사용 가능
  • 4.0.18
  • "TYPE" 키워드가 "ENGINE" 키워드로 변경(CREATE TABLE...)
  • 4.0.14
  • InnoDB의 BLOB와 TEXT 타입에 대한 인덱스 지원
  • 4.0.4
  • JOIN DELETE (Multiple Delete) 도입
  • JOIN UPDATE (Multiple Update) 도입
  • 4.0.2
  • Memory 스토리지 엔진에서 NULLABLE 컬럼의 인덱스 지원

  • VARCHAR 컬럼의 길이가 1~255에서 0~255로 변경됨
  • 4.0.1
  • Query Cache 도입
  • 4.0
  • UNION 집합 연산 도입
  • SQL_CALC_FOUND_ROWS 힌트와 FOUND_ROWS() 함수 구현

  • UPDATE와 DELETE 구문에 ORDER BY 사용 허용
  • 3.23
  • EXPLAIN(쿼리 실행계획) 구현
  • 전문 검색(Fulltext search) 도입
  • JOIN(SELECT만) 도입
  • NULL-SAFE 연산자(<=>) 도입

  • 길이가 0인 CHAR 컬럼 허용

  • 반응형


    오랜만에 포스팅한다.


    파이썬 스크립트 개발에 틈틈히 php 수정등...

    마리아 DB를 공부도 해야된다는 생각에 정신이 없다..

    하지만 이게 잘 하고 있는건지...라는 의문의 1패...


    잡설은 그만하고..


    Script로 백업 도중 (스크립트 뽑아내는 명령어 중) Lock Tables 라는 에러가 발생하였다.


    그동안 문제없이 잘 돌아가는 스크립트가 왜 지금 에러가 발생했을까 라는 의문도 들고..

    중간에 작업한 적이 없는 것 같은데 ...


    하지만 컴퓨터는 거짓말을 하지 않기에... 일단은 백업이 우선이라 해결을 진행해 보았다.



    MyISAM 이기에 배치 작업이 있나 확인을 해 보았다. (조회 또한 table lock 을 잡기에....이건 순수히 나만의 생각)


    show processlist;


    하지만 확인 결과 어떠한 작업도 확인이 되지 않았다.


    그렇다면 희박하지만 권한을 부여해 보았다. (권한을 revoke 한 적은 전혀 없기에...)


    mysql> GRANT SELECT,LOCK TABLES ON DBNAME.* TO 'username'@'localhost';


    이 후 다시 진행해 보았다.


    $mysqldump -d -u유저 -p --quick > /파일명.sql 


    말도 안되....정상적으로 진행이 되었다.


    하아....누가??아니면 무슨 이유로...??

    원인을 찾아 봐야겠다.

    반응형

    [원본] http://randa.tistory.com/

    MySQL에서 비교연산자는 1(TRUE), 0(FALSE), NULL값 또는 연산에 대한 결과를 리턴한다. 이 포스팅에서는 비교연산자의 설명 및 예제를 설명하도록 한다.



    1. BETWEEN min AND max

    해당 연산자는 AND 좌우의 값을 포함한 범위안에 값이 있는지를 체크한다. 이는 수식으로 "expr >= ... AND expr <= ..." 동일한 결과를 나타낸다.

    1
    2
    3
    4
    5
    SELECT 2 BETWEEN 1 AND 3, 2 BETWEEN 3 and 1;
    SELECT 1 BETWEEN 2 AND 3;
    SELECT 'b' BETWEEN 'a' AND 'c';
    SELECT 2 BETWEEN 2 AND '3';
    SELECT 2 BETWEEN 2 AND 'x-3';

    1line - BETWEEN은 반드시 범위 값 중 작은게 왼쪽 큰게 오른쪽에 있어야 한다. 따라서 2는 1~3범위 안에 있음으로 

        2 BETWEEN 1 AND 3은 1을 리턴하고, 2 BETWEEN 3 and 1은 비교대상 중 우측이 더 작음으로 0을 리턴한다.

    2line - 1은 2~3 범위안에 없기 때문에 0을 리턴한다.

    3line - a~c중에는 b가 있기때문에 1이 리턴된다. BETWEEN은 숫자 뿐만 아니라 문자도 비교 가능한 것을 알 수 있다.

    4line - 범위 중 3을 '' 로 묶어 문자열로 치환하였으나, 숫자만이 존재 할 경우 내부적으로 숫자로 취급한다. 따라서 2~3중에는 

              2가 포함되어 있기에 1을 리턴한다.

    5line - 숫자와 문자열의 범위를 주었다. 이 경우 정상적으로 값을 취할 수 없기 때문에 0을 리턴한다. 5line의 예제는 비교연산

              을 위해서는 동일한 형태의 데이터 타입끼리 비교를 해야 정상적인 결과를 줌을 알 수 있다.



    2. COALESCE(value1,value2 ...)

    COALESCE는 범위안에 값 중 NULL이 아닌 첫번째 인수를 리턴한다. 만약 모든 값 이 NULL일 경우는 NULL을 리턴한다.

    1
    2
    SELECT COALESCE(NULL,1,2,3);
    SELECT COALESCE(NULL,NULL,NULL);

    1line - 좌측부터 시작해서 첫번째로 NULL이 아닌 것은 1이기 때문에 1을 리턴한다.

    2line - value 값이 전부 NULL로만 이루어져 있기 때문에 NULL을 리턴한다.



    3. GREATEST(value1,value2 ...)

    GREATEST는 범위안에 값 중 가장 큰 인수를 리턴한다.

    1
    2
    3
    4
    SELECT GREATEST(2,0);
    SELECT GREATEST(34.0,3,5.0,767.99);
    SELECT GREATEST('B','A','C');
    SELECT GREATEST(NULL,'B','C');

    1line - 2, 0중 가장 큰 수인 2를 리턴한다.

    2line - 가장 큰 수치인 767.99를 리턴한다.

    3line - a, b, c중 가장 뒤인 c를 리턴한다.

    4line - 값 중 NULL이 포함될 경우 NULL을 리턴한다.



    4. expr [NOT] IN (value1,value2 ...)

    IN 구문은 expr에 해당하는 값이 ( ) 안에 존재할 경우 1(TRUE)을 리턴한다. NOT이 붙을 경우 반대로 해당하는 값이 없어야 1을 리턴한다.

    1
    2
    3
    4
    SELECT 2 IN (0,3,5,7);
    SELECT 'wefwf' IN ('wee','wefwf','weg');
    SELECT 2 NOT IN (0,3,5,7);
    SELECT 'wefwf' NOT IN ('wee','wefwf','weg');

    1line - 0, 3, 5, 7 중 2가 존재하지 않기때문에 0을 리턴한다.

    2line - 'wefwf'는 ( ) 안에 존재하기 때문에 1을 리턴한다.

    3line - 1line 결과와 반대로 1을 리턴한다.

    4line - 2line 결과와 반대로 0을 리턴한다.


    IN절안에는 서로 다른 데이터 타입을 쓰지않는 것이 좋다. 이는 MySQL 내부적으로 비교하는 기준이 다를 수 있기 때문이다. 따라서 만약 숫자와 문자열을 혼합한다면 

    1
    SELECT val1 FROM tbl1 WHERE val1 IN (1,2,'a');

    위와 같이 사용하는 대신 아래와 같이 써야 한다.

    1
    SELECT val1 FROM tbl1 WHERE val1 IN ('1','2','a');


    IN절에서 ( ) 안의 값은 MySQL 환경변수 중 max_allow_packet에 영향을 받는다. IN절 안의 목록을 마음껏 늘려도 되지만 DB에서 설정 한 max_allow_packet 값을 초과할 수 는 없다.(사실 해당 값을 초과할 정도로 SQL을 작성할 경우는 극히 드물고 매우 비효율 적일 것이다. 그정도라면 JOIN이 더 효율적일 것임으로.)


    5. INTERVAL(N,N1,N2,N3,...)

    INTERVAL은 값 N과 그 뒤의 값을 비교하여 결과를 리턴한다. 최소 1개 이상의 N(num) 값이 있어야 한다.


     * N < N1 일 경우 뒤 N과 관계없이 무조건 0을 리턴한다.

     * N1 < N2 < N3 ... 와 같이 N(num)은 뒤로갈 수록 값이 커야 한다. 내부적으로 Binary 형태로 결과를 구하기 때문이 고 만약 

       그렇지 않을 경우 원하는 결과가 나오지 않을 수 있다.

     * N이 NULL 일 경우는 -1을 리턴한다.

     * N > N(num)이 될때까지의 N(num)에 대한 개수를 구한다. 왼쪽부터 읽는다.


    1
    2
    3
    4
    5
    SELECT INTERVAL(23, 1, 15, 17, 30, 44, 200);
    SELECT INTERVAL(10, 1, 10, 100, 1000);
    SELECT INTERVAL(22, 23, 30, 44, 200);
    SELECT INTERVAL(NULL, 3, 5, 7, 9);
    SELECT INTERVAL(100, 1, 10, 100, 10, 1000, 10);

    1line - N(23)보다 큰 N(num)은 30이다. 그럼 그 사이의 1, 15, 17의 개수 3. 따라서 3을 리턴한다.

    2line - N(10)보다 큰 N(num)은 100이다. INTERVAL에서 >= 는 조건에 포함되지 않는다. 따라서 1, 10 2개. 2를 리턴한다.

    3line - N(22) < N1(23)이다. 따라서 0을 리턴한다.

    4line - N이 NULL값이기 때문에 -1을 리턴한다.

    5line - N(100)보다 큰 N(num)은 1, 10, 100, 10 이 있다. N < N(num)이 만족한 1000에서 종료되기 때문에 뒤에 10은 무시된다. 

              따라서 4를 리턴한다.



    6. IS [NOT] NULL

    값이 NULL인가를 비교하여 값을 리턴한다. IS NULL의 경우 NULL인 경우 1 NULL이 아닌경우 0을 리턴한다. 반대로 NOT이 붙으면 부정의 의미가 되어 NULL이 아닌경우 1, NULL인 경우 1을 리턴한다.

    1
    2
    SELECT 1 IS NULL, '' IS NULL, NULL IS NULL;
    SELECT 1 IS NOT NULL, '' IS NOT NULL, NULL IS NOT NULL;

    1line - NULL(공백은 NULL이 아니다)은 NULL로 명시할 경우에만 존재함으로 0 / 0 / 1을 리턴한다.

    2line - NULL(공백은 NULL이 아니다)인 경우에만 0을 리턴함으로 1 / 1 / 0을 리턴한다.



    7.  IS [NOT] boolean_value

    불리안 값에 대응해서 값을 테스트 하는데, 여기에서 boolean_value 은 TRUE, FALSE, or UNKNOWN이   있다

    IS NOT boolean_value 신텍스는 MySQL 5.0.2에서 추가 되었다.

    1
    2
    SELECT 1 IS TRUE, 0 IS FALSE, NULL IS UNKNOWN;
    SELECT 1 IS NOT UNKNOWN, 0 IS NOT UNKNOWN, NULL IS NOT UNKNOWN;

    1line - 1, 0, NULL은 각각 TRUE/FALSE/UNKNOWN과 대응됨으로 전부 1을 리턴한다.

    2line - 1, 0은 각각 TRUE/FALSE에 대응함으로 참이다. NULL은 UNKNOWN인데 NOT을 붙여 부정했기에 거짓이 된다. 따라서 

              1/1/0을 리턴한다.



    8. ISNULL(expr)

    IS NULL과 비슷한 역활을 한다. expr에 대한 결과가 NULL인지 아닌가에 대하여 확인하여 NULL일 경우 1, 아닐경우 0을 리턴한다.

    1
    2
    SELECT ISNULL(1+1);
    SELECT ISNULL(1/0);

    1line - 1+1의 결과는 2다. NULL이 아님으로 0을 리턴한다.

    2line - 1을 0으로 나눈다는 것은 불가능하기 때문에 NULL이다. 따라서 1을 리턴한다.



    9. LEAST(value1,value2,...)

    LEAST는 값 중 가장 작은 인수를 리턴한다. 인수들은 아래의 규칙에 따라서 비교가 된다


     * 만일 리턴 값이 INTEGER 문맥에서 사용되거나 또는 모든 인수가 정수 값이라면, 그 인수들은 정수로 비교가 된다.

     * 만일 리턴 값이 REAL 문맥에서 사용되거나 또는 모든 인수가 실수 값 (real value)이라면, 인수들은 실수(real)로 비교된다.

     * 만일 어떤 인수가 문자 크기에 민감한 스트링이라면, 그 인수는 문자 크기를 구분하는 스트링으로 비교가 된다.

     * 이외의 모든 경우에는, 인수들은 문자 크기와는 상관없는 스트링으로 비교가 된다.


    MySQL 5.0.13 이전의 경우, LEAST() 은 모든 인수가 NULL 일 경우에만 NULL을 리턴했다. 하지만 5.0.13 이후에는, 어떤 인수라도 NULL 포함되어 있다면 NULL을 리턴한다.

    1
    2
    3
    SELECT LEAST(2,0);
    SELECT LEAST(34.0,3.0,5.0,767.0);
    SELECT LEAST('B','A','C');

    1line - 0이 가장 작음으로 0을 리턴한다.

    2line - 3.0이 가장 작음으로 3.0을 리턴한다.

    3line - A가 가장 앞선 문자열임으로 A를 리턴한다.



    10. value1 value2

    양쪽의 값을 경우 1 틀릴경우 0을 리턴한다. 단 하나의 값이라도 NULL이 포함되어지면 결과는 NULL을 리턴하게된다.

    1
    2
    3
    SELECT 1 = 0;
    SELECT '0' = 0;
    SELECT NULL = 0;

    1line - 1은 0이 아님으로 0을 리턴한다.

    2line - 0은 0임으로 1을 리턴한다

    3line - NULL이 포함되었음으로 NULL을 리턴한다.



    11. value1 <=> value2

    <=>는 같은 값을 비교하는 =과 내용은 근본적으로 동일하다. 하지만 차이점은 NULL 하나의 값도 값으로 표시한다는게 다르다.

    1
    2
    SELECT 1 <=> 1, NULL <=> NULL, 1 <=> NULL;
    SELECT 1 = 1, NULL = NULL, 1 = NULL;

    1line - 1, 1, 0. NULL 값도 하나의 문자로 취급 하기 때문에 NULL을 리턴하지 않는다.

    2line - 1, NULL, NULL. 하나라도 비교 대상에 NULL이 포함되면 연산불가로 판정하고 NULL 값을 리턴한다.



    12. value1 <> value2, 또는 value1 != value2

    =와 반대이다. 일치하지 않을 경우 1을 리턴한다.

    1
    2
    3
    SELECT '.01' <> '0.01';
    SELECT .01 <> '0.01';
    SELECT 'zapp' <> 'zappp';

    1line - .01은 0.01과 같음으로 0을 리턴할 것 같지만 둘다 ' 으로 묶어 문자형 만들었다. 따라서 문자 그대로 비교하여 틀림으로 

               값은 1

    2line - .01은 0.01과 같음으로 0을 리턴한다. 숫자의 경우 ' 으로 묶지 않으면 앞의 값이 생략된 경우 0을 추가한다. 

    3line - zapp와 zappp는 다름으로 1을 리턴한다.



    13. value1 > value2

    값 1이 값 2보다 클 경우 1을 리턴한다.

    1
    SELECT 2 > 1;

    1line - 2가 1보다 큼으로 1을 리턴한다.



    14. value1 >= value2

    값 1이 값 2보다 크거나 같을 경우 1을 리턴한다. >=의 순서 바꾸면 안된다.

    1
    SELECT 2 >= 2

    1line - 2보다 크거나 같을 경우에 참인데 2와 2는 같음으로 1을 리턴한다.



    15. value1 < value2

    값 1이 값 2보다 작을 경우 1을 리턴한다.

    1
    SELECT 2 < 1;

    1line - 2는 1보다 작음으로 1을 리턴한다.



    12. value1 <= value2

    값 1이 값 2보다 작거나 같을 경우 1을 리턴한다. <=의 순서 바꾸면 안된다.

    1
    SELECT 2 <= 2;

    1line - 2보다 작거나 같을 경우에 참인데 2와 2는 같음으로 1을 리턴한다.

    반응형

    [원본] http://blog.syszone.co.kr/3333

    때로 MySQL 5.1 데이터베이스는 몇가지 관리 작업을 수행해야 한다. 내 경우를 예로 들면, 운영서버에서 겨우 400k 행을 가진 두 개의 테이블을 조인하는 간단한 쿼리문을 실행하는데 너무 오래 걸리는 경우가 있었다. 실제로 이 쿼리문이 실행되는데 약 30초에서 100초 가량이 걸렸다. 테스트와 검수작업 후에 58ms로 처리 시간을 줄였다. 쿼리문의 컬럼은 이미 인덱스가 생성되어 있었기 때문이다. 이 정도 처리속도라면 다행히도 사용자들이 불편해 하는 정도는 아니였지만, 나는 이정도 처리 속도도 괜히 성가시게 느껴졌다. 해결책은 간단했는데, 몇가지 명령문을 실행해서 정리 작업을 하면 되었기 때문이다. 이 정리작업을 하고 나니, 동일한 쿼리문을 운영서버에서 실행하는데 겨우 4.8ms 밖에 걸리지 않게 되었다. 정말이지 만족스러운 결과였다.

    내가 한 일들

    • Backup - 데이터베이스 백업하기
    • Check - 데이터베이스 체크하기
    • Optimize - 데이터베이스 최적화하기
    • Analyze - 데이터베이스 분석하기

    mysqldump -u root -p --create-options --routines --triggers dbname > ./db.dmp

    # note these cause LOCKS, so be careful on your production server!

    $ mysqlcheck -u root -p --check --databases dbname

    $ mysqlcheck -u root -p --optimize --databases dbname

    $ mysqlcheck -u root -p --analyze --databases dbname


    각 수행 단계들에 대한 상세 설명

    1. 먼저 mysqldump 명령문을 이용해서 데이터베이스를 백업한다.

    프로시져 또는 함수가 있다면 반드시 -routines 인자를 사용해야 한다. 또한 트리거를 사용한다면 반드시 -triggers 인자를 사용해야 한다.


    $ mysqldump -u root -p --create-options --routines --triggers dbname > ./db.dmp

    # copy to another server

    $ scp ./db.dmp user@somehost:~/

    여기에 더해서 다른 시스템에서 백업한 데이터베이스를 실제로 재생성하여 백업이 정확한지 확인해야 한다.

    만약 데이터베이스가 너무 커다면 이처럼 데이터베이스 전체를 백업하는 일은 사실 불가능하다. 하지만 데이터베이스가 너무 크다면, 이미 복제 서버를 구축해서 백업 시스템을 활용중일 것이다.

    2 Check


    테이블 무결성을 검사한다.

    http://dev.mysql.com/doc/refman/5.1/en/check-table.html

    단일 테이블에 대해 검사를 하려면:

    mysql> CHECK TABLE {table name};

    콘솔에서 데이터베이스의 전체 테이블을 검사하려면 :

    $ mysqlcheck -u root -p --check --databases dbname

    테이블 무결성 검사는 정기적으로 하는 것이 좋다.

    3. Optimize

    단편화 제거 작업(defrag operation)과 같이, optimize table 명령문을 사용하면 사용하지 않은 공간을 회수할 수 있다. MyISAM 엔진에서는 optimize 명령문은 말그대로 단편화 제거 작업만을 수행한다. 반면 InnoDB 엔진의 경우 내부적으로 ALTER TABLE문을 실행하여, MySQL 서버에 대해 테이블과 인덱스를 재생성하도록 요청한다.

    http://dev.mysql.com/doc/refman/5.1/en/optimize-table.html

    단일 테이블에 대해 optimize를 하려면:

    mysql> OPTIMIZE TABLE {table name};

    콘솔에서 데이터베이스의 전체 테이블을 optimize를 하려면:

    $ mysqlcheck -u root -p --optimize --databases dbname

    만약 InnoDB라면 결과에 "Table does not support optimize, doing recreate + analyze instead” 메시지가 나온다.

    4. Analyze

    analyze를 실행하면 인덱스를 재생성하여 성능을 최적화하는데, 키를 재분배하기 때문이다. 만약 인덱스가 제대로 생성되어 있음에도 slow query가 발생한다면, analyze를 실행하는 것을 고려해 볼만하다. analyze를 실행하면 read 락이 걸린다. 만약 모든 테이블이 InnoDB 엔진을 사용한다면, optimize 과정에 이미 analyze가 포함되어 있다.

    http://dev.mysql.com/doc/refman/5.1/en/analyze-table.html

    단일 테이블에 대해 analyze를 하려면:

    mysql> ANALYZE TABLE {table name};

    콘솔에서 데이터베이스의 전체 테이블을 analyze를 하려면:

    $ mysqlcheck -u root -p --analyze --databases dbname

    InnoDB에서 analyze를 하는 경우, 몇가지 특이점이 있다. 특히 analyzer가 취하는 샘플의 갯수가 다를 수 있다는 점이다(샘플의 갯수는 innodb_stats_sample_pages 옵션으로 설정할 수 있다). 기본값이 매우 작기 때문에, analyze를 여러번 시도하게 될 때, 그때마다 결과가 달라질 수도 있다.

    더 자세한 내용은 아래를 참조하라.

    http://dev.mysql.com/doc/refman/5.1/en/innodb-restrictions.html

    반응형

    'MySQL' 카테고리의 다른 글

    [MySQL] mysqldump 시 lock tables  (0) 2016.05.31
    [펌][MySQL] 비교 연산자  (1) 2016.03.04
    [MySQL] DUMP (mysqldump) export  (1) 2016.02.25
    [MySQL] error 1130  (0) 2016.02.19
    [MySQL] 임시 DB 설치 3.23.58 (3.*) / python  (0) 2016.02.19


    이렇게 빨리 Migration을 진행할 줄 몰랐다.
    물론 내가 진행 하는 것이 아니지만 이참에 여러 테스트를 해 보았다.

    Oracle과는 다르게 쉽게 sql 문을 뽑아 낼 수 있고 쉽게 migration을 진행할 수 있는점이 매력적이다.
    정확히 말하면 한단계 과정을 덜 거치는 차이일 뿐인데..

    1. 단순히 data를 txt 파일로 export 진행
    -자신이 원하는 데이터를 바로 파일로 export 하는 것이다.

    mysql> SELECT * FROM 테이블명 INTO OUTFILE '/my_log/tmp1.txt';

    이걸로 끝이다.
    아래는 테스트로 뽑아낸 데이터다
    (디폴트는 Tab이다. 혹시라도 바꾸고자 한다면 명령문에 FIELDS TERMINATED BY '문자' 를 추가해 주면 된다

    mysql> SELECT * FROM 테이블명 INTO OUTFILE '/my_log/tmp1.txt''
        -> FIELDS TERMINATED BY ',';

    이렇게 하면 , 로 컬럼마다 구분을 해 준다


    --너무 성의 없어 보이는군....하지만 탭으로 나누어서 데이터가 export 된 것을 확인 가능하다.


    2. Mysqldump 를 이용하여 데이터 export

     

    기본 구문은 아래와 같다

    $> mysqldump -u 유저명 -p비밀번호 DB명 


    아래는 특정 테이블만 뽑아내는 내용

    $> mysqldump -u 유저명 -p비밀번호 DB명 테이블명 


    아래는 테이블의 특정 조건만 뽑아 내는 내용이다

    $> mysqldump -u 유저명 -p비밀번호 DB명 테이블명 --where="조건절" > 파일명


    추가로 위와 같이 뽑아내면 테이블 스키마도 같이 export 되어 나오기 때문에 다순 데이터 구문만 뽑아내고 싶다면 아래와 같이 진행해 보자

    $> mysqldump -u 유저명 -p비밀번호 DB명 테이블명  --where="조건절" --no-create-info | grep  '^INSERT' > 파일명


    샘플 명령문

    $> mysqldump -u root -pmysql TESTDB TestTable --where="idx=5 and status='Normal'" --no-create-info | grep  '^INSERT' > TestTable_query.sql


    -- 캡쳐는 회사 디비 내용을 가지고 테스트 하느라 비공개....




    Import는 다시 진행 후 업로드 해야겠다.


    반응형

    'MySQL' 카테고리의 다른 글

    [펌][MySQL] 비교 연산자  (1) 2016.03.04
    [펌] [MySQL] 5.1의 InnoDB에서 MySQL 테이블 최적화하기  (0) 2016.03.03
    [MySQL] error 1130  (0) 2016.02.19
    [MySQL] 임시 DB 설치 3.23.58 (3.*) / python  (0) 2016.02.19
    [MYSQL] Socket 접속  (0) 2016.02.11

    또 한번의 삽질 추가.


    임시 DB를 설치 한 이후 외부에서 접속을 진행 하였더니,

    접속이 안되어서 확인.


    처음에는 쉽게 port로 생각하여 Open 하였지만 연결 실패..


    유저도 제대로 생각했다고 했지만 여기서 함정..

    역시...난 멍청한 것인가...




    1. Linux Port Open

    vi /etc/sysconfig/iptables

    -A RH-Firewall-1-INPUT -p tcp -m state --state NEW -m tcp --dport 3306 -j ACCEPT

    -A RH-Firewall-1-OUTPUT -p tcp -m state --state NEW -m tcp --dport 3306 -j ACCEPT


    또는 아래와 같이 명령어 입력

    [root@localhost sysconfig]# iptables -I INPUT 1 -p tcp --dport 3306 -j ACCEPT

    [root@localhost sysconfig]# iptables -I OUTPUT 1 -p tcp --dport 3306 -j ACCEPT


    하지만...failed...

    >> ERROR 1130 오류 코드


    ERROR 1130 (00000): Host 'x.x.x.x' is not allowed to connect to this MySQL server


    2. User 생성 확인

    확인을 했더니 IP가 제대로 입력이 안되었음...OTL...단순히 local host로만 생성을 한 것임...



    아래와 같이 추가로 생성하여 해결



    참조 : http://imdsoho.tistory.com/entry/mysql-%EC%82%AC%EC%9A%A9%EC%9E%90-%EC%B6%94%EA%B0%80-%EB%B0%8F-error-1130-%EC%B2%98%EB%A6%AC

    반응형

    OS 재기동이 필요한 시점에 문제가 발생할 소지가 있기 때문에

    이럴 때를 대비해서 백업용 DB가 필요하다.


    문서로 정리 하였지만, 

    작성한 것을 복-붙 이다.




    임시 MySQL DB 구축

    작성일 : 2016.02.18

    작성자 : Louis.Kim

    mysql> select version();

    +-------------+

    | version()   |

    +-------------+

    | 3.23.58-log |

    +-------------+

    1 row in set (0.00 sec)

     

    1. zip 파일을 임시 DB에 복사 및 압축해제

              

    ex) tar -xvzf 파일명

     

    2. 압축 해제한 mysql 서버 폴더에 install.sh 파일을 생성 및 아래내용 복사 (make 파일생성)

      

    참고로 본 서버 참고하여 생성

    useradd -M -s /sbin/nologin mysql

    ./configure \

    --prefix=/usr/local/mysql \

    --with-charset=euc_kr \

    --without-innodb \

    --with-unix-socket-path=/tmp/mysql.sock \

    --without-comment \

    --without-debug \

    --with-mysqld-user=mysql \

    --without-bench \

    --without-docs \

    --localstatedir=/usr/local/mysql/var  \

    --sysconfdir=/etc \

    --disable-shard \

    --enable-assembler && make -j 6 && make install

     

    echo "/usr/local/mysql/lib/mysql" >> /etc/ld.so.conf && ldconfig

    cf) localstatedir 의 경우 기본적으로 설치되는 경로이기에, 경로가 변경된다면 해당 경로 수정

       혹여나 변경을 못했다면 my.cnf 에서 수정 가능


     

    3. .bashsrc 수정

     

    vi ~/.bashrc 한 후 아래 alias 추가

    vi = '/usr/bin/vim'

    . ~/.bashrc 또는 source ~/.bashrc 로 설정을 다시 로딩

     

    4. .bash_profile 수정

     

    /usr/local/mysql/bin path에 추가 (vi ~/.bash_profile)

    PATH=$PATH:$HOME/bin:/usr/local/mysql/bin

     

    -개인을 위해서 아래 추가

    mysql_base=/usr/local/mysql/

    mysql_home=$mysql_base/var/

    . ~/.bash_profile 또는 source ~/.bash_profile 로 설정을 다시 로딩

     

    5. install.sh 파일 실행

     

    $root > sh install.sh

     

    오류 발생 시 하단에 오류 발생 찾아서 확인

     

    6. 설치가 완료 되면 my.cnf 생성

     

    root$> vi /etc/my.cnf

    [client]

    #password       = your_password

    port            = 3306

    socket          = /tmp/mysql.sock

     

    [mysqld]

    port            = 3306

    socket          = /tmp/mysql.sock

    skip-locking

    skip-innodb

     

    set-variable    = key_buffer=512M

    set-variable    = max_allowed_packet=16M

    set-variable    = table_cache=512

    set-variable    = sort_buffer=4M

    set-variable    = record_buffer=2M

    set-variable    = thread_cache=512

    set-variable    = thread_concurrency=16

    set-variable    = myisam_sort_buffer_size=64M

    set-variable    = max_connections=300

    set-variable    = max_heap_table_size = 2000M

    set-variable    = tmp_table_size=1000M

    set-variable    = max_tmp_tables=256

    set-variable    = max_binlog_size =300M

    set-variable    = long_query_time = 1

     

    server-id       = 1

    log-bin=/db_log/LOG

    binlog-do-db=DARKEDEN

    log-slow-queries= /db_log/slow-query.log

     

    log=/backup/ALOG/mysql.log

     

    [mysqldump]

    quick

    set-variable    = max_allowed_packet=16M

     

    [mysql]

    no-auto-rehash

     

    [isamchk]

    set-variable    = key_buffer=256M

    set-variable    = sort_buffer=256M

    set-variable    = read_buffer=2M

    set-variable    = write_buffer=2M

     

    [myisamchk]

    set-variable    = key_buffer=256M

    set-variable    = sort_buffer=256M

    set-variable    = read_buffer=2M

    set-variable    = write_buffer=2M

     

    [mysqlhotcopy]

    interactive-timeout

    Port 는 기본 포트 3306

     

    Log-bin log-slow-queries , log 등의 해당 Directory가 없을 경우 생성해 줘야 함.

     

    [root@localhost /]# mkdir /db_log

    [root@localhost /]# chown -R mysql:mysql /db_log

     

    [root@localhost /]# mkdir -p /backup/ALOG

    [root@localhost /]# chown -R mysql:mysql /backup

     

    datadir 의 경우 해당 데이터가 쌓이는 장소이므로 없으면 default에 쌓이지만 변경이 원하고자 한다면 datadir 항목을 추가 (ef- datadir=/my_data1/datfile/ )

     

    이 모든 항목들은 mysqld를 중지한 후 진행해야 함

     

     

     

    7. Python 설치 (MySQL 에서 사용하기 위한 라이브러리 설치

       - README 보면서 진행)

     

      $ tar xfz MySQL-python-1.2.1.tar.gz

      $ cd MySQL-python-1.2.1

      $ chmod 700 setup.py   --권한이 없을 경우 권한 부여

      $ # edit site.cfg if necessary

      $ python setup.py build

      $ sudo python setup.py install # or su first

     

    확인방법

      - Python 접속

      $phthon

      $ import MySQLdb  후 에러가 발생 안되면 완료

     

    8. DB 설치

     

    필히 설치할 필요 없으나, 아래 폴더에서 설치가 가능

    $ cd /usr/local/bin

    $ ./mysql_install_db

    /usr/local/mysql/var 에 설치가 되었는지 확인이 가능

     

    9. 해당 데이터 및 권한 가져오기

     

    - 데이터는 일간 백업에서 가져오면 가능(FTP 서버 내 Daily_BK) -> 데이터

     - $ tar -cvzf mysql_back1.tgz /usr/local/mysql/var/mysql  -> 권한

       해당 압축 파일을 FTP서버로 전송 후 다시 임시 DB로 전송

     

    10. 임시 DB에서 권한 및 데이터 복구

     

    - 권한의 경우 기존 mysql 해 놓은곳에 덮어 쓸것 (기존은 백업)

    - 일간 백업한 것은 DARKEDEN 에 생성 (권한 확인 / 소유자 확인)

    - 각각의 폴더의 유저 소유 권한을 확인(/usr/local/mysql/var 의 경우 아래로 mysql으로 해야함)

     

    11. MySQL open

     - $>safe_mysqld&  로 실행 후 $>ps -ef | grep mysql 확인


     



    오류 발생 시

    1. sh install.sh 를 돌렸는데 발생하는 오류

    ...

    checking for atomic operations... no

    checking for int8... no

    checking "LinuxThreads"... "Not found"

    configure: error: This is a linux system and Linuxthreads was not

    found. On linux Linuxthreads should be used.  Please install Linuxthreads

    (or a new glibc) and try again.  See the Installation chapter in the

    Reference Manual for more information.

    해결방법

    mysql 설치중 아래와 같은 error 메세지 발생시에는 간단히 아래 방법대로 진행

     

    checking "LinuxThreads"... "Not found"

    configure: error: This is a linux system and Linuxthreads was not

    found. On linux Linuxthreads should be used.  Please install Linuxthreads

    (or a new glibc) and try again.  See the Installation chapter in the

    Reference Manual for more information.

     

    방법:

    /usr/include/pthread.h 화일을 열어 맨위 부분쯤에 아래 내용을 추가 하고 저장

     

    /* Linuxthreads */

     

    mysql configure 과정에서 pthread.h 파일을 찾아 위 내용이 있는지 확인하는 것으로

    glibc에서 없는 경우 에러 메세지가 발생


    참고 : http://faq.hostway.co.kr/Linux_DB/1303

     

    반응형

    MYSQL 을 linux 상에서 접속을 할줄 몰라 열심히 삽질 하다가 겨우 찾아냈다.


    사실 말하면 그동안 동료가 알려줬지만 제대로 못 외워서 삽질한게 더 맞는 것 같다.

    역시 삽질하면서 배워야지 자기 것이 되는게 맞는 말인듯....


    일반적으로 mysql 접속은 아래와 같다.


    /usr/local/mysql/bin/mysql -u user01 -p user_db


    -u 뒤에는 유저명

    -p 뒤에는 패스워드를 작성하면 된다.


    하지만 나는 진행할려고 할때마다 아래와 같은 에러가 발생했다.


    [root@devDB ~]# mysql -h localhost -u root -p

    Enter password:

    ERROR 2002: Can't connect to local MySQL server through socket '/tmp/mysql.sock' (2)


    왜이리 접속이 안되서 열심히 찾아보이 socket 을 이용해서 접속하는 것이기에,

    해당 socket파일에 명시가 되어 있지 않다고 되어 있다.


    Oracle 과 비교하면 리스너와 같은것으로 보면 될까?? 리스너 포트가 변경되었을 때

    리스너 포트를 명시하는 경우다.


    아래와 같이 진행하면 된다.

    해당 개발DB의 경우 cnf 파일에 명시되어 있는데 cnf 파일을 보면 아래와 같다


    ...

    [mysqld7100]

    socket          = /tmp/mysql_1100.sock

    port            = 7100

    pid-file        = /home/DATABASE/DBPart/mysql_1100.pid

    datadir         = /home/DATABASE/DBPart/

    server-id       = 1100

    ...


    그래서 아래와 같이 시도를 하면 접속이 된다.


    mysql -u root -p -S /tmp/mysql_1100.sock


    참고로 -p 뒤에 비밀번호를 붙이지 않으면 비밀번호를 묻게 된다.



    mysql -u user01 -p user_pw

    mysql : MYSQL 데이터베이스 클라이언트 프로그램

    -u : MYSQL 사용자명을 지정하기 위한 옵션

    -p : 지정한 사용자의 MYSQL 패스워드를 입력하기 위한 옵션

    user_db : 지정한 사용자가 사용할 MYSQL 데이터베이스명


    Oracle 하다가 Mysql 를 하려고 하니 참 낯설다-ㅋㅋㅋ


    반응형

    어떤 DBMS이든지 마찬가지겠지만, DBMS를 효율적으로 적은 리소스로 가장 좋은 성능을 내게끔 사용하기 위해서 가장 먼저 해야 하는 일은 어떠한 구조로 만들어 졌는지 확인하는 것이다. DBMS의 특성을 확인하여, 그 DBMS의 장점과 단점을 파악하고, 내가 원하는 서비스의 성격에 맞게 DBMS를 선택하여 사용하면, 훨씬 더 효율적으로 데이터를 관리 할 수 있다. 

    MySQL도 DBMS로서 다른 DBMS와 비교되는 구조와 특성을 가지고 있다. 이러한 특성을 미리 나열하기 전에 MySQL의 내부 구조에 대해 먼저 알아보자. 

     

    [그림 1-1]

    [그림 1-1]은 MySQL Conference에서 MySQL 내부 구조 설명시 MySQLAB에서 사용했던 그림이다. 여기에서 알수 있는 것은 MySQL Server의 내부의 모듈들은 컴포넌트 형태로 되어있어서 여러 기능들이 퍼즐 형식으로 엮여져 있다는 것이다. 

    퍼즐 형태로 만들어진 내부 모듈들로 인해 내부적으로 다른 스토리지 엔진을 추가하거나, 기능을 추가할때, 다른 모듈에 크게 영향을 주거나 하는 일이 적은 것을 확인할 수 있다. 

    맨 위의 오른쪽에 표시된 SQL Control interface는 MySQL Client와 MySQL Server 사이에 존재하는 Interface로서 백업을 진행할 때나, 상태 정보를 보고 싶을때와 같은 경우에 컨트롤 하는 문장들을 의미한다. 

    사용자 삽입 이미지

     

    [그림 1-2]
    [그림 1-2] 도 MySQLAB에서 MySQL Server와 Application과의 관계및 여러 Tool들을 설명하기 위해 사용하는 그림 중의 하나이다. 

    크게 MySQL은 세 단계로 나누어 생각할 수 있다. 첫번째는 위의 그림에서 Connector로서 표현한 Client 부분, 두번째는 MySQL Server의 머리부분에 해당하는 부분으로 SQL을 분석하여 실행계획을 만드는 부분, 세번째는 데이터를 저장하고 추출하는 Storage Engine 부분이다. 

    맨 위의 Connector는 MySQL Server에 접근하기 위해 Application에서 설치하여 사용할 수 있는 모듈들을 나타낸다. C API, JDBC등 언어에 따라 여러가지 Connector들을 사용할 수 있고, 이 Connector들을 사용하여 MySQL Server와 통신할 수 있다. 

    두번째 부분는 MySQL의 인스턴스 부분으로 Client로 부터 들어온 쿼리를 분석하고 최적화 하여 실행계획을 만들고, 필요할 경우 메모리에 cache하는 기능을 담당하는 부분이다. 

    세번째 부분은 Storage Engine 영역으로 데이터를 저장하고, 추출하는 부분을 담당하는 부분으로 나눌 수 있다. 위의 그림에서 보는 것과 같이 스토리지 엔진의 종류는 다양하다. MySQLAB에서 만든 스토리지 엔진도 있고, 다른 서드파티에서 만든 스토리지 엔진도 있다. 화면에 보이는 스토리지 엔진은 대부분 MySQLAB에서 만든 것들이다. 

    각각의 스토리지 엔진은 그 데이터 저장방법 및 추출 방법에 장점과 단점을 가지고 있다. 그렇기 때문에 실제 서비스에 사용할 때에는 스토리지 엔진 특성에 맞게 취사 선택을 잘 해야 한다. 

    실제 한국에서 웹 서비스에 많이 사용하는 스토리지 엔진은 MyISAM과 InnoDB이다. 그러므로 추후에 강좌에서는 MyISAM과 InnoDB에 대해 자세히 다루도록 할 예정이다. 

    [그림 1-2]의 MySQL Server 부분에 표현된 SQL 분석 부분에 관련된 부분을 자세히 살펴보도록 하자. 

    먼저 Connection Pool은 MySQL 내부에서 관리하는 Connection Pool을 말하는 것으로 새로운 유저의 커넥션 쓰레드를 DB에 할당하여 저장하는 부분을 말한다. Connection을 생성하게 되면 자동적으로 그 Connection에서 실행할 SQL 작업을 위한 메모리가 자동적으로 할당된다. 

    SQL Interface는 DML, DDL, Stored Procedure, View, Cursor, Trigger등의 지원을 위한 Interface부분을 말하고, 모든 SQL 함수에 대한 지원을 제공하는 모듈을 말한다. 

    Parser/Optimizer는 SQL의 권한을 확인하고, SQL문을 데이터베이스 내부 언어로 변환하고, 수행 경로를 분석하는 등 SQL문을 실행을 위한 준비 작업을 하는 부분을 말한다. 이 부분은 모든 스토리지 엔진에 동일하게 적용되기 때문에 스토리지 별로 별도의 코딩이 필요없다. 

    메모리 캐쉬 부분은 빈번하게 사용되는 인덱스나 데이터를 빠르게 접근하게 하기 위해 메모리에 저장하는 영역을 말하며, 스토리지 엔진에 따라 그 기능은 조금씩 차이가 난다. 


    반응형

    'MySQL' 카테고리의 다른 글

    [펌] [MySQL] 5.1의 InnoDB에서 MySQL 테이블 최적화하기  (0) 2016.03.03
    [MySQL] DUMP (mysqldump) export  (1) 2016.02.25
    [MySQL] error 1130  (0) 2016.02.19
    [MySQL] 임시 DB 설치 3.23.58 (3.*) / python  (0) 2016.02.19
    [MYSQL] Socket 접속  (0) 2016.02.11

    + Recent posts