Làm thế nào để tiêu diệt đúng cách MySQL?


28

Tôi đã cài đặt CentOS 64bit với CPanel và tôi sử dụng:

service mysql stop

Nó chỉ tiếp tục đánh dấu và không bao giờ có vẻ như nó dừng lại. Trong nhật ký, nó chỉ đăng rất nhiều:

130303 17:42:38 [Warning] /usr/sbin/mysqld: Forcing close of thread

Trong err.logtập tin, tôi thấy rất nhiều trong số này:

[Warning] /usr/sbin/mysqld: Forcing close of thread

Nó được sử dụng ngay lập tức. Bất cứ ý tưởng tại sao nó làm điều đó và làm thế nào để khắc phục?

Ngay bây giờ tôi phải làm killall -9 mysqlnhưng có cách nào tốt hơn không?

Máy chủ cũng rất rất hoạt động.

Đây có phải là một vấn đề cấu hình? Tôi có cài đặt memroy quá cao không?

[mysqld]
default-storage-engine=MyISAM
local-infile=0
symbolic-links=0
skip-networking
max_connections = 500
max_user_connections = 20
key_buffer = 512M
myisam_sort_buffer_size = 64M
join_buffer_size = 64M
read_buffer_size = 12M
sort_buffer_size = 12M
read_rnd_buffer_size = 12M
table_cache = 2048
thread_cache_size = 16K
wait_timeout = 30
connect_timeout = 15
tmp_table_size = 64M
max_heap_table_size = 64M
max_allowed_packet = 64M
max_connect_errors = 10
query_cache_limit = 1M
query_cache_size = 64M
query_cache_type = 1
low_priority_updates=1
concurrent_insert=ALWAYS
log-error=/var/log/mysql/error.log
tmpdir=/home/mysqltmp
myisam_repair_threads=4
[mysqld_safe]
open_files_limit = 8192
log-error=/var/log/mysql/error.log

[mysqldump]
quick
max_allowed_packet = 512M

[myisamchk]
key_buffer = 64M
sort_buffer = 64M
read_buffer = 16M
write_buffer = 16M

Câu trả lời:


37

Cách dễ nhất để tắt mysql khi nó chỉ đơn giản là chạy

mysqladmin -uroot -p -h127.0.0.1 --protocol=tcp shutdown

Đây là lý do tại sao:

Tệp dịch vụ mysql ( /etc/init.d/mysql) phụ thuộc vào sự hiện diện của tệp ổ cắm. Về mặt lịch sử, khi quay trở lại MySQL 4.0, tệp socket đôi khi biến mất một cách khó hiểu. Điều này cản trở một tiêu chuẩn service mysql stoptừ làm việc.

Nó không đủ để nói

mysqladmin -uroot -p -h127.0.0.1 shutdown

vì mysqld chí tuyến đường người dùng đến trong như root@127.0.0.1để root@localhostnếu TCP / IP không được kích hoạt một cách rõ ràng. Theo mặc định, mysqld sẽ chọn con đường ít nhất kháng và kết nối root@127.0.0.1đến root@localhostthông qua các tập tin ổ cắm. Tuy nhiên, nếu không có tệp socket, root@localhostsẽ không bao giờ kết nối.

Ngay cả Tài liệu MySQL trên mysqladmin cũng nói điều này:

Nếu bạn thực hiện tắt máy mysqladmin khi kết nối với máy chủ cục bộ bằng tệp ổ cắm Unix, mysqladmin sẽ đợi cho đến khi tệp ID tiến trình của máy chủ bị xóa, để đảm bảo rằng máy chủ đã dừng đúng cách.

Đó là lý do tại sao bắt buộc phải kích hoạt TCP / IP:

mysqladmin -uroot -p -h127.0.0.1 --protocol=tcp shutdown

Trở lại vào ngày 30 tháng 9 năm 2011, tôi đã viết kịch bản phiên bản mysqld_multiđược gọi của riêng mình mysqlservice(Xem bài đăng của tôi: Chạy nhiều phiên bản trên cùng một máy chủ ). Nó phục vụ như một công cụ ảo để kết nối với mysqld từ các cổng khác nhau. Bạn chỉ cần mang theo của riêng bạn my.cnfvới các thông số tùy chỉnh. Trong kịch bản đó, tôi đưa ra các tắt máy như thế này:

