MySQL 데이터베이스에 심볼릭 링크를 사용할 수 있나요?

MySQL 데이터베이스에 심볼릭 링크를 사용할 수 있나요?

내 컴퓨터에 MySQL이 설치되어 있고 기존 용량을 최대화하려면 매우 큰 테이블을 추가해야 합니다.

이전에 MySQL 데이터를 외장 드라이브에 저장한 적이 있지만 읽기/쓰기 문제로 인해 외장 하드 드라이브보다는 노트북 하드 드라이브에 최대한 많은 데이터를 보관하는 것을 선호하므로 모든 데이터 대신 심볼릭 링크가 필요합니다. 하드 드라이브에.

나는 참조한다MySQL 문서이렇게 하려면 작동해야 할 것처럼 보이지만 내가 하는 일은 (처음에는) 이 새 데이터베이스에 테이블을 생성하는 것을 허용하지 않습니다(결국 대량 내보내기 .sql 파일/테이블을 이 새 데이터베이스로 가져오고 싶습니다). .

얻다:

mysql> create table test(`test` varchar(8) NOT NULL);
    ERROR 1030 (HY000): Got error 168 - 'Unknown (generic) error from engine' from storage engine

오류 로그에는 많은 내용이 표시되지 않고 다음 경고만 표시됩니다.

chris@chris-X1C6:/var/log/mysql$ cat error.log
2024-02-26T21:36:16.697730Z 19 [Warning] [MY-013360] [Server] Plugin mysql_native_password reported: ''mysql_native_password' is deprecated and will be removed in a future release. Please use caching_sha2_password instead'

mysqlMySQL 8에서 심볼릭 링크가 열려 있는지 확인하고, 적용 가능한 모든 디렉터리의 소유자를 확인했으며 , 각 위치에 충분한 공간이 있는지 확인했지만 여전히 이 오류 168이 발생합니다. 내가 무엇을 놓치고 있나요? 필요한 경우 Ubuntu 22.04에서 MySQL 8.0을 실행합니다.

관련 세부정보:

chris@chris-X1C6:/var/log/mysql$ df -h
Filesystem      Size  Used Avail Use% Mounted on
tmpfs           1.6G  4.1M  1.6G   1% /run
/dev/nvme0n1p6  173G  153G   12G  93% /
tmpfs           7.7G   31M  7.7G   1% /dev/shm
tmpfs           5.0M  4.0K  5.0M   1% /run/lock
efivarfs        154K   52K   98K  35% /sys/firmware/efi/efivars
tmpfs           7.7G     0  7.7G   0% /run/qemu
/dev/nvme0n1p4   60G  769M   60G   2% /media/chris/Share
/dev/nvme0n1p1  256M   35M  222M  14% /boot/efi
/dev/sdc2       4.6T   36K  4.3T   1% /media/chris/F
/dev/sda1       932G  287G  646G  31% /media/chris/T7
/dev/sdb2       4.6T  4.3T  260G  95% /media/chris/E
tmpfs           1.6G   96K  1.6G   1% /run/user/1000


