কীভাবে সঠিকভাবে মাইএসকিউএল বধ করবেন?


28

আমি সিপানেল ইনস্টল করে সেন্টোজ bit৪ বিট স্থাপন করেছি এবং আমি ব্যবহার করি:

service mysql stop

এটি কেবল পর্যায়ক্রমে টিকটিকি রাখে এবং কখনই বন্ধ হয়ে যায় বলে মনে হয় না। লগগুলিতে এটি কেবল প্রচুর পোস্ট করে:

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

ইন err.logফাইল, আমি এই প্রচুর দেখুন:

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

তাত্ক্ষণিকভাবে ব্যবহৃত হত। কোনও ধারণা কেন এটি করে এবং কীভাবে ঠিক করবেন?

এখনই আমাকে করতে হবে killall -9 mysqlতবে এর থেকে আরও ভাল উপায় কি আছে?

সার্ভারটিও খুব সক্রিয়।

এটি কি কনফিগার সমস্যা? আমার কি স্মৃতিশক্তি সেটিংস খুব বেশি আছে?

[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

উত্তর:


37

শাটডাউন মাইএসকিএল করার সর্বাপেক্ষা সহজ উপায় এটি চালানো সহজ simply

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

এখানে কেন:

Mysql পরিষেবা ফাইল ( /etc/init.d/mysql) সকেট ফাইলের উপস্থিতির উপর নির্ভর করে। Orতিহাসিকভাবে বলতে গেলে, মাইএসকিউএল ৪.০-তে ফিরে যেতে সকেট ফাইলটি কখনও কখনও অনভিজ্ঞভাবে অদৃশ্য হয়ে যায়। এটি service mysql stopকাজ করা থেকে একটি মানকে বাধা দেয় ।

বলা বাহুল্য নয়

mysqladmin -uroot -p -h127.0.0.1 shutdown

কারণ টিএসসিপি / আইপি স্পষ্টভাবে সক্ষম না root@127.0.0.1করা root@localhostহলে মাইএসকিএলডি কোনও ব্যবহারকারীকে আসবে । ডিফল্টরূপে, mysqld প্রতিরোধের অন্তত পথ বেছে এবং সংযুক্ত করবে root@127.0.0.1করার root@localhostসকেট ফাইল মাধ্যমে। তবুও, যদি কোনও সকেট ফাইল root@localhostনা থাকে তবে কখনও সংযুক্ত হবে না।

এমনকি মাইসক্ল্যাডমিনে মাইএসকিউএল ডকুমেন্টেশন এটি বলে:

আপনি যদি ইউনিক্স সকেট ফাইলটি ব্যবহার করে কোনও স্থানীয় সার্ভারের সাথে সংযোগ স্থাপনের সময় মাইসক্ল্যাডমিন শাটডাউনটি সম্পাদন করেন তবে সার্ভারটি সঠিকভাবে বন্ধ হয়ে গেছে কিনা তা নিশ্চিত করার জন্য মাইসক্ল্যাডমিন সার্ভারের প্রক্রিয়া আইডি ফাইলটি সরিয়ে না দেওয়া পর্যন্ত অপেক্ষা করে।

এজন্য টিসিপি / আইপি সক্ষম করা জরুরি:

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

৩০ শে সেপ্টেম্বর, ২০১১ এ, আমি আমার নিজের mysqld_multiনামে পরিচিত সংস্করণটি স্ক্রিপ্ট করেছি mysqlservice(আমার পোস্টটি দেখুন: একই হোস্টে একাধিক ঘটনা চালানো )। এটি বিভিন্ন বন্দর থেকে মাইএসকিএলডে সংযোগের জন্য ভার্চুয়াল ইঞ্জিন হিসাবে কাজ করে। আপনার নিজের my.cnfপছন্দসই পরামিতিগুলি নিয়ে আসতে হবে bring সেই স্ক্রিপ্টে, আমি এই জাতীয় শাটডাউন জারি করি:

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
}

তবে কী ${MYSQLD_STOP}?

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

আমি 127.0.0.1এবং আমি একটি স্পষ্টত বন্দর লক্ষ করুন । এইভাবে, আমি কোনও সকেট ফাইলে নির্ভর করি না।

