What is debian-sys-maint used for?
One major thing it is used for is telling the server to roll the logs. It needs at least the reload and shutdown privilege.
See the file /etc/logrotate.d/mysql-server
It is used by the /etc/init.d/mysql script to get the status of the server. It is used to gracefully shutdown/reload the server.
Here is the quote from the README.Debian
* MYSQL WON'T START OR STOP?:
=============================
You may never ever delete the special mysql user "debian-sys-maint". This user
together with the credentials in /etc/mysql/debian.cnf are used by the init
scripts to stop the server as they would require knowledge of the mysql root
users password else.
What is the easiest way to restore it after I've lost it?
The best plan is to simply not lose it. If you really lose the password, reset it, using another account. If you have lost all admin privileges on the mysql server follow the guides to reset the root password, then repair the debian-sys-maint.
You could use a command like this to build a SQL file that you can use later to recreate the account.
mysqldump --complete-insert --extended-insert=0 -u root -p mysql | grep 'debian-sys-maint' > debian_user.sql
Is the password in
/etc/mysql/debian.cnf already hashed
The password is not hashed/encrypted when installed, but new versions of mysql now have a way to encrypt the credentials (see: https://serverfault.com/a/750363).
Usually the queue depth is per LUN/path, in rr multipathing configurations. It's very dependent on the implementation of the multipathing driver and you would have to check with the documentation of your multipathing driver which in your case is the device mapper's multipathing wich AFAIR uses the same concept as ESX in which the queue depth for all paths it the smallest queue depth for any of the paths see my example from ESX here:
ESX's native multipathing configures the queue depth in rr multipathing configurations to be the smallest common depth of any of the involved queues. Ie with a depth of 32 for each LUN/path and 4 paths the total queue depth is only 32!
That's the reason why some vendors offer their own driver (like EMC's powerpath).
From a performance perspective the round robing load distribution ESX doesn't cycle over any given path for each IO, the default schedules the first 1000 IOs go over the first path, the next 1000 IOs over the next on a per VM basis which should smooth the overall load over all paths as an per single IO path switch would incur a latency penalty for each IO.
Best Answer
On recent kernels the
/proc/scsiis being "migrated" to sysfs. You can recompile the kernel and enable theCONFIG_SCSI_PROC_FS: legacy /proc/scsi/ supportto the scsi subsystem, or see if something under/sys/class/scsi_hostand other sysfs dirs have what you need. The legacy support is a good route if you have many tools that rely on /proc/scsi to work.