stop() {
  ${ECHO} -n $"Stopping ${PROGNAME}"
  ${MYSQLD_STOP}
  ATTEMPTS=0
  STOPPING_MYSQLD=1
  MINUTES_TO_TRY=10
  (( TICKS_TO_TRY = MINUTES_TO_TRY*240 ))
  while [ ${STOPPING_MYSQLD} -eq 1 ]
  do
    ${ECHO} -n "."
    ${SLEEP} 0.25
    MYSQLD_HAS_BEEN_SHUTDOWN=`${TAIL} ${MYSQL_ERROR_LOG} | ${GREP} -c "Shutdown complete$"`
    (( ATTEMPTS++ ))
    if [ ${ATTEMPTS} -eq ${TICKS_TO_TRY}   ] ; then STOPPING_MYSQLD=0 ; fi
    if [ ${MYSQLD_HAS_BEEN_SHUTDOWN} -eq 1 ] ; then STOPPING_MYSQLD=2 ; fi
  done
  ${ECHO}
  if [ ${STOPPING_MYSQLD} -eq 2 ]
  then
    ${ECHO} "Stopped ${PROGNAME}"
  else
    ${TAIL} -30 ${MYSQL_ERROR_LOG}
  fi
}

Nhưng là ${MYSQLD_STOP}gì?

MYSQL_CONN="-uroot -p<rootpassword> -P${MYSQLD_PORT} -h127.0.0.1 --protocol=tcp"
MYSQLD_STOP="${MYSQLADMIN} ${MYSQL_CONN} shutdown"

Xin lưu ý tôi sử dụng 127.0.0.1và một cổng rõ ràng. Bằng cách đó, tôi không dựa vào một tập tin ổ cắm.

Tôi đã luôn luôn sử dụng mysqladmin --protocol=tcp shtudownnhư là sự thay thế thích hợp cho việc tắt máy mysql nếu service mysql stopbị treo. Làm kill -9trên mysqldmysqld_safenên cuối cùng của cuối cùng của những khu nghỉ mát cuối cùng. (Vâng, tôi đã nói ba lần cuối cùng).

Nhiều lần, mysqld đã xóa mysql.sock mà không có cảnh báo. Những người khác cũng đã có vấn đề này trong những năm qua:

TIẾNG VIỆT

Bí mật đúng như tôi đã nêu: Kết nối với mysql bằng mysqladmin thông qua TCP / IP ( --protocol=tcp) và vấn đề shutdown. Điều này phải hoạt động vì đặc quyền tắt máymysql.userdành cho mục đích độc quyền của tắt máy được xác thực. Điều này đã lưu lại ngày làm việc của tôi một vài lần khi tôi có thể thực hiện tắt máy từ xa từ máy Windows của mình khi tắt mysqld trên máy chủ Linux.

CẬP NHẬT 2013 / 03-06 22:48 EST

Nếu bạn lo lắng về những gì đang diễn ra trong quá trình tắt máy, có một cách để thao túng thời gian tắt máy và cách dữ liệu được chuyển vào đĩa, đặc biệt là nếu bạn có nhiều dữ liệu InnoDB trong Bộ đệm

BỀN VỮNG # 1

Nếu bạn có nhiều trang bẩn, bạn có thể hạ innodb_max_denty_pages_pct xuống 0:

SET GLOBAL innodb_max_dirty_pages_pct = 0;

Đặt cái này khoảng 15-30 phút trước khi tắt máy. Điều này sẽ cung cấp cho mysqld số lượng trang bẩn ít nhất có thể để ghi vào đĩa.

BỀN VỮNG # 2

Theo mặc định, innodb_fast_shutdown là 1. Có ba giá trị cho tùy chọn này

  • 0: InnoDB thực hiện tắt máy chậm, thanh lọc toàn bộ và hợp nhất bộ đệm chèn trước khi tắt.
  • 1: InnoDB bỏ qua các hoạt động này khi tắt máy, một quá trình được gọi là tắt máy nhanh.
  • 2: InnoDB tuôn ra các bản ghi của nó và tắt lạnh, như thể MySQL đã bị sập; không có giao dịch cam kết nào bị mất, nhưng hoạt động khôi phục sự cố khiến lần khởi động tiếp theo mất nhiều thời gian hơn.

Tài liệu tiếp tục nói điều này:

Việc tắt máy chậm có thể mất vài phút hoặc thậm chí hàng giờ trong những trường hợp cực đoan mà lượng dữ liệu đáng kể vẫn được đệm. Sử dụng kỹ thuật tắt máy chậm trước khi nâng cấp hoặc hạ cấp giữa các bản phát hành chính của MySQL, để tất cả các tệp dữ liệu được chuẩn bị đầy đủ trong trường hợp quá trình nâng cấp cập nhật định dạng tệp.

Sử dụng innodb_fast_shutdown = 2 trong các tình huống khẩn cấp hoặc khắc phục sự cố, để tắt máy nhanh nhất tuyệt đối nếu dữ liệu có nguy cơ bị hỏng.