স্তব্ধ হয়ে mysqladmin --protocol=tcp shtudownথাকলে আমি সবসময় মাইএসকিএল বন্ধ করার উপযুক্ত বিকল্প হিসাবে ব্যবহার করেছি service mysql stop। এরকম kill -9উপর mysqldএবং mysqld_safeগত রিসর্ট গত মাসের শেষ করা উচিত। (হ্যাঁ, আমি গত তিনবার বলেছি)।

অনেক সময়, মাইএসকিএলডি কোনও সতর্কতা ছাড়াই mysql.sock মুছে ফেলেছে। অন্যান্য লোকেরাও বছরের পর বছর ধরে এই সমস্যাটি নিয়েছিলেন:

উপসংহার

গোপনটি ঠিক যেমনটি আমি বলেছি: টিসিপি / আইপি ( ) এবং ইস্যু করে মাইএসক্ল্যাডমিন ব্যবহার করে মাইএসকিউএলে সংযুক্ত করুন । এই কাজ করা হয়েছে কারণ হরতাল বিশেষাধিকার হয় প্রামাণ হরতালের একচ্ছত্র উদ্দেশ্যে নয়। লিনাক্স সার্ভারে মাইএসকিএলডি বন্ধ করার সময় আমি যখন আমার উইন্ডোজ মেশিন থেকে রিমোট শাটডাউন দিতে সক্ষম হয়েছি তখন এটি আমার কাজের দিন কয়েকবার বাঁচিয়েছে।--protocol=tcpshutdownmysql.user

আপডেট 2013-03-06 22:48 EST

আপনি যদি শাটডাউন চলাকালীন কী ঘটছে তা নিয়ে চিন্তিত হয়ে থাকেন তবে শাটডাউন সময়টি কীভাবে চালিত হবে এবং যেভাবে ডেটা ডিস্কে প্রবাহিত হবে তা বিশেষভাবে যদি আপনার বাফার পুলে প্রচুর InnoDB ডেটা থাকে

পরামর্শ # 1

আপনার যদি প্রচুর নোংরা পৃষ্ঠাগুলি থাকে তবে আপনি ইনোডাব_ম্যাক্স_ডাল্টি_পৃষ্ঠাগুলি_পৃষ্ঠাটি 0 তে কমিয়ে দিতে পারেন :

SET GLOBAL innodb_max_dirty_pages_pct = 0;

শাটডাউনের প্রায় 15-30 মিনিট আগে এটি সেট করুন। এটি ডিস্কে লেখার জন্য কমপক্ষে সম্ভাব্য নোংরা পৃষ্ঠাগুলি মাইএসকিএলডি দেবে।

পরামর্শ # 2

ডিফল্টরূপে, ইনোডব_ফেস_শুটডাউন হয় ১। এই বিকল্পের জন্য তিনটি মান রয়েছে

  • 0: ইনোডিবি বন্ধ করার আগে একটি ধীর শটডাউন, একটি পুরোপুরিজ এবং একটি ইনসার্ট বাফার মার্জ করে।
  • 1: ইনোডিবি এই অপারেশনগুলিকে শাটডাউন এড়িয়ে দেয়, এটি একটি প্রক্রিয়া একটি দ্রুত শাটডাউন হিসাবে পরিচিত।
  • 2: InnoDB তার লগগুলি ফ্লাশ করে এবং শীতল বন্ধ করে দেয়, যেন মাইএসকিউএল ক্র্যাশ হয়ে গেছে; কোনও প্রতিশ্রুতিবদ্ধ লেনদেন হারিয়ে যায় না, তবে ক্র্যাশ পুনরুদ্ধার অপারেশন পরবর্তী প্রারম্ভিকালে আরও বেশি সময় নেয়।

ডকুমেন্টেশন আরও বলে:

ধীর এই শাটডাউনটি কয়েক মিনিট সময় নিতে পারে এমনকি এমন কয়েক ঘন্টা এমনকি কয়েক ঘন্টা সময় নিতে পারে যেখানে পর্যাপ্ত পরিমাণে ডেটা বাফার হয়। মাইএসকিউএল প্রধান রিলিজগুলির মধ্যে আপগ্রেড বা ডাউনগ্রেড করার আগে ধীর শটডাউন প্রযুক্তিটি ব্যবহার করুন, যাতে আপগ্রেড প্রক্রিয়া ফাইলের ফর্ম্যাট আপডেট করে তবে সমস্ত ডেটা ফাইল সম্পূর্ণ প্রস্তুত থাকে।