chris@chris-X1C6:/var/lib/mysql$ ll --ignore=binlog*
total 1790432
-rw-rw-rw-  1 mysql mysql      1709 Dec  5  2022  ca-key.pem
-rw-rw-rw-  1 mysql mysql      1112 Dec  5  2022  ca.pem
-rw-rw-rw-  1 mysql mysql      1705 Dec  5  2022  server-key.pem
-rw-rw-rw-  1 mysql mysql      1112 Dec  5  2022  server-cert.pem
-rw-rw-rw-  1 mysql mysql      1705 Dec  5  2022  client-key.pem
-rw-rw-rw-  1 mysql mysql      1112 Dec  5  2022  client-cert.pem
-rw-rw-rw-  1 mysql mysql      1705 Dec  5  2022  private_key.pem
-rw-rw-rw-  1 mysql mysql       452 Dec  5  2022  public_key.pem
drwxrwxrwx  2 mysql mysql      4096 Dec  5  2022  sys/
drwxrwxrwx  2 mysql mysql      4096 Dec 14  2022  fu/
drwxrwxrwx  2 mysql mysql      4096 Dec 21  2022  eq/
drwxrwxrwx  2 mysql mysql      4096 May  8  2023  performance_schema/
-rw-rw-rw-  1 mysql mysql         0 Jan 26 17:44  mysql.sock
-rw-rw-rw-  1 mysql mysql         0 Jan 26 17:44  mysql.pid
-rw-rw-rw-  1 mysql mysql         0 Jan 31 06:40  debian-5.7.flag
drwxrwxrwx  2 mysql mysql      4096 Jan 31 06:40  mysql/
-rw-rw-rw-  1 mysql mysql         6 Jan 31 06:40  mysql_upgrade_info
lrwxrwxrwx  1 root  root         14 Feb 13 22:31  F -> /media/chris/F/
drwxr-xr-x 83 root  root       4096 Feb 17 09:46  ../
-rw-rw-rw-  1 mysql mysql   8585216 Feb 20 17:00 '#ib_16384_1.dblwr'
lrwxrwxrwx  1 mysql mysql        23 Feb 20 19:27  op -> /media/chris/F/mysql/op/
-rw-r-----  1 mysql mysql        56 Feb 20 19:28  auto.cnf
-rw-r-----  1 mysql mysql      3272 Feb 21 11:22  ib_buffer_pool
drwxrwxrwx  2 mysql mysql      4096 Feb 22 14:31 '#innodb_temp'/
drwxrwxrwx  2 mysql mysql      4096 Feb 22 14:32 '#innodb_redo'/
-rw-r-----  1 mysql mysql         5 Feb 22 14:32  chris-X1C6.pid
-rw-r-----  1 mysql mysql  12582912 Feb 22 14:32  ibtmp1
-rw-rw-rw-  1 mysql mysql 855638016 Feb 22 15:31  undo_002
drwxrwxrwx  9 mysql mysql      4096 Feb 26 00:00  ./
-rw-rw-rw-  1 mysql mysql 838860800 Feb 26 13:37  undo_001
-rw-rw-rw-  1 mysql mysql  79691776 Feb 26 13:37  ibdata1
-rw-rw-rw-  1 mysql mysql    196608 Feb 26 13:37 '#ib_16384_0.dblwr'
-rw-rw-rw-  1 mysql mysql  37748736 Feb 26 13:37  mysql.ibd

chris@chris-X1C6:/var/lib/mysql$ ls -lad /media/chris/F/mysql/op /var/lib/mysql/op
drwxrwxrwx 2 mysql mysql 4096 Feb 20 18:34 /media/chris/F/mysql/op
lrwxrwxrwx 1 mysql mysql   23 Feb 20 19:27 /var/lib/mysql/op -> /media/chris/F/mysql/op

답변1

저는 MySQL v5.6의 InnoDB 테이블을 사용하여 이 작업을 수행했습니다. 빈 테이블을 생성하고 mysqld를 종료한 후 공간이 충분한 파일 시스템으로 파일을 이동하고 이동된 파일에 대한 심볼릭 링크를 설정한 후 mysqld를 다시 시작했습니다.

파일을 이동하는 디렉토리는 mysqld가 실행 중인 사용자가 읽고 쓸 수 있는지 확인해야 하며, 해당 위치까지의 경로에 있는 디렉토리는 mysqld 사용자가 읽고 실행할 수 있는지 확인해야 합니다. (아마도 실행 가능해야 할 것 같은데 기억이 나지 않습니다)

내가 기억하는 또 다른 점은 mysqld가 파일 시스템을 사용하여 ALTER TABLE 작업(보통 새 파일 생성, 행을 새 파일에 복사한 다음 이전 파일과 새 파일의 파일 이름을 바꾼 다음 이전 파일 삭제)을 수행한다는 것입니다. (대형 파일)은 저장되지만 테이블 데이터에 대한 다른 작업은 저장되지 않을 수 있습니다. 임시 파일(및 임시 테이블)을 생성하는 정렬 또는 그룹화는 mysqld 표준 준비 영역의 임시 파일에 저장되며, 이는 테이블 파일을 이동하는 대규모 파일 시스템이 아닐 수 있습니다.

위의 경험은 아마도 8~10년 전에 일어났을 것이므로 시대에 뒤떨어진 것일 수도 있습니다. 나는 최신 버전의 MySQL이 여전히 이런 식으로 작동할 것이라고 생각하지만, 현재 문서와 현재 경험(다른 사람들이 경험을 공유하는 경우)을 따르는 것이 더 좋습니다.

관련 정보