MySQL이 계속 크래시되다
클라우드에서 Ubuntu 12.10을 실행하는 서버가 있으며, 워드프레스 웹 사이트를 실행하기 위한 RAM은 512MB입니다(하루 약 1000회 방문).
MySQL이 항상 크래쉬가 발생하여 4Gb 스와프를 활성화하여 동작할 수 있는지 확인했습니다.하지만 여전히 추락하고 있어매번 서비스를 다시 시작해야 하는데...
mysql에서 에러 로그를 확인해보니 InnoDB가 뭔가 복구하려고 루프를 하고 있는 것 같았지만, 할 수 없는 것 같습니다.누가 나를 도와줄 수 있나요?
131009 17:56:57 InnoDB: 5.5.32 started; log sequence number 242183133
131009 17:56:57 [Note] Server hostname (bind-address): '127.0.0.1'; port: 3306
131009 17:56:57 [Note] - '127.0.0.1' resolves to '127.0.0.1';
131009 17:56:57 [Note] Server socket created on IP: '127.0.0.1'.
131009 17:56:57 [Note] Event Scheduler: Loaded 0 events
131009 17:56:57 [Note] /usr/sbin/mysqld: ready for connections.
Version: '5.5.32-0ubuntu0.12.10.1' socket: '/var/run/mysqld/mysqld.sock' port: 3306 (Ubuntu)
131009 17:57:25 [Note] Plugin 'FEDERATED' is disabled.
131009 17:57:25 InnoDB: The InnoDB memory heap is disabled
131009 17:57:25 InnoDB: Mutexes and rw_locks use GCC atomic builtins
131009 17:57:25 InnoDB: Compressed tables use zlib 1.2.7
131009 17:57:25 InnoDB: Using Linux native AIO
131009 17:57:25 InnoDB: Initializing buffer pool, size = 128.0M
131009 17:57:25 InnoDB: Completed initialization of buffer pool
131009 17:57:25 InnoDB: highest supported file format is Barracuda.
InnoDB: The log sequence number in ibdata files does not match
InnoDB: the log sequence number in the ib_logfiles!
131009 17:57:25 InnoDB: Database was not shut down normally!
InnoDB: Starting crash recovery.
InnoDB: Reading tablespace information from the .ibd files...
InnoDB: Restoring possible half-written data pages from the doublewrite
InnoDB: buffer...
131009 17:57:26 InnoDB: Waiting for the background threads to start
131009 17:57:27 InnoDB: 5.5.32 started; log sequence number 242183133
131009 17:57:27 [Note] Server hostname (bind-address): '127.0.0.1'; port: 3306
131009 17:57:27 [Note] - '127.0.0.1' resolves to '127.0.0.1';
131009 17:57:27 [Note] Server socket created on IP: '127.0.0.1'.
131009 17:57:27 [Note] Event Scheduler: Loaded 0 events
131009 17:57:27 [Note] /usr/sbin/mysqld: ready for connections.
Version: '5.5.32-0ubuntu0.12.10.1' socket: '/var/run/mysqld/mysqld.sock' port: 3306 (Ubuntu)
131009 17:58:05 [Note] Plugin 'FEDERATED' is disabled.
131009 17:58:05 InnoDB: The InnoDB memory heap is disabled
131009 17:58:05 InnoDB: Mutexes and rw_locks use GCC atomic builtins
131009 17:58:05 InnoDB: Compressed tables use zlib 1.2.7
131009 17:58:05 InnoDB: Using Linux native AIO
131009 17:58:05 InnoDB: Initializing buffer pool, size = 128.0M
131009 17:58:05 InnoDB: Completed initialization of buffer pool
131009 17:58:06 InnoDB: highest supported file format is Barracuda.
InnoDB: The log sequence number in ibdata files does not match
InnoDB: The log sequence number in the ib_logfiles!
131009 17:58:06 InnoDB: Database was not shut down normally!
InnoDB: Starting crash recovery.
InnoDB: Reading tablespace information from the .ibd files...
InnoDB: Restoring possible half-written data pages from the doublewrite
InnoDB: buffer...
131009 17:58:06 InnoDB: Waiting for the background threads to start
131009 17:58:07 InnoDB: 5.5.32 started; log sequence number 242183143
131009 17:58:07 [Note] Server hostname (bind-address): '127.0.0.1'; port: 3306
131009 17:58:07 [Note] - '127.0.0.1' resolves to '127.0.0.1';
131009 17:58:07 [Note] Server socket created on IP: '127.0.0.1'.
131009 17:58:07 [Note] Event Scheduler: Loaded 0 events
131009 17:58:07 [Note] /usr/sbin/mysqld: ready for connections.
Version: '5.5.32-0ubuntu0.12.10.1' socket: '/var/run/mysqld/mysqld.sock' port: 3306 (Ubuntu)
131009 17:58:33 [Note] Plugin 'FEDERATED' is disabled.
131009 17:58:33 InnoDB: The InnoDB memory heap is disabled
131009 17:58:33 InnoDB: Mutexes and rw_locks use GCC atomic builtins
131009 17:58:33 InnoDB: Compressed tables use zlib 1.2.7
131009 17:58:33 InnoDB: Using Linux native AIO
131009 17:58:33 InnoDB: Initializing buffer pool, size = 128.0M
131009 17:58:34 InnoDB: Completed initialization of buffer pool
131009 17:58:34 InnoDB: highest supported file format is Barracuda.
InnoDB: Log scan progressed past the checkpoint lsn 242183143
131009 17:58:34 InnoDB: Database was not shut down normally!
InnoDB: Starting crash recovery.
InnoDB: Reading tablespace information from the .ibd files...
InnoDB: Restoring possible half-written data pages from the doublewrite
InnoDB: buffer...
InnoDB: Doing recovery: scanned up to log sequence number 242183153
131009 17:58:34 InnoDB: Waiting for the background threads to start
131009 17:58:35 InnoDB: 5.5.32 started; log sequence number 242183153
131009 17:58:35 [Note] Server hostname (bind-address): '127.0.0.1'; port: 3306
131009 17:58:35 [Note] - '127.0.0.1' resolves to '127.0.0.1';
131009 17:58:35 [Note] Server socket created on IP: '127.0.0.1'.
131009 17:58:35 [Note] Event Scheduler: Loaded 0 events
131009 17:58:35 [Note] /usr/sbin/mysqld: ready for connections.
Version: '5.5.32-0ubuntu0.12.10.1' socket: '/var/run/mysqld/mysqld.sock' port: 3306 (Ubuntu)
131009 17:58:44 [Note] Plugin 'FEDERATED' is disabled.
131009 17:58:44 InnoDB: The InnoDB memory heap is disabled
131009 17:58:44 InnoDB: Mutexes and rw_locks use GCC atomic builtins
131009 17:58:44 InnoDB: Compressed tables use zlib 1.2.7
131009 17:58:44 InnoDB: Using Linux native AIO
131009 17:58:45 InnoDB: Initializing buffer pool, size = 128.0M
131009 17:58:45 InnoDB: Completed initialization of buffer pool
131009 17:58:45 InnoDB: highest supported file format is Barracuda.
InnoDB: The log sequence number in ibdata files does not match
InnoDB: The log sequence number in the ib_logfiles!
131009 17:58:45 InnoDB: Database was not shut down normally!
InnoDB: Starting crash recovery.
InnoDB: Reading tablespace information from the .ibd files...
InnoDB: Restoring possible half-written data pages from the doublewrite
InnoDB: buffer...
131009 17:58:45 InnoDB: Waiting for the background threads to start
131009 17:58:47 [Note] Plugin 'FEDERATED' is disabled.
131009 17:58:47 InnoDB: The InnoDB memory heap is disabled
131009 17:58:47 InnoDB: Mutexes and rw_locks use GCC atomic builtins
131009 17:58:47 InnoDB: Compressed tables use zlib 1.2.7
131009 17:58:47 InnoDB: Using Linux native AIO
131009 17:58:47 InnoDB: Initializing buffer pool, size = 128.0M
131009 17:58:47 InnoDB: Completed initialization of buffer pool
131009 17:58:47 InnoDB: highest supported file format is Barracuda.
InnoDB: The log sequence number in ibdata files does not match
InnoDB: The log sequence number in the ib_logfiles!
131009 17:58:47 InnoDB: Database was not shut down normally!
InnoDB: Starting crash recovery.
InnoDB: Reading tablespace information from the .ibd files...
InnoDB: Restoring possible half-written data pages from the doublewrite
InnoDB: buffer...
131009 17:58:47 InnoDB: Waiting for the background threads to start
131009 17:58:48 InnoDB: 5.5.32 started; log sequence number 242183153
131009 17:58:48 [Note] Server hostname (bind-address): '127.0.0.1'; port: 3306
131009 17:58:48 [Note] - '127.0.0.1' resolves to '127.0.0.1';
131009 17:58:48 [Note] Server socket created on IP: '127.0.0.1'.
131009 17:58:48 [Note] Event Scheduler: Loaded 0 events
131009 17:58:48 [Note] /usr/sbin/mysqld: ready for connections.
Version: '5.5.32-0ubuntu0.12.10.1' socket: '/var/run/mysqld/mysqld.sock' port: 3306 (Ubuntu)
MySQL이 RAM을 너무 많이 사용했기 때문에 발생한 현상입니다.이 질문과 이 게시물은 모두 테스트 방법과 해결책에 도움이 되었습니다.
저 같은 경우에는 이걸 더해서/etc/mysql/my.cnf파일로 문제를 해결했습니다.
innodb_buffer_pool_size = 12M
할당하는 메모리의 양은 다음과 같습니다.MySQL을 제외한 모든 것을 시작하고 사용 가능한 메모리의 양을 확인합니다.InnoDB 버퍼를 그 양의 10%로 설정합니다.저는 12M이었어요.
크래시 없이 설치를 실행할 수 있는 몇 가지 방법이 있습니다.과거 WordPress에서도 비슷한 문제가 있었습니다만, InnoDB를 올바르게 활용하고 있지 않은 것 같습니다.위의 로그 보기와 포스트에서 중요한 스왑을 추가했지만 아무 것도 하지 않았거나 문제를 악화시켰을 수 있습니다.
우선, 4GB 스왑 메모리는 이러한 소규모 서버에는 너무 큽니다.프로세스 대부분은 스왑 메모리를 통해 사용됩니다.스왑 메모리를 512MB 또는 1GB로 줄이고 문제 슈팅을 수행합니다.다음으로 스왑 구성을 확인합니다.용량이 너무 높으면 시스템이 스왑 메모리를 적극적으로 사용하게 됩니다.이렇게 하면 사이클이 낭비되고 데이터 복구 속도가 느려집니다.너무 낮으면 스왑 메모리가 아예 없는 것과 마찬가지입니다.기본값은 60입니다. 10시부터 시작하여 서버의 "스위트 스폿"을 찾을 때까지 작업하는 것이 좋습니다.시스템에서 Ubuntu를 변경하는 방법은 다음 Ubuntu 문서를 참조하십시오.https://help.ubuntu.com/community/SwapFaq#What_is_swappiness_and_how_do_I_change_it.3F
InnoDB 버퍼는 128.0으로 매우 작습니다.MB. 4GB 스왑 메모리는 MySQL에 의해 조작되지 않을 수 있습니다(따라서 스와프는 Apache/PHP에 의해 사용되고 있을 가능성이 있습니다).그래서 추락한 거겠죠InnoDB를 적어도 2배 늘려주세요.실제로 그 버퍼에 완전한 DB를 넣는 것이 좋습니다만, RAM의 제약으로 인해 불가능하다는 것을 알고 있습니다.RAM 사이즈의 1/2를 목표로 해, 이전에 비해 어떻게 동작하는지를 확인해, 결과에 따라 RAM 사이즈를 낮추거나 늘려 주세요.MySQL Workbench에는 InnoDB 버퍼 사용률을 알려주는 'Server Status' 툴이 있습니다. 이상적으로는 100%(이상적으로는 80-90%) 미만으로 실행되며 스파이크가 발생할 경우 충분한 중복 공간을 확보해야 합니다.
간단한 메모:DB 전체를 RAM에 저장할 경우 보다 견고하고 빈번하게 DB 백업을 수행해야 합니다(변동성이 높고 전원이 모두 들어가 시스템 전원이 차단되면 문제가 발생합니다).
그래도 큰 영향이 없을 경우 WP 사이트에 대한 보다 강력한 캐싱을 검토하십시오.모든 요청에 대해 모든 페이지를 로드하는 것은 매우 부담이 되며, 큰 노력 없이 해결할 수 있습니다.MySQL의 Server Stats 페이지에서 InnoDB 읽기/쓰기 수와 비교하여 사이트에서 실행 중인 초당 쿼리 수를 확인합니다.
저도 비슷한 문제가 있어서 겨우 해결할 수 있었어요.
배경
MySQL 설치와 Apache 구성을 튜닝하는 것을 추천하는 튜토리얼을 여러 번 시도해 보았습니다만, 잘 되지 않았습니다.
문제의 특정
WordPress xmlrpc.php 파일을 대상으로 한 무차별 포스 공격을 받은 것으로 나타났습니다.
이를 확인하려면 apache2 액세스 로그를 보고 의심스러운 POST 요청을 찾아야 합니다.제 경우, /xmlrpc.php 파일에 대한 POST 요구가 같은 IP 주소에서 대량으로 송신되고 있는 것을 발견했습니다(초당 약 2~3건의 요구).
cd /var/log/apache2/
cat access.log
솔루션
이 문제를 해결하기 위해 Iptables를 통해 문제의 IP 주소를 금지했습니다.
악성 IP 주소를 금지한다(예시를 금지하는 임의의 IP 주소로 대체한다).
iptables -A INPUT -s 46.166.139.20 -j DROP
차단된 IP 주소를 보려면:
iptables -L INPUT -v -n
참고 자료: http://www.cyberciti.biz/faq/linux-howto-check-ip-blocked-against-iptables/
나도 비슷한 문제가 있었는데, 근본 원인은 기억력이었어.호스트가 다음 단계를 수행하도록 조언하여 문제를 해결했습니다.
MySQL 구성 파일을 엽니다.
$sudo nano /etc/my.cnf
다음 행을 변경합니다.
max_connections = 50
key_module = 25M
max_allowed_module = 1M
thread_stack = 128K
table_cache = 25
언급URL : https://stackoverflow.com/questions/19282583/mysql-keeps-crashing
'programing' 카테고리의 다른 글
| 리액트 프로젝트에 SCSS 스타일을 추가하는 방법 (0) | 2023.02.26 |
|---|---|
| React를 사용하여 인라인 글꼴 크기 스타일 생성JS (0) | 2023.02.26 |
| 저장 상태 변경 시 React-redux 구성 요소가 다시 렌더링되지 않음 (0) | 2023.02.26 |
| 엔티티 클래스 이름이 밑줄이 있는 SQL 테이블 이름으로 변환됩니다. (0) | 2023.02.26 |
| Maven을 통해 Spring Boot에서 활성 프로파일 구성 (0) | 2023.02.26 |