ডেটা দুর্নীতির ঝুঁকিতে থাকলে নিরঙ্কুশতম দ্রুততম শাটডাউন পেতে জরুরি বা সমস্যা সমাধানের পরিস্থিতিতে ইনোডাব_ফেস_শুটডাউন = 2 ব্যবহার করুন।

ইনোডাব_ম্যাক্স_ডার্টি_পেজ_প্যাক্ট এবং ইনোডাব_ফেষ্ট_শুটডাউন এর জন্য ডিফল্ট বেশিরভাগ ক্ষেত্রে ঠিক হওয়া উচিত।


2
সকেট ফাইলটি রেড হ্যাট ডেরিভেটিভসে অদৃশ্য হয়ে যায় কারণ tmpwatchএটির সাথে এটির সাথে মুছে ফেলা সমস্ত কিছু /tmpতার কনফিগার থ্রেশহোল্ডের চেয়ে কিছু সময়ের চেয়ে পুরানো থাকে।
মাইকেল - স্ক্যলবট

আপনাকে ধন্যবাদ, @ মাইকেল-স্ক্লবট আমাকে কারও কাছ থেকে শুনতে হয়েছিল, শেষ পর্যন্ত। আমি অনুমান করি এজন্যই মাইএসকিউএল এবি (প্রাক-ওরাকল, প্রাক-সান) এ থাকা কেউ mysql.userমাথা খারাপ করার মতো শটডাউন সুবিধা যুক্ত করার সিদ্ধান্ত নিয়েছে ।
রোল্যান্ডোমাইএসকিউএলডিবিএ

ডেবিয়ান বা উবুন্টু ব্যবহারে mysqladmin --defaults-file=/etc/mysql/debian.cnf shutdown... সেই ফাইলটিতে মূলের মতো মাইএসকিউএল অ্যাকাউন্টের শংসাপত্র রয়েছে।
0xC0000022L

যথারীতি, @ রোল্যান্ডোমাইএসকিউএলডিবিএ আপনি স্ট্যাক এক্সচেঞ্জ সাইটের সেরা ডিবিএ সংস্থানগুলির মধ্যে একটি। এখানে দুর্দান্ত কাজ যা 6+ বছর পরে আমাকে সহায়তা করেছিল।
জ্যাকগল্ড

5

দেখে মনে হচ্ছে আপনার মাইএসকিউএল "কীভাবে" বন্ধ করবেন এবং আপনার এত ধীরে ধীরে কেন বন্ধ হচ্ছে সে সম্পর্কে আপনার প্রশ্ন কম।

ইন একটি অনুরূপ প্রশ্নের আমার উত্তর , আমি একটি মসৃণ পুনর্সূচনা, যা কার্যকলাপ পরিমাণ আপনাকে অনুরোধ পর যে মাইএসকিউএল শুরু ঘটতে আছে কমিয়ে সাহায্যের জন্য কিছু প্রস্তাবনা দেওয়া শাটডাউন প্রক্রিয়া

আপনি যদি SHOW FULL PROCESSLIST;সেই আইটেম # 1 এর ঘন ঘন ব্যবহারকারী না হন , কারণ আপনার সার্ভারে শাটডাউনটি এত ধীরে ধীরে কী ঘটছে তা অনুধাবন করা দরকার। যদি দীর্ঘ-চলমান প্রশ্নগুলি থাকে যা বাধা দেওয়ার জন্য নিরাপদ থাকে তবে আপনি সেগুলি দিয়ে হত্যা করতে পারেন KILL <thread-id>

অন্যান্য পরামর্শগুলি পুনরায় গ্রহণ করা:

গ্লোবাল ভেরিয়েবল innodb_fast_shutdown = 1(ডিফল্ট) সেট করা শাটডাউনটির InnoDB- এর অংশকে গতিবেগিত করবে। এটি কেবল নিরাপদ, তবে আপনি যদি আপগ্রেড করার সাথে সম্পর্কিত না থাকায় সার্ভারটি বন্ধ করে দিচ্ছেন। যদি আপনি কোনও আপগ্রেডের জন্য বন্ধ করে থাকেন তবে এটি অবশ্যই 0 এ সেট করা উচিত

