기계식 키보드를 이야기 할 때 갈축이나 청축이나 하는 이야기가 독일 체리사의 Cherry MX 스위치 축 색상에서 나온 단어다. 체리에서는 스위치의 특성에 따라 축의 색상을 구분했는데, 이게 사실상 산업 표준이 된거다.
갈축, 청축, 적축. 이 3가지 색상을 기반으로 여러가지 사양이 있다.
- 적축: 45g 리니어 스위치. 2.0mm/4.0mm 타건감 없음. 가장 소음이 적음. 눌렀다는 느낌이 적음. 소리가 작음 - 청축: 60g 클릭 스위치. 2.2mm/4.0mm 경쾌한 타건감. 클릭 소리 남. 가장 소리가 큼. - 갈축: 55g 넌클릭 스위치. 2.0mm/4.0mm 청축보다 덜한 타건감. 소리가 청축보다 작음.
※ 아래 영상을 보면 어떤 차이가 있는지 확인해볼 수 있다.
- 흑축: 60g 적축과 같은 리니어 타입에서 강한 스프링을 사용한 축. 같은 키를 자주 입력하는 작업에는 필요하나 키압이 강해 쉽게 피로를 느낄 수 있다. - 백축: 65g 제품명은 MX CLEAR다. 갈축과 같은 넌클릭 타입에서 강한 스프링을 사용한 축. 같은 키를 자주 입력하는 작업에는 필요하나 키압이 강해 쉽게 피로를 느낄 수 있다. - 회축: 80g 갈축의 스프링 강화버전이다. - 은축: 45g 적축과 같은 넌클릭 타입에서 누르는 깊이를 줄인 제품. (2mm -> 1.2mm)
May 8 21:07:59 wl gda: [ID 107833 kern.warning] WARNING: /pci@0,0/pci-ide@1f,2/ide@1/cmdk@1,0 (Disk1): May 8 21:07:59 wl Error for command 'read sector' Error Level: Retryable May 8 21:07:59 wl gda: [ID 107833 kern.notice] Sense Key: ICRC error during UDMA May 8 21:07:59 wl gda: [ID 107833 kern.notice] Vendor 'Gen-ATA ' error code: 0x16
ICRC: ATAPI 장치(예를 들어 SATA 방식의 HDD)에서 UDMA 를 사용시 ICRC(Interface CRC) 비트를 사용함 기본적으로 "전송 오류"
0x16 은 뭔가 응답이 오지 않은 경우에 해당되는듯. 재시도 가능.
일반적으로 "read sector" 커맨드에 대한 오류는 HDD 배드섹터에 기인하긴 하지만, 이 경우는 좀 아리송하다. 약 7시간 동안 45번 나고 더 이상 오류가 발생하지 않았음. 뭐징. OS 패치를 대량으로 하면 안보이던 오류가 많히 보인다. 일단 백업을 자주하는걸로 결정.
----
2024.11.27 추가
2022.05. 이후 별 이상 없다가 어제부터 이 메시지가 다시 보였다. 약 24시간 동안 267회 발생. 일단 조치사항은 없긴 한데 역시 백업은 해 놔야할듯.
블로그를 백업본으로 복구했다. 갑자기 아래와 같은 로그를 내면서 MySQL 이 죽어서 그렇다.
2022-04-20T09:00:24.015047Z 0 [Note] [MY-011953] [InnoDB] Page cleaner took 4554ms to flush 164 and evict 0 pages 17:00:26 UTC - mysqld got signal 11 ; Most likely, you have hit a bug, but this error can also be caused by malfunctioning hardware. Thread pointer: 0x2b42e148 Attempting backtrace. You can use the following information to find out where mysqld died. If you see no messages after this, something went terribly wrong... stack_bottom = 7fffbf04df10 thread_stack 0x46000 /usr/local/mysql-8.0.26-solaris11-x86_64/bin/mysqld'_Z19my_print_stacktracePKhm+0x2e [0x385a3ee] /usr/local/mysql-8.0.26-solaris11-x86_64/bin/mysqld'handle_fatal_signal+0x2f7 [0x26a6cb7] /lib/amd64/libc.so.1'__sighndlr+0x6 [0x7fffbe14ebe6] /lib/amd64/libc.so.1'call_user_handler+0x2f1 [0x7fffbe1406b1] /usr/local/mysql-8.0.26-solaris11-x86_64/bin/mysqld'_Z27free_blob_buffers_and_resetP5TABLEj+0x77 [0x2658077] /usr/local/mysql-8.0.26-solaris11-x86_64/bin/mysqld'_Z18close_thread_tableP3THDPP5TABLE+0xdc [0x24b192c] /usr/local/mysql-8.0.26-solaris11-x86_64/bin/mysqld'_Z19close_thread_tablesP3THD+0x28b [0x24b1c1b] /usr/local/mysql-8.0.26-solaris11-x86_64/bin/mysqld'_ZN18Prepared_statement7prepareEPKcmPP10Item_param+0x881 [0x25807f1] /usr/local/mysql-8.0.26-solaris11-x86_64/bin/mysqld'_Z19mysqld_stmt_prepareP3THDPKcjP18Prepared_statement+0xb6 [0x2581016] /usr/local/mysql-8.0.26-solaris11-x86_64/bin/mysqld'_Z16dispatch_commandP3THDPK8COM_DATA19enum_server_command+0x2097 [0x2556917] /usr/local/mysql-8.0.26-solaris11-x86_64/bin/mysqld'_Z10do_commandP3THD+0x174 [0x2557344] /usr/local/mysql-8.0.26-solaris11-x86_64/bin/mysqld'handle_connection+0x278 [0x2698468] /usr/local/mysql-8.0.26-solaris11-x86_64/bin/mysqld'pfs_spawn_thread+0x161 [0x3d8e4b1] /lib/amd64/libc.so.1'_thrp_setup+0xa4 [0x7fffbe14e7e4] /lib/amd64/libc.so.1'_lwp_start+0x0 [0x7fffbe14eac0]
Trying to get some variables. Some pointers may be invalid and cause the dump to abort. Query (2b436af0): SHOW TABLES LIKE 'piwik_archive_numeric%' Connection ID (thread ID): 1903317 Status: NOT_KILLED
The manual page at http://dev.mysql.com/doc/mysql/en/crashing.html contains information that should help you find out what is causing the crash.
- 구글링도 해봤지만 흔한 에러는 아닌듯 하다. 메시지만 보면 Data Dictionary 를 초기화하다가 오류. 그렇다면 mysql.ibd 파일에 문제가 있다는 거긴 하지만, MySQL 지원을 받을 수 있는건 아니라 포기. 만약 업체였다면 비용 들여서라도 지원받으면 되지 않을까 하는 생각이다. 예전에 5.x 버전에서 8 로 업그레이드가 제대로 안된것 같기도 하다.
- 처음에 난 덤프도 DataDictionary 를 조회하다가 오류난 것이기도 하다. 결국은 복구 불가로 판정했고 바로 백업본을 리스토어 했다. 이래서 백업은 중요하다. 매우 중요하다.
- 어쨌든 복구하느라고 MySQL 8을 재설치하고 백업본을 복구한거기 때문에, 서버가 꽤 빨라졌다. my.cnf 파일도 처음부터 재작성했다. 어쨌든 괜찮아진 느낌.
----
2022.04.26 추가
MySQL 8을 작년에 설치한것도 MySQL 5.x 에서 업그레이드한거였는데, 지금 생각해보면 뭔가 업그레이드가 잘못되었을 거 같다. my.cnf 에 문제가 있었는데도 작동했기 때문. MySQL 8 설치하고 첫 실행했을때 기동이 안되었다. my.cnf 를 초기화(내용을 전부 지움)하면 기동이 되었고. 뭔가 설정에 문제가 있긴 했던 느낌.