"Tells the slave thread to continue replication when a query returns an error from the provided list. Normally, replication will discontinue when an error is encountered, giving the user a chance to resolve the inconsistency in the data manually. Do not use this option unless you fully understand why you are getting the errors. If there are no bugs in your replication setup and client programs, and no bugs in MySQL itself, you should never get an abort with error. Indiscriminate use of this option will result in slaves being hopelessly out of sync with the master and you having no idea how the problem happened. For error codes, you should use the numbers provided by the error message in your slave error log and in the output of SHOW SLAVE STATUS. Full list of error messages can be found in the source distribution in `Docs/mysqld_error.txt'. You can (but should not) also use a very non-recommended value of all which will ignore all error messages and keep barging along regardless. Needless to say, if you use it, we make no promises regarding your data integrity. Please do not complain if your data on the slave is not anywhere close to what it is on the master in this case -- you have been warned. Example: slave-skip-errors=1062,1053 or slave-skip-errors=all",
"Tells the slave thread to continue replication when a query returns an error from the provided list",
0,0,0,GET_STR,REQUIRED_ARG,0,0,0,0,0,0},
{"socket",OPT_SOCKET,"Socket file to use for connection",
"Using this option will cause most temporary files created to use a small set of names, rather than a unique name for each new file. This is to work around a problem in the Linux kernel dealing with creating a bunch of new files with different names. With the old behavior, Linux seems to 'leak' memory, as it's being allocated to the directory entry cache instead of the disk cache.",
"Using this option will cause most temporary files created to use a small set of names, rather than a unique name for each new file.",