FLUSH TABLES;কৌতুকপূর্ণভাবে ব্যবহার করা সমস্ত উন্মুক্ত টেবিলগুলি বন্ধ করে দেয়। পরবর্তী প্রশ্নের সাথে রেফারেন্স দিলে এগুলি পুনরায় খোলা হবে, তবে এই ক্রিয়াটি আপনার চূড়ান্তভাবে শাটডাউন করার অনুরোধ করার সময় এবং শটডাউনটি সম্পূর্ণ হওয়ার সময়কালের মধ্যে যে সময়টি অতিক্রান্ত হবে তা অবশেষে কমিয়ে দেওয়া উচিত, কারণ এটি কিছুটা প্রাথমিক গৃহকর্ম সম্পাদন করে এবং আরও গুরুত্বপূর্ণভাবে এটি মঞ্চটি নির্ধারণ করে sets চূড়ান্ত পদক্ষেপের জন্য ...

FLUSH TABLES WITH READ LOCK;সমস্ত উন্মুক্ত টেবিলগুলি বন্ধ করে এবং আপনার বর্তমান ক্লায়েন্ট সংযোগের মালিকানাধীন একটি এক্সক্লুসিভ লক প্রাপ্ত করে যা পুরো সার্ভারে কোনও টেবিলে অন্য কোনও সংযোগকে লেখা থেকে বাধা দেয়। আপনি mysql>এই লকটির মালিক না হওয়া অবধি আপনার প্রম্পটটি আর পাবেন না, আপনি যে মুহুর্তে শাটডাউন অনুরোধটি জারি করতে পারবেন - তবে এই অধিবেশনটি থেকে সংযোগ বিচ্ছিন্ন করবেন না।

একটি ব্যস্ত সার্ভারে, এই পদক্ষেপগুলির দ্বারা সার্ভারের ক্রিয়াকলাপের মাত্রা হ্রাস করা উচিত, জিনিসগুলিকে আরও শান্ত করা উচিত, এবং শাটডাউন তৈরি করতে বা পুনরায় চালু করতে আরও সহজভাবে সহায়তা করা উচিত।


2

এটি সম্ভাব্য মাইএসকিউএল সম্পূর্ণরূপে লকড নয়, বন্ধ করার সময় ক্লিনআপ ক্রিয়াকলাপগুলি (রোলব্যাকস, ইত্যাদি) করছে। বন্ধ করার সময় যদি আপনি এটি সব না করতে দেন, প্রায়শই আপনাকে শুরু করার সময় অপেক্ষা করতে হবে।

এখানে দেখার মতো কিছু বিষয় রয়েছে: অন্য টার্মিনাল উইন্ডোতে ত্রুটি লগ (টেইল -f [yourerror.log]) দেখার সময় একটি টার্মিনাল উইন্ডোতে শাটডাউন মাইএসকিএল। ত্রুটি লগ মাইএসকিউএল করছে তা আপনাকে দেখাবে।


1

আমি আপনার অভিজ্ঞতার কথা শুনে দুঃখিত এবং আশা করি যে এটির মতো মিলে মাইএসকিউএল দৃশ্যের সাথে আমার অভিজ্ঞতা আপনাকে সহায়তা করতে পারে।

সার্ভার থেকে মাইএসকিউএল পরিষেবাটি কীভাবে বন্ধ করতে হবে তা নির্ধারণের পরিবর্তে, কোনও ক্ষেত্রে অপব্যবহার হয়েছে কিনা তা নির্ধারণ করার জন্য আপনাকে নীচের মাধ্যমে আপনার সিস্টেমের স্বাস্থ্য পরীক্ষা করতে হবে ( অনুমানটি একটি ধারণাটির উপর ভিত্তি করে তৈরি করা হয়েছে) CentOS / RHEL পরিবেশ ):

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

সিস্টেমের মধ্যে গড় সিস্টেম লোড এবং উচ্চ-গ্রাহক সংস্থানগুলি সনাক্ত করতে নিম্নলিখিত ব্যবহার করুন।

mytopসিস্টেম দ্বারা প্রক্রিয়াজাত হওয়া এসকিউএল স্টেটমেন্টগুলিতে সামগ্রিক দৃষ্টিভঙ্গি পেতে আপনাকে ইনস্টল করতে হবে।

স্থাপন করা mytop , কেবল নিম্নলিখিতটি সম্পাদন করুন:

 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 

(আপনার পছন্দের কোনও পাঠ্য সম্পাদক ব্যবহার করুন)

অনুসন্ধান করুন "long|!" => \$config{long_nums},

এটি হিসাবে মন্তব্য করুন #"long|!" => \$config{long_nums},

chmod 555 /usr/local/bin/mytop

