标签：replica 信息 std 手动 条件 适合 win cat 错误日志
在UNIX系统上，本地客户以localhost为主机名建立MySQL连接，该过程是通过一个UNIX套接字文件（比如说，/tmp/mysql.sock文件）实现的。如果这个套接字文件被删除掉了，本地客户因为无法找到这个连接，就无法连接MySQL服务器。此时，必须建立一条TCP/IP连接，即使用127.0.0.1而不是localhost作为—host（主机名/主机地址）参数值去连接本地主机上的MySQL服务器：
mysqladmin -h127.0.0.1 -uroot -p shutdown
127.0.0.1是一个IP地址值（本地主机的回馈地址），所以这条命令将强制性地建立起一条TCP/IP连接而不是建立起一条套接字连接。关闭MySQL服务器后，再重新以localhost为主机名启动，它就会重新创建出一个套接字文件来。
如果用户是因为忘记或者不知道root口令而无法连接MySQL服务器，就需要重新获得对MySQL服务器的控制才能重新设置root口令，重新设置root口令的过程如下：
（1）关闭MySQL服务器。在UNIX系统上，如果能登录为MySQL服务器主机上的root用户，可以使用kill命令结束MySQL服务器的运行。先从MySQL服务器的PID文件（这个文件通常可以在MySQL数据目录里找到）或者使用ps命令查出MySQL服务器的进程ID，然后向MySQL服务器进程发出一个TERM信号让它结束运行,kill -TERM PID,MySQL服务器在收到TERM信号后会把内存中的数据表和日志信息写入磁盘。如果MySQL服务器因为种种原因而没有对这个正常终止信息做出响应，可以使用kill-9命令强行终止它。不到万不得已，最好不要使用kill -9 PID进行强行终止；因为强行终止MySQL服务器进程往往会使MySQL来不及把内存中的信息写入磁盘而造成数据表里的数据不完整。
Linux系统上的ps命令可能会列出几个mysqld“进程”。这些“进程”其实只是同一MySQL服务器进程的多个线程，只要终止其中的任何一个，就能把它们全部终止。
如果你是用mysql_safe脚本去启动MySQL服务器的，这个脚本将监控着MySQL服务器的运行情况并在它被终止时立刻重新启动。此时，应该先查出mysqld_safe进程的PID并终止mysqld_safe进程，然后才能真正终止mysqld进程。
如果把MySQL服务器运行为windows系统上的一项服务，那么，即便不知道它的口令，也能通过windows的“Services Manager”（服务管理器）或者下面这条命令正常地结束它的运行；C：\＞net stop mysql
在windows系统上，还可以通过“Task Manager”（任务管理器）来强行终止MySQL服务器的运行。这相当于UNIX系统上的kill-9命令，不到万不得已，最好不要这样做。
（2）用--skip_grant_tables选项重新启动MySQL服务器。此时，MySQL服务器将不使用它的权限表对连接操作进行身份验证，而用户就能在不提供root口令的情况下连接上MySQL服务器并获得全部的权限了。但这等于是完全解除MySQL服务器的安全防线，并让别人也能以同样的方法连接上MySQL服务器，所以应该在连接上MySQL服务器之后尽快发出一条FLUSH PRIVILEGES语句：
mysql
FLUSH PRIVILEGES；
使权限表读入内存并生效，以阻止其他的连接。该语句还重新激活grant语句，在MySQL服务器不使用权限表时，grant语句被禁用。
（3）修改完root口令后，应该关闭MySQL服务器并按正常启动过程再次启动即可。
默认情况下，所有日志创建于mysqld数据目录中。通过刷新日志，你可以强制mysqld来关闭和重新打开日志文件（或者在某些情况下切换到一个新的日志）。当你执行一个FLUSH LOGS语句或执行mysqladmin flush -logs或mysqladmin refresh时，出现日志刷新。如果你正使用MySQL复制功能，从复制服务器将维护更多日志文件，被称为接替日志。
错误日志（error log）记载着MySQL数据库系统的诊断和出错信息。如果mysqld莫名其妙地“死掉”并且mysqld_safe需要重新启动它，mysqld_safe在错误日志中写入一条restarted mysqld消息。如果mysqld注意到需要自动检查或者修复一个表，则错误日志中写入一条消息。
在一些操作系统中，如果mysqld“死掉”，错误日志包含堆栈跟踪信息。跟踪信息可以用来确定mysqld“死掉”的地方，并可以用--log -error=file_name选项来指定mysqld保存错误日志文件的位置。如果没有指定file_name值，mysqld使用错误日志名host_name.err，并在数据目录中写入日志文件。如果执行FLUSH LOGS，错误日志用-old重新命名后缀，并且mysqld创建一个新的空日志文件。（如果未给出--log-error选项，则不会重新命名）。
如果不指定--log-error，或者（在Windows中）使用--console选项，错误被写入标准错误输出stderr。通常标准输出为服务器的终端。
在Windows中，如果未给出--console选项，错误输出总是写入.err文件。
如果想要知道mysqld内部发生了什么，应该用--log=file_name或-l file_name选项启动它。如果没有指定file_name的值，默认名是host_name.log，所有连接和语句被记录到日志文件。如果怀疑在客户端发生了错误并想确切地知道该客户端发送给mysqld的语句时，该日志可能非常有用。
mysqld按照它接收的顺序记录语句到查询日志。这可能与执行的顺序不同，与更新日志和二进制日志不同，它们在查询执行后，任何一个锁释放之前记录日志。（查询日志还包含所有语句，而二进制日志不包含只查询数据的语句）。
服务器重新启动和日志刷新不会产生一个的新查询日志文件。在UNIX中，可以通过下面的命令重新命名文件并创建一个新文件：
shell＞mv hostname.log hostname-old.log
shell＞mysqladmin flush -logs
shell＞cp hostname-old.log to-backup-directory
shell＞rm hostname-old.log
在Windows中，服务器打开日志文件期间不能重新命名日志文件。首先，必须停止服务器，然后重新命名日志文件；最后，重启服务器来创建新的日志文件。
二进制日志包含所有更新的数据或者已经潜在更新的数据（例如，没有匹配任何行的一个DELETE）的所有语句。语句以“事件”的形式保存，它描述数据更改。
ps:二进制日志已经代替了老的更新日志，更新日志在MySQL 5.1中不再使用。
二进制日志还包含关于每个更新数据库的语句的执行时间信息。它不包含没有修改任何数据的语句。如果想要记录所有语句，应使用一般查询日志。
二进制日志的主要目的是在恢复时能够最大可能地更新数据库，因为二进制日志包含备份后进行的所有更新。
二进制日志还用于在主复制服务器上记录所有将发送给从服务器的语句。
当用--log-bin=file_name选项启动时，mysqld写入包含所有更新数据的SQL命令的日志文件。如果未给出file_name值，默认名为-bin后面所跟的主机名。如果给出了文件名，但没有包含路径，则文件被写入数据目录。如果在日志名中提供了扩展名（例如，--log-bin=file_name.extension），则扩展名会被忽略。
mysqld在每个二进制日志名后面添加一个数字扩展名。每次启动服务器或刷新日志时该数字则增加。如果当前的日志大小达到max_binlog_size，还会自动创建新的二进制日志。如果正在使用大的事务，二进制日志超过max_binlog_size，事务全写入一个二进制日志中，绝对不要写入不同的二进制日志中。为了能够使当前用户知道还使用哪个不同的二进制日志文件，mysqld还创建一个二进制日志索引文件，包含所有使用的二进制日志文件的文件名。默认情况下与二进制日志文件的文件名相同，扩展名为“.index”。可以用--log-bin-index=file_name选项更改二进制日志索引文件的文件名。当mysqld在运行时，不应手动编辑该文件，因为这样做会使mysqld变得混乱。
可以用RESET MASTER语句删除所有二进制日志文件，或用PURGE MASTER LOGS只删除部分二进制文件。
如果系统正进行二进制文件复制，应确保没有从服务器在使用旧的二进制日志文件，方可删除它们。一种方法是每天一次执行mysqladmin flush -logs并删除三天前的所有日志。可以手动删除，或最好使用PURGE MASTER LOGS，该语句还会安全地更新二进制日志索引文件。
具有SUPER权限的客户端可以通过SET SQL_LOG_BIN=0语句禁止将自己的语句记入二进制记录。可以用mysqlbinlog实用工具检查二进制日志文件。
如果想要重新处理日志的语句，这很有用。例如，可以从二进制日志更新MySQL服务器，方法如下：
shell＞mysqlbinlog log -file | mysql -hserver_name
如果用户正使用事务，必须使用MySQL二进制日志进行备份，而不能使用旧的更新日志。
查询结束后、锁定被释放前或提交完成后的事务，则立即将数据记入二进制日志，这样可以确保按执行顺序记入日志。
对非事务表的更新执行完毕后应立即保存到二进制日志中。对于事务表，例如BDB或InnoDB表，所有更改表的更新（UPDATE、DELETE或INSERT）被存入缓存中，直到服务器接收到COMMIT语句。在该点，当用户执行完COMMIT之前，mysqld将整个事务写入二进制日志。当处理事务的线程启动时，它为缓冲查询分配binlog_cache_size大小的内存。如果语句大于该值，线程则打开临时文件来保存事务。线程结束后临时文件被删除。
Binlog_cache_use状态变量显示使用该缓冲区（也可能是临时文件）保存语句的事务数量。Binlog_cache_disk_use状态变量显示这些事务中实际上有多少必须使用临时文件。这两个变量可以用于将binlog_cache_size调节到足够大的值，以避免使用临时文件。
max_binlog_cache_size（默认4GB）可以用来限制用来缓存多语句事务的缓冲区总大小。如果某个事务大于该值，将会失败并执行回滚操作。
如果你正使用更新日志或二进制日志，当使用CREATE……SELECT or INSERT……SELECT时，并行插入被转换为普通插入。这样通过在备份时使用日志可以确保重新创建表的备份。
默认情况下，并不是每次写入时都将二进制日志与硬盘同步。因此如果操作系统或机器（不仅仅是MySQL服务器）崩溃，有可能二进制日志中最后的语句丢失了。要想防止这种情况，你可以使用sync_binlog全局变量（1是最安全的值，但也是最慢的），使二进制日志在每N次二进制日志写入后与硬盘同步。即使sync_binlog设置为1，出现崩溃时，也有可能表内容和二进制日志内容之间存在不一致性。例如，如果使用InnoDB表，MySQL服务器处理COMMIT语句，它将整个事务写入二进制日志并将事务提交到InnoDB中。如果在两次操作之间出现崩溃，重启时，事务被InnoDB回滚，但仍然存在二进制日志中。可以用--innodb-safe-binlog选项解决该问题，可以增加InnoDB表内容和二进制日志之间的一致性。
ps:在MySQL 5.1中不需要--innodb-safe-binlog；由于引入了XA事务支持，该选项作废了。
该选项可以提供更大程度的安全，还应对MySQL服务器进行配置，使每个事务的二进制日志（sync_binlog=1）和（默认情况为真）InnoDB日志与硬盘同步。该选项的效果是崩溃后重启时，在滚回事务后，MySQL服务器从二进制日志剪切回滚的InnoDB事务。这样可以确保二进制日志反馈InnoDB表的确切数据等，并使从服务器与主服务器保持同步（不接收回滚的语句）。
注意即使MySQL服务器更新其他存储引擎而不是InnoDB，也可以使用--innodb-safebinlog。在InnoDB崩溃恢复时，只从二进制日志中删除影响InnoDB表的语句/事务。如果崩溃恢复时MySQL服务器发现二进制日志变短了（即至少缺少一个成功提交的InnoDB事务），如果sync_binlog=1并且硬盘/文件系统的确能根据需要进行同步（有些不需要）则不会发生，则输出错误消息（“二进制日志＜名＞比期望的要小”）。在这种情况下，二进制日志不准确，复制应从主服务器的数据快照开始。
慢速查询日志（slow-query log）记载着执行用时较长的查询命令，这里所说的“长”是由MySQL服务器变量long_query_time（以秒为单位）定义的。每出现一个慢查询，MySQL服务器就会给它的Slow_queries状态计算器加上一个1。
用--log-slow-queries=file_name选项启动时，mysqld写一个包含所有执行时间超过long_query_time秒的SQL语句的日志文件。
如果没有给出file_name值，默认为主机名，后缀为-slow.log。如果给出了文件名，但不是绝对路径名，文件则写入数据目录。
语句执行完并且所有锁释放后记入慢查询日志。记录顺序可以与执行顺序不相同。
慢查询日志可以用来找到执行时间长的查询，可以用于优化。但是，检查又长又慢的查询日志会很困难。要想容易些，可以使用mysqldump slow命令获得日志中显示的查询摘要来处理慢查询日志。
在MySQL 5.1的慢查询日志中，不使用索引的慢查询同使用索引的查询一样记录。要想防止不使用索引的慢查询记入慢查询日志，使用--log-short-format选项。
在MySQL 5.1中，通过--log-slow-admin-statements服务器选项，可以请求将慢管理语句，例如OPTIMIZE TABLE、ANALYZE TABLE和ALTER TABLE写入慢查询日志。
用查询缓存处理的查询不加到慢查询日志中，因为表有零行或一行而不能从索引中受益的查询也不写入慢查询日志。
MySQL服务器可以创建各种不同的日志文件，从而可以很容易地看见所进行的操作。但是，必须定期清理这些文件，确保日志不会占用太多的硬盘空间。
当启用日志使用MySQL时，你可能想要不时地备份并删除旧的日志文件，并告诉MySQL开始记入新文件。在Linux（Redhat）的安装上，可为此使用mysql-log-rotate脚本。如果从RPM分发安装MySQL，脚本应该自动被安装了。
在其他系统上，必须自己安装短脚本，可从cron等入手处理日志文件。可以通过mysqladmin flush -logs或SQL语句FLUSH LOGS来强制MySQL开始使用新的日志文件。
日志清空执行的操作如下：
如果使用标准日志（--log）或慢查询日志（--log-slow-queries），关闭并重新打开日志文件。（默认为mysql.log和hostname-slow.log）。
如果使用更新日志（--log-update）或二进制日志（--log-bin），关闭日志并且打开有更高序列号的新日志文件。
如果只使用更新日志，只需要重新命名日志文件，然后在备份前清空日志。例如：
shell＞cd mysql-data-directory
shell＞mv mysql.log mysql.old
shell＞mysqladmin flush-logs
然后做备份并删除“mysql.old”。
激活日志功能的弊病之一是随着日志的增加而产生的大量信息，生成的日志文件有可能会填满整个磁盘。如果MySQL服务器非常繁忙且需要处理大量的查询。用户既想保持有足够的空间来记录MySQL服务器的工作情况日志，又想防止日志文件无限制地增长，就需要应用一些日志文件的失效处理技术。进行日志失效处理的方式主要有以下几种：
1.日志轮转
该方法适用于常规查询日志和慢查询日志这些文件名固定的日志文件，在日志轮转时，应进行日志刷新操作（mysqladmin flush -logs命令或flush logs语句），以确保缓存在内存中的日志信息写入磁盘。
日志轮转的操作过程是这样的（假设日志文件的名字是log）：首先，第一次轮转时，把log更名为log.1，然后服务器再创建一个新的log文件，在第二次轮转时，再把log.1更名为log.2，把log更名为log.1，然后服务器再创建一个新的log文件。如此循环，创建一系列的日志文件。当到达日志轮转失效位置时，下次轮转就不再对它进行更名，直接把最后一个日志文件覆盖掉。例如：如果每天进行一次日志轮转并想保留最后7天的日志文件，就需要保留log.1～log.7共七个日志文件，等下次轮转时，用log.6覆盖原来的log.7成新的log.7，原来的log.7就自然失效。
2.以时间为依据对日志进行失效处理
该方法将定期删除超过指定时间的日志文件，适用于变更日志和二进制日志等文件名用数字编号标识的日志文件。
将日志文件镜像到所有的从服务器上，就需要使用镜像机制，用户必须知道主服务器有多少个从服务器，哪些正在运行，并需依次连接每一个从服务器，同时发出show slave status语句以确定它正处理主服务器的哪个二进制日志文件（语句输出列表的Master_Log_File项），只有所有的从服务器都不会用到的日志文件才能删除。例如：本地MySQL服务器是主服务器，它有两个从MySQL服务器S1和S2。在主服务器上有5个二进制日志文件。它们的名字是mrlog0.38～mrlog0.42。
SHOW SLAVE STATUS语句在S1上的执行结果是：
mysql＞SHOW SLAVE STATUS\G
……
Master_Log_File：mrlog.41
……
在S2上的执行结果是：
mysql＞SHOW SLAVE STATUS\G……
Master_Log_File：mrlog.40
……
这样，我们就知道从服务器仍在使用的、最低编号的二进制日志是mrlog.40，而编号比它更小的那些二进制日志，因为不再有从服务器需要用到它们，所以可以安全地删掉。于是，连接到主服务器并发出下面的语句：
mysql＞PURGE MASTER LOGS TO ‘mrlog.040‘；
在主服务器上发出的这条命令将把编号小于40的二进制日志文件删除。
通过镜像机制可把数据从一个地方复制到另一个地方，并能实现两个或多个地方的数据同步过程。MySQL服务器也支持镜像来提高数据的安全性和稳定性。
MySQL数据库系统中的镜像机制遵循以下原则：
一般来说，建议遵循以下原则：
要尽可能地让主服务器和从服务器都使用同一版本系统。
在选定系统后，尽量使用该系统的最新版本。
在两个MySQL服务器间建立主-从镜像关系的具体步骤如下：
（1）确定主从服务器的镜像ID号，主从服务器的ID号不能相同。在启动主从服务器时，用--server_id启动选项给出其ID。
（2）从服务器必须在主服务器上有一个具备足够权限的账户，从服务器将使用该账户去连接主服务器并请求主服务器把二进制变更日志发送给它。
可用以下命令创建这个账户：
GRANT REPLICATION SLAVE ON *.* TO ‘slave_user‘@‘slave_host‘ IDENTIFIED BY ‘slave_pass‘；
ps:REPLICATION权限只MySQL4.0.2后版本，之前的版本请用FILE权限。
（3）把主服务器上的数据库文件复制到从服务器上完成最初同步工作，也可用备份后再加载的方法，还可用在主服务器上运行LOAD DATA FROM MASTER语句来建立从服务器。但有约束条件：数据表要全部是MyISAM表,在连接从服务器时使用的账户必须有SUPER权限,从服务器用来连接主服务器的账户必须具备RELOAD和SUPER权限。ps:这是一个主服务器上的账户，而用来发出LOAD DATA FROM MASTER语句的账户是一个从服务器上的账户。LOAD DATA FROM MASTER语句在执行时需申请一个全局性的读操作锁，这个锁在语句执行期间阻塞主服务器上一切的写操作。
无论用哪一种办法把数据库从主服务器复制到从服务器，在开始制作备份到（如有必要的话）给主服务器重新配置好二进制日志功能的这段时间内，都必须确保主服务器上而没有发生任何修改（写）操作。
（4）关闭服务器。
（5）对主服务器的配置进行修改，把它的镜像ID告诉它并激活其二进制日志功能。在主服务器要读取的选项文件内增加以下内容：
[mysqld]
server-id=master_server_id
log-bin=binlog_name
（6）重新启动主服务器，从现在开始，它将把客户对数据库的修改操作记录到二进制变更日志里。如果在此之前已经激活二进制日志功能，则要在重启前把二进制变更日志备份下来，在重启后再发一条RESET MASTER语句清除现有的二进制变更日志。
（7）关闭从服务器。
（8）对从服务器进行配置，使它知道自己的镜像ID，到哪里去找主服务器以及如何去连接主服务器。配置内容如下：
[mysqld]
server-id=slave_server_id
master-host=master_host
master-user=slave_user#在主服务器上为从服务器建立的账户
msater-password=slave_pass#在主服务器上为从服务器建立的账户的密码
master-connet-retry=30#设置连接重试间隔，默认为60秒
master-retry-count=100000#设置重试次数，默认为86400次
ps:最后两个选项在网络连接不可靠时设置。
（9）重新启动从服务器。从服务器用两个信息源来确定它自己在镜像工作中的进度位置：一个是数据目录中的master.info文件，另一个是启动选项所指定的配置信息。第一次启动从服务器时，master.info文件不存在，从服务器会根据选项文件中给出的各种master-xxx选项值去连接主服务器。一旦连接成功，从服务器会创建一个master.info文件以保存各种连接参数和它自己的镜像工作状态。如果以后再重启从服务器，从服务器会优先读取该文件，而不是选项文件。所以如果修改选项文件的内容，如果用户想使该选项生效，就要删除master.info文件并重启从服务器。
以上步骤是镜像所有数据库的操作过程，如果想把MySQL权限数据保留在主服务器上，排除在镜像机制外的话，可用在选项文件的[mysqld]中加入--binlog-ignore-db=mysql选项，这样，mysql数据库上的操作就不会记录在二进制变更日志里。如要排除其他数据库，只要增加多几个该选项即可。
在建立起镜像关系并使之开始运转之后，还需要对主、从服务器进行监控和管理，这些工作可以用以下语句来完成：
SLAVE STOP, SLAVE START用于挂起来恢复从服务器上镜像，如当备份时，可用该语句让从服务器暂时停止镜像活动。
SHOW SLAVE STATUS，在从服务器上查看其镜像协调信息，这些信息可以用来判断哪些二进制变更日志已经不再使用。
PURGE MASTER，在主服务器上对二进制变更日志进行失效处理。删除所有从服务器都不再使用的二进制变更日志。
CHANGE MASTER，在从服务器上修改镜像参数。如正在读取主服务器上哪个二进制变更日志，正在写哪个中继日志文件等。
镜像机制中的从服务器由两个内部线程组成：
一个叫“I/O线程”，负责与主服务器通信，请求主服务器发送二进制变更日志，并把接收到的数据修改命令写入某个中继日志文件；用SLAVE STOP IO_THREAD或SLAVE START IO_THREAD可挂起或恢复该线程。
一个叫“SQL线程”，负责从中继日志中读取数据修改命令并执行。同理，用SLAVE STOP SQL_THREAD或SLAVE START SQL_THREAD可挂起或恢复该线程。
中继日志文件默认的文件为hostname-relay-bin.nnn和hostname-relay-bin.index。可用从服务器的--relay-log和--relay-log-index选项修改。在从服务器中还有一个relay-log.info中继信息文件，可用--relay-log-info-file启动选项修改文件名。
双机热备份是指通过日志文件来传输服务器上数据的变化。主服务器进程在数据被更新时触发，并将相应的日志文件发送到从服务器。从服务器进程接收到主服务器发送的日志文件后，阅读日志文件并对响应的数据库进行操作。
1.主服务器的配置
主服务器的IP设置为192.168.1.59。配置主服务器的步骤如下：
（1）找到MySQL数据库的配置文件my.ini。
（2）通过编辑器打开my.ini文件，定位到[mysqld]一节，加入如下内容：
server-id=1
log-bin=c：/log-bin.log
binlog-do-db=dbname
其中，server-id指定服务器编号；log-bin为日志的存储位置及文件名；binlog-do-db为进行日志记录的数据库名称，如果存在多个数据库，则用逗号“，”分隔。
本实例中指定服务器编号为1，日志的存储位置和名称是C盘根目录下log-bin.log，指定对db_database16数据库进行日志记录操作。
（3）创建db_database16数据库。
（4）进入MySQL的命令操作界面，通过命令为从服务器授权访问数据库的用户名和密码。命令如下：
grant replication slave on *.* to ‘root‘@‘192.168.1.227‘ identified by ‘root‘；
其中，指定用户名是root，从服务器的IP是192.168.1.227，密码是root。
（5）重启MySQL服务器，使更改生效。
（6）重新进入到MySQL的命令操作界面，执行如下命令检测配置是否生效。
show master status\G
2.从服务器的配置
（1）首先在从服务器中创建与主服务器中相同的数据库。
（2）找到从服务器中的my.ini文件，定位到[mysqld]一节，在该节中加入如下内容：
server-id=2
master-host=192.168.1.59
master-port=3306
master-user=root
master-password=root
master-connect-retry=60
其中，server-id指定从服务器的编号，该编号必须与主服务器不同；master-host指定主服务器的IP地址；master-port指定访问主服务器所用端口号；master-user和master-password指定访问主服务器的用户名和密码；master-connect-retry表示如果因为网络问题与主服务器断开连接，等待多少秒尝试重新连接。
（3）重新启动MySQl服务器，使配置生效。
（4）进入到从服务器的MySQL命令操作界面，执行如下命令启动进程。
slave start；
到此，MySQL数据库双机热备份的配置完成。
可以对MySQL服务器在以下几种网络接口上的连接监听情况进行控制：
（1）任何一种平台上的MySQL服务器都监听着供TCP/IP连接使用的网络接口，如用--skip-networking选项启动服务器，则不监听TCP/IP端口。MySQL服务器使用的默认端口号是3306；可用—port选项另行指定一个不同的端口号。如服务器主机有多个IP地址，还可用--bind-address选项对服务器在监听客户连接时使用的IP地址进行设定。
（2）在UNIX系统上，MySQL服务器还将在一个UNIX域套接字文件上监听有无本地客户在试图以localhost为主机名进行连接。默认的套接字文件是/tmp/mysql.sock，可用--socket选项指定另外一个套接字文件。
（3）在基于NT的Windows平台上，名字里有-nt字样的MySQL服务器都支持命名管道。默认的命名管道名是MySQL；可用--socket选项另行指定一个不同的命名管道名。
（1）在MySQL服务器的编译阶段，可以在运行configure脚本时用--enable-local-infile或--disable-local-infile选项把LOAD DATA语句的LOCAL能力设置为启用或禁用。
（2）在MySQL服务器的启动阶段，可以用--local-infile或--disable-local-infile选项来启用或禁用服务器的LOCAL能力（在MySQL 4.0.2之前的版本里，要用--local-infile=0来禁用它）。
如果在服务器端禁用了LOCAL的能力，则客户端就不能使用该功能；如服务器启用了LOCAL的能力，客户端默认也是禁止使用的，但可用mysql程序的--local-infile选项启用它。
国际化是指软件能够在世界多个国家地区使用，而本地化则是指可从国际化软件中选择一套适合本地区的语言和习惯的设置来使用。在MySQL中的国际化和本地化设置有以下几方面内容：
1.设置MySQL服务器的地理时区
如果时区设置不对，则服务器显示的时间将会和当地时间有冲突。这就需要管理员对时区进行设置。设置方法可通过mysqld_safe脚本的--timezone选项来设置，建议把这个选项放到某个选项文件里，尤其是在MySQL服务器是通过不支持命令行选项的mysql.server脚本调用safe_mysql或mysqld_safe脚本来启动的时候。例如：可以把用来设定美国中部时间的指令添加到选项文件的[mysqld_safe]选项组里：
[mysqld_safe]
timezone=US/Central
上例中的语法适用于Solaris、Linux或Mac OS X在内的绝大多数UINX系统。另一种常见的语法是：
[mysqld_safe]
timezone=CST6CDT
MySQL能用多种语言来显示诊断信息与出错信息，默认是英语，但可以另行设置其他语言。如果想知道都有哪几种语言可供选用，可以查看MySQL安装路径下的share/mysql目录里有几个以语言名称作为名字的下级目录。如果想改用另一种语言，请用—language启动选项给出该种语言的名称或路径名。以法语为例，如果把MySQL安装在了目录/usr/local/mysql下，就要用—language=french或—language=/usr/local/mysql/share/mysql/french来改变出错信息的显示语言。
MySQL支持多种字符集，可在share/mysql/charsets目录下查询支持的字符集，也可用show variables like ‘character_sets‘来显示支持的字符集清单。用SHOW CHARACTER SET语句也能查出这份清单和一些相关信息。
如果想从可用的字符集中挑出一个作为MySQL服务器的默认字符集，就要在MySQL服务器的编译阶段通过configure脚本的下列选项来进行配置：
MySQL服务器的默认字符集是latin1，但可以用--with-charset选项另行指定一个。
如果想给MySQL服务器增加对其他字符集的支持，就要使用--with-extra-charsets选项。这个选项的参数是一个以逗号分隔符的字符集清单。例如，如果想让MySQL服务器支持latin1、big5和hebrew字符集，就要像如下所示的方法去配置MySQL软件的源代码发行版本：
./configure--with-extra-charsets=latin1，big5，hebrew
--with-extra-charsets有两个特殊的参数值，一个是all，代表所有可用字符集；一个是complex，代表所有的复杂字符集（包括多字节字符集和有特殊排序规则的字符集）。
服务器启动时，使用默认字符集，如需指定另外的字符集，需用--default-character-set选项指明。对于MyISAM数据表，既可以同时使用myisamchk程序的—recover和—quick选项，再加上负责指定新字符集的—set-character选项，来重新对索引进行排序，这里请注意，在执行myisamchk程序之前先要停止MySQL服务器。
也可以在不停止MySQL服务器的前提下用REPAIR TABLE……QUICK语句或mysqlcheck—repair—quick命令来重新对索引进行排序。第三种方法是按“转储-丢弃-重新加载”的顺序对各有关数据表进行处理，这个办法适用于包括MyISAM数据表在内的各种数据表。在客户端，可用--default-character-set选项指定客户程序使用的字符集。如果没有把新字符集安装到它们的默认位置（MySQL安装路径下的share/mysql/charsets目录），而是把所需的字符集文件安装到了另一个目录下，还可以用—character-sets-dir选项把这个地点告知客户程序。
MySQL服务器变量分为全局级和会话级两个级别。全局级变量将影响整个服务器，会话级变量则只影响某指定客户连接上的工作。如果某个变量同时存在于两个级别，则服务器在客户建立连接时用全局变量的值去初始化相应的会话级变量，一旦客户连接建立起来后，对全局变量所做的修改不会影响到相应的会话级参数当前值。
指定一个全局级变量var_name，下面两种SET语句格式，如下所示：
SET GLOBAL var_name=value；
SET @@GLOBAL.var_name=value；
类似地，针对会话级变量的SET语句也有两种格式，如下所示；
SET SESSION var_name=value；
SET @@SESSION.var_name=value；
不带级别限定符的SET语句修改的是会话级变量，如下所示；
SET var_name=value；
SET @@var_name=value；
可用一条SET语句设置多个变量，变量间用逗号分隔，如：
SET SESSION sql_warnings=0，GLOBAL table_type=InnoDB；
SESSION和LOCAL是同义语，可用LOCAL代替SESSION，如：@@LOCAL来替换@@SESSION。
具备SUPER权限才能设置全局变量，新设置值的效力将持续到该变量被再次修改或服务器退出。设置会话级变量不用特殊的权限，新设置值的效力将持续到该值被再次修改或连接断开。显示参数的语句如下：
SHOW GLOBAL VARIABLES；
SHOW GLOBAL VARIABLES LIKE‘TEST‘；
SHOW SESSION VARIABLES；
SHOW SESSION VARIABLES LIKE‘TEST‘；
如果不带GLOBAL或SESSION关键字，这条语句将返回会话级变量的值，如果会话级变量不存在，则返回全局级变量的值。
一些变量对一般的性能调整是最有用的，如下所述：
back_log，当多个客户同时连接服务器时，客户处理过程需进入一个队列排队等待服务器处理。该值定义服务器等待处理队列长度的最大值，如果站点访问量大，需加大该值。
delayed_queue_size，在实际插入数据表前，来自insert delayed语句的数据行会进入一个队列等待服务器处理。该值定义该队列能容纳的数据行的最大个数。当队列满时，会阻塞后续的语句。加大该值能提高insert delayed语句的执行速度。
flush_time，自动存盘间隔。如果系统经常死机或重启，把这个变量设置为一个适当的非零值，使MySQL服务器每隔flush_time去刷新一次数据表缓冲区，将其中的信息写入磁盘。这将导致系统性能下降，但可减少数据表被破坏或丢失数据的概率。在命令行上用--flush选项启动服务器可使数据表在每次修改后被自动存盘。
key_buffer_size，用来容纳索引块的缓冲区的长度。加大该值可加快索引创建和修改操作的速度，该索引缓冲区越大，在内存中找到键值的可能性就越大，读盘次数就越少。
max_allowed_packet，服务器与客户程序之间通信时使用的缓冲区在最大值。MySQL 4.0版本之前，该值最大可取16MB, MySQL 4.0版本以后，该值的最大值是1GB。如果客户端与服务器需传送大容量的数据，如BLOB或TEXT值，就要加大该值。客户端也有一个同名的变量，默认是16MB，该值也要加大。客户端的启动命令为：
mysql--set-variable=max_allowed_packet=64M
max_connections，允许同时打开的连接数，如果站点繁忙，需加大该值。
table_cache，数据表缓存区的尺寸。加大该值可使服务器能够同时打开更多的数据表，从而减少文件打开/关闭操作的次数。
如果加大了max_connections和table_cache变量的值，MySQL服务器就会占用更多的文件描述符，如果操作系统对每个进程所能占用的文件描述符的个数有限制，这样做就会引起一些问题。如果真的是遇到这种问题，就需要加大操作系统对每个进程所能占用的文件描述符的个数限制或者是另想办法绕过这一限制。
除通用的MySQL服务器变量外，如果激活了InnoDB支持，MySQL服务器就会有一些与InnoDB有关的变量。通过以下几个MySQL服务器变量来控制InnoDB处理程序的工作情况：
innodb_buffer_pool_size，如果有足够的内存，可把该值设置得大些以减少读盘操作。
innodb_log_buffer_size加大这个缓冲区的尺寸将是更多的语句在你提交某个事物之前被缓存在内存里，从而减少了事物执行期间的磁盘读写次数。
innodb_log_file_size和innodb_log_files_in_group，前者设置日志文件的长度，后者设置日志文件的个数。InnoDB日志文件的总长度是两者的乘积，它的总长度不得超过4GB。
标签：replica 信息 std 手动 条件 适合 win cat 错误日志
原文地址：http://www.cnblogs.com/wade-luffy/p/6048475.html