Mặc định cho innodb_max_denty_pages_pct và innodb_fast_shutdown sẽ ổn trong hầu hết các trường hợp.


2
Tệp ổ cắm biến mất trên các dẫn xuất của Red Hat vì tmpwatchxóa nó, cùng với mọi thứ khác /tmpcó thời gian cũ hơn ngưỡng được định cấu hình của nó.
Michael - sqlbot

Cảm ơn bạn, @ Michael-sqlbot tôi cần nghe điều đó từ một người nào đó, cuối cùng. Tôi đoán đó là lý do tại sao một người nào đó tại MySQL AB (tiền Oracle, tiền mặt trời) đã quyết định thêm đặc quyền SHUTDOWN mysql.userđể vượt qua những cơn đau đầu như thế này.
RolandoMySQLDBA

Trên Debian hoặc Ubuntu, sử dụng mysqladmin --defaults-file=/etc/mysql/debian.cnf shutdown... tệp đó chứa thông tin đăng nhập cho tài khoản MySQL giống như root.
0xC0000022L

Như thường lệ, @RolandoMySQLDBA bạn là một trong những tài nguyên DBA tốt nhất trên các trang web Stack Exchange. Công việc tuyệt vời ở đây đã giúp tôi hơn 6 năm sau.
JakeGould

5

Có vẻ như câu hỏi của bạn ít hơn về "làm thế nào để" tắt MySQL và nhiều hơn về lý do tại sao câu hỏi của bạn lại tắt quá chậm.

Trong câu trả lời của tôi cho một câu hỏi tương tự , tôi đã đưa ra một số gợi ý để khởi động lại suôn sẻ, giúp đỡ bằng cách giảm số lượng hoạt động phải xảy ra sau khi bạn yêu cầu MySQL bắt đầu quá trình tắt máy .

Nếu bạn không phải là người dùng thường xuyên SHOW FULL PROCESSLIST;của mục số 1, bởi vì bạn cần có ý thức về những gì đang diễn ra trong máy chủ của mình khiến việc tắt máy trở nên rất chậm. Nếu có các truy vấn chạy dài mà an toàn để ngắt, bạn có thể giết chúng bằng KILL <thread-id>.

Tóm lại các đề xuất khác:

Đặt biến toàn cục innodb_fast_shutdown = 1(mặc định) sẽ tăng tốc độ tắt máy của InnoDB. Điều này chỉ an toàn, tuy nhiên, nếu bạn tắt máy chủ vì những lý do không liên quan đến việc thực hiện nâng cấp. Nếu bạn đang tắt để nâng cấp, thì điều này phải được đặt thành 0.

Sử dụng FLUSH TABLES;duyên dáng đóng tất cả các bảng mở. Chúng sẽ được mở lại nếu được tham chiếu bởi các truy vấn tiếp theo, nhưng hành động này cuối cùng vẫn sẽ giảm thời gian trôi qua giữa thời gian bạn yêu cầu tắt máy và thời gian tắt máy hoàn tất, bởi vì nó thực hiện một số công việc vệ sinh sớm và quan trọng hơn là nó tạo ra giai đoạn cho bước cuối cùng ...

FLUSH TABLES WITH READ LOCK;đóng tất cả các bảng đang mở và có được một khóa độc quyền thuộc sở hữu của kết nối máy khách hiện tại của bạn để ngăn mọi kết nối khác ghi vào bất kỳ bảng nào trên toàn bộ máy chủ. Bạn sẽ không nhận được mysql>lời nhắc của mình cho đến khi bạn sở hữu khóa này, tại thời điểm đó bạn có thể đưa ra yêu cầu tắt máy - nhưng không ngắt kết nối với phiên này.

Trên một máy chủ bận rộn, các bước này sẽ làm giảm mức độ hoạt động trên máy chủ, sẽ khiến mọi thứ yên tĩnh hơn nhiều và sẽ giúp việc tắt máy hoặc khởi động lại diễn ra suôn sẻ hơn.


2

MySQL có thể không hoàn toàn bị khóa, nhưng đang thực hiện các hoạt động dọn dẹp (rollback, v.v.) khi tắt. Nếu bạn không để nó làm tất cả những điều đó khi tắt máy, thường bạn sẽ phải chờ khi bắt đầu.

Đây là một cái gì đó để xem xét: Tắt mysql trong một cửa sổ đầu cuối trong khi xem nhật ký lỗi (tail -f [yourerror.log]) trong một cửa sổ đầu cuối khác. Nhật ký lỗi sẽ cho bạn thấy MySQL đang làm gì.


1

