☰

mysql, 개별 데이터베이스와 전체 데이터 디렉토리 재배치

tag-icon • tag-icon mysql data-recovery database-administration database-backup
mysql, 개별 데이터베이스와 전체 데이터 디렉토리 재배치

다음 목적을 위해 mysql 고객 데이터베이스를 다른 디스크로 재배치해야 합니다.

 1. Separation of user data from system files
 2. Ease of backing up system and user data separately
 3. Ease of upgrading the system

다음 기사가 도움이 되었습니다.

  [how-to-move-mysql-datadir-to-another-drive][1]
  [move-a-mysql-database-to-another-location][2]

ubuntu-18 시스템에서 실행하면 innodb_file_per_table 변수가 기본적으로 설정되어 있는 것으로 보입니다.

mysql> SHOW GLOBAL VARIABLES LIKE 'innodb_%';
...
| innodb_file_per_table                    | ON 
...

(GLOBAL 없이도 동일한 결과)

찾을 수 없어요어느모든 구성 파일에서 innodb_file_per_table에 대한 참조 많은 내용이 포함된 유일한 파일은 다음과 같습니다.

  /etc/mysql/mysql.conf.d/mysqld.cnf

파일에 아직 무엇이 저장되어 있는지 걱정됩니다.

  /var/lib/mysql/ibdata1
                /ib_logfileN

데이터베이스에 액세스하기만 하면 이러한 내용이 업데이트된다는 것을 알았습니다.

내 질문은 다음과 같습니다

  1. 고객 데이터베이스만 (별도의 디스크로) 이동했는데 시스템 디스크가 손실되어 처음부터 다시 생성해야 하는 경우 손실되는 항목이 있습니까?

  2. (mysql,performance_schema 및 sys)를 포함한 모든 데이터베이스를 별도의 디스크로 이동하는 것이 더 낫습니까?

  3. /etc/mysql/mysql.conf.d/mysqld.cnf의 "datadir" 변수를 통해 이를 가리키는 전체 데이터 디렉토리를 별도의 디스크로 이동하는 것이 더 낫습니까?

  4. 그 결과는 무엇입니까?~ 아니다시스템 디스크가 손실된 경우 옵션 3을 사용하시겠습니까?

답변1

MySQL의 모든 테이블을 다른 디스크로 옮기는 것이 가장 좋습니다. '고객'을 분리하려는 시도는 복잡성을 더하고 목표를 어렵게 만듭니다. (요구 사항이 될 경우 추가 논의가 가능합니다.)

기본적으로 이러한 이동으로 인해 남겨지는 유일한 파일은 구성 파일입니다. 언급했지만 /etc/mysql/mysql.conf.d/mysqld.cnf주변에 다른 구성 파일이 있을 수 있습니다.

다른 곳에는 여러 파일과 사용자가 만든 "데이터베이스"에 해당하는 하위 디렉터리가 포함된 더 큰 디렉터리가 있습니다. 나는 그 나무 전체를 옮기기만 하면 됩니다. Linux 기반 OS를 사용하는 경우 이전 위치에서 새 위치로의 심볼릭 링크를 사용하십시오. 명시적인 구성 변경은 필요하지 않습니다.

그런 다음 디스크 중 하나가 충돌하면 데이터에 액세스할 수 없습니다. 내 요점은 파일과 디렉토리를 가지고 노는 것이 반드시 "보안"에 더 가까워지는 것은 아니라는 것입니다.

대신 백업에 집중하세요. 및/또는 "복제". 후자는 추가 비용이 필요합니다.섬기는 사람그리고 데이터의 완전한 사본을 제공합니다. 그러면 서버 중 하나가 충돌하더라도 손실되는 것은 없습니다.

LVM은 또 다른 백업 기술입니다. 데이터베이스용 디스크를 사용하면 얻을 수 있는 이점. 그러나 그것은 많은 복잡성을 추가합니다.

좀 더 읽어보고 열린 마음을 유지하도록 제안하십시오. 당신의 생각과 직접적으로 일치하는 많은 것을 발견하게 될 것입니다.

관련 정보