এবং আপনি সঙ্গে যেতে ভাল মাইটোপ । মাইএসকিউএল বিবৃতি যা আপনার মাইএসকিউএল পরিষেবা হগিং করছে তা পরীক্ষা করে দেখতে এবং এগুলি বন্ধ করতে এটি ব্যবহার করুন।

উপরোক্ত নির্দেশাবলীর সম্পাদন আপনাকে নিম্নলিখিত ক্ষমতা প্রদান করবে:

  • আপনার সার্ভারের স্থিতি / স্বাস্থ্য নির্ণয়
  • আপনার বাধা কারণ নির্ণয়

একবার আপনি যদি বাধা-বিপত্তিটির কারণটি নির্মূল করে ফেলেন, আপনি যখন মাইএসকিউএল পরিষেবাটি পুনরায় চালু করার চেষ্টা করবেন তখন আপনার একটি সহজ দিন হওয়া উচিত। আমি আশা করি যে আপনি উপরের তথ্যটি দরকারী পেয়ে যাবেন।

দ্রষ্টব্য: mytop প্রাচীন এবং অবিস্মরণীয়। আপনার সম্ভবত innotopএকটি আধুনিক সিস্টেমে ব্যবহার করা উচিত ।


0

মাইএসকিউএল'র আর্টি-স্ক্রিপ্টের মানক প্রয়োগটি মাইএসকিউএলকে সিগিটারের সাথে সংকেত দেয় এবং মাইএসকিউএল বন্ধ হয়ে যাওয়ার জন্য নির্দিষ্ট সময়ের জন্য অপেক্ষা করে।

মাইএসকিউএল, একটি সিগনটার্ম পাওয়ার পরে প্রথমে নতুন সংযোগ গ্রহণ বন্ধ করে দেবে, তারপরে যেই প্রশ্নগুলি এখনও মুলতুবি অবস্থায় রয়েছে তা সম্পাদন সম্পূর্ণ করবে (এটি আপনার কাজের চাপ এবং সমগতিশীল ক্লায়েন্টের সংখ্যার উপর নির্ভর করে কিছুটা সময় নিতে পারে), তারপরে ডিস্কে ডেটা ফ্লাশ করা শুরু করবে (এটি নিতে পারে আপনার কাজের চাপ, কনফিগারেশনগুলি, উপলব্ধ মেমরি এবং স্টোরেজ ইঞ্জিন পছন্দগুলির উপর নির্ভর করে) দীর্ঘ সময়। সমস্ত ডেটা-ফ্লাশিং শেষ হওয়ার পরে, মাইএসকিউএল শুরু করার সময় যা কিছু মেমরি বরাদ্দ করেছিল তা হ্রাস করবে (এটি মাইএসকিউএল দ্বারা বরাদ্দ মেমরির পরিমাণের উপর নির্ভর করে কিছু সময় নিতে পারে), সমস্ত ফাইল হ্যান্ডলগুলি এখনও খোলা বন্ধ করে, এবং তারপরে কল করুন "প্রস্থান (0)"।

যদি আপনার বন্ধের জন্য মাইএসকিউএল অনুরোধটি বন্ধ করতে বেশ সময় নিচ্ছে, তবে এটি বেশ সম্ভব যে এই এক বা একাধিক পর্যায়টি সম্পূর্ণ হতে দীর্ঘ সময় নিচ্ছে। আপনার যদি সময় থাকে তবে আমি দৃ strongly়ভাবে প্রক্রিয়াটি শেষ হওয়ার জন্য অপেক্ষা করার পরামর্শ দিচ্ছি (আপনি যখন আপনার ডাটাবেস উদাহরণটি আবার শুরু করবেন তখন এটি ডেটা-হ্রাস বা দীর্ঘ পুনরুদ্ধার প্রক্রিয়া এড়াতে পারে)।

দুর্ভাগ্যক্রমে আপনার প্রশ্নের যথেষ্ট তথ্য নেই যা আমাকে আপনার সমস্যার উপযুক্ত সমাধানের পরামর্শ দেওয়ার অনুমতি দেয়। আমি আশা করি এটি বিষয়টি বুঝতে সহায়তা করে।

আমাদের সাইট ব্যবহার করে, আপনি স্বীকার করেছেন যে আপনি আমাদের কুকি নীতি এবং গোপনীয়তা নীতিটি পড়েছেন এবং বুঝতে পেরেছেন ।
Licensed under cc by-sa 3.0 with attribution required.