Tôi rất tiếc khi nghe về trải nghiệm của bạn và hy vọng rằng trải nghiệm của tôi với các kịch bản MySQL ngớ ngẩn, tương tự như thế này, có thể giúp bạn hiểu.

Thay vì cố gắng tìm ra cách tiêu diệt dịch vụ MySQL khỏi máy chủ, trong một số trường hợp, bạn sẽ cần kiểm tra sức khỏe hệ thống của mình thông qua các cách sau để xác định xem có lạm dụng dịch vụ hay không ( giả định dựa trên khái niệm về một Môi trường CentOS / RHEL ):

 /usr/bin/iostat
 /usr/bin/uptime
 top -c

Sử dụng cách sau để xác định tải hệ thống trung bình và tài nguyên tiêu thụ hàng đầu trong hệ thống.

Bạn cũng sẽ cần cài đặt mytopđể có cái nhìn tổng thể về các câu lệnh SQL đang được hệ thống xử lý.

Để cài đặt mytop, chỉ cần thực hiện như sau:

 cd /root
 wget http://jeremy.zawodny.com/mysql/mytop/mytop-1.6.tar.gz
 tar -zxvf /root/mytop-1.6.tar.gz
 cd /root/mytop-1.6
 perl Makefile.pl
 make
 make install
 chmod 644 /usr/local/bin/mytop
 vi /usr/local/bin/mytop 

(sử dụng bất kỳ trình soạn thảo văn bản nào bạn thích)

Tìm kiếm "long|!" => \$config{long_nums},

Nhận xét nó như là #"long|!" => \$config{long_nums},

chmod 555 /usr/local/bin/mytop

Và bạn là tốt để đi với mytop . Sử dụng nó để kiểm tra các câu lệnh MySQL đang ăn cắp dịch vụ MySQL của bạn và ngăn chặn chúng.

Việc thực hiện các hướng dẫn trên sẽ cung cấp cho bạn khả năng sau:

  • Chẩn đoán tình trạng / sức khỏe của máy chủ của bạn
  • Chẩn đoán nguyên nhân tắc nghẽn của bạn

Khi bạn đã loại bỏ nguyên nhân của nút cổ chai, bạn sẽ có một ngày dễ dàng hơn khi bạn cố gắng khởi động lại dịch vụ MySQL. Tôi hy vọng rằng bạn sẽ tìm thấy thông tin trên hữu ích.

Lưu ý: mytop là cổ xưa và không rõ ràng. Bạn có thể nên sử dụng innotoptrên một hệ thống hiện đại.


0

Việc triển khai tiêu chuẩn init-script của MySQL báo hiệu MySQL bằng SIGTERM và chờ một khoảng thời gian nhất định để MySQL tắt.

MySQL, sau khi nhận được SIGTERM, trước tiên sẽ dừng nhận các kết nối mới, sau đó hoàn tất thực hiện bất kỳ truy vấn nào đang chờ xử lý (việc này có thể mất một lúc, tùy thuộc vào khối lượng công việc và số lượng máy khách đồng thời của bạn), sau đó bắt đầu chuyển dữ liệu vào đĩa (việc này có thể mất một thời gian dài, một lần nữa tùy thuộc vào khối lượng công việc, cấu hình, bộ nhớ khả dụng và lựa chọn công cụ lưu trữ của bạn). Sau khi hoàn tất việc xóa dữ liệu, MySQL sẽ phân bổ bất kỳ bộ nhớ nào được phân bổ trong giai đoạn khởi tạo (điều này cũng có thể mất một lúc, tùy thuộc vào lượng bộ nhớ được phân bổ bởi MySQL), đóng tất cả các thẻ xử lý vẫn mở, sau đó gọi "thoát (0)".

Nếu sau khi yêu cầu tắt máy của bạn, MySQL mất nhiều thời gian để tắt, thì có thể một hoặc nhiều giai đoạn này sẽ mất nhiều thời gian để hoàn thành. Nếu bạn có thời gian, tôi thực sự khuyên bạn nên đợi quá trình hoàn tất (điều này sẽ tránh mất dữ liệu hoặc quá trình khôi phục lâu khi bạn bắt đầu lại trường hợp cơ sở dữ liệu của mình).

Thật không may, không có đủ thông tin trong câu hỏi của bạn để cho phép tôi đề xuất một giải pháp thích hợp cho vấn đề của bạn. Tôi hy vọng điều này sẽ giúp hiểu vấn đề.

Khi sử dụng trang web của chúng tôi, bạn xác nhận rằng bạn đã đọc và hiểu Chính sách cookieChính sách bảo mật của chúng tôi.
Licensed under cc by-sa 3.0 with attribution required.