더 작은 디스크를 갖춘 컴퓨터가 있습니다.
Filesystem Size Used Avail Use% Mounted on
/dev/root 3.5G 3.1G 249M 93% /
devtmpfs 459M 0 459M 0% /dev
tmpfs 463M 0 463M 0% /dev/shm
tmpfs 463M 36M 428M 8% /run
tmpfs 5.0M 8.0K 5.0M 1% /run/lock
tmpfs 463M 0 463M 0% /sys/fs/cgroup
/dev/mmcblk0p1 63M 25M 38M 40% /boot
tmpfs 64M 140K 64M 1% /mnt/ramdisk
저는 간단한 데이터베이스를 가지고 있지만 테이블 중 하나에 500만 개가 넘는 행이 있어서 작은 레코드에서 많은 공간을 차지합니다.
# ls -lh /var/lib/mysql/datalogger/
total 1.1G
...
-rw-rw---- 1 mysql mysql 1.1G Nov 10 09:56 avg_values.ibd
...
많은 공간(이 표의 약 절반)을 차지하지 않는 다른 유사한 컴퓨터에서 수행한 목표는 6개월보다 오래된 데이터를 삭제하는 쿼리를 실행하는 것입니다. 문의 내용은 사건과 관련이 없습니다. 쿼리 후 실행하여 공간을 optimize NO_WRITE_TO_BINLOG table avg_values;
확보하세요 ibd
.
문제의 컴퓨터의 문제는 사용 가능한 공간이 매우 제한되어 있고 (내가 아는 한 캐시를 통해) 그렇게 큰 테이블에서 쿼리를 실행할 수 없기 때문에 쿼리 후에도 통신이 불규칙하다는 것입니다. 한도를 완료했습니다:
MariaDB [datalogger]> select * from avg_values limit 10;
ERROR 2006 (HY000): MySQL server has gone away
No connection. Trying to reconnect...
Connection id: 5
Current database: datalogger
ERROR 2013 (HY000): Lost connection to MySQL server during query
다른 작은 테이블의 경우 일반적으로 문제가 없습니다(오류가 표시되기도 함).
MariaDB [datalogger]> select * from raw_values;
ERROR 2006 (HY000): MySQL server has gone away
No connection. Trying to reconnect...
Connection id: 5
Current database: datalogger
+----+---------------------+-------------------+------+-------+
| id | timestamp | channel | raw | value |
+----+---------------------+-------------------+------+-------+
| 1 | 2021-11-10 09:46:51 | AI1 | 1 | 0.011 |
| 2 | 2021-11-10 09:46:51 | AI2 | 1 | 0.011 |
| 3 | 2021-11-10 09:46:51 | AI3 | 2 | 0.022 |
| 4 | 2021-11-10 09:46:51 | AI4 | 2 | 0.022 |
| 5 | 2021-11-10 09:46:51 | pyr1_sensor1_data | 113 | 113 |
| 6 | 2021-11-10 09:46:51 | pyr1_body_temp | 42 | 42 |
| 7 | 2021-11-10 09:46:51 | pyr2_sensor1_data | NULL | NULL |
| 8 | 2021-11-10 09:46:51 | pyr2_body_temp | NULL | NULL |
| 9 | 2021-11-10 09:46:46 | AI1 | 1 | 0.011 |
| 10 | 2021-11-10 09:46:46 | AI2 | 1 | 0.011 |
| 11 | 2021-11-10 09:46:46 | AI3 | 2 | 0.022 |
| 12 | 2021-11-10 09:46:46 | AI4 | 2 | 0.022 |
| 13 | 2021-11-10 09:46:46 | pyr1_sensor1_data | 115 | 115 |
| 14 | 2021-11-10 09:46:46 | pyr1_body_temp | 42 | 42 |
| 15 | 2021-11-10 09:46:46 | pyr2_sensor1_data | NULL | NULL |
| 16 | 2021-11-10 09:46:46 | pyr2_body_temp | NULL | NULL |
| 17 | 2021-11-10 09:46:52 | AI1 | 1 | 0.011 |
| 18 | 2021-11-10 09:46:52 | AI2 | 1 | 0.011 |
| 19 | 2021-11-10 09:46:52 | AI3 | 2 | 0.022 |
| 20 | 2021-11-10 09:46:52 | AI4 | 2 | 0.022 |
| 21 | 2021-11-10 09:46:52 | pyr1_sensor1_data | 112 | 112 |
| 22 | 2021-11-10 09:46:52 | pyr1_body_temp | 42 | 42 |
| 23 | 2021-11-10 09:46:52 | pyr2_sensor1_data | NULL | NULL |
| 24 | 2021-11-10 09:46:52 | pyr2_body_temp | NULL | NULL |
+----+---------------------+-------------------+------+-------+
24 rows in set (0.02 sec)
특히 이 작은 디스크를 사용하여 공간을 확보하는 등 이러한 쿼리를 실행할 수 있는 방법이 있습니까?
답변1
쿼리 실행 중에 공간이 소진될 수 있으므로 제한된 저장 공간이나 합리적인 쿼리에 맞게 최적화하는 쉬운 방법은 없습니다. 두 가지 옵션이 있습니다:
원격 시스템에서 NFS 드라이브를 마운트하고 mysql의 tmpdir을 해당 드라이브로 지정하거나 mysql의 tmpdir을 /dev/shm으로 지정합니다. 이 점에 매우 주의하고 이와 같은 작업을 수행하기 전에 항상 백업을 만드십시오.