Jiliuke

激流客

匿名访问 1. yum -y install samba samba-common 2. cd /etc/samba vim smb.conf # 1). 先设定好服务器整体环境方面的参数 [global] # 与主机名有关的设定信息 workgroup = vbirdhouse netbios name = vbirdserver server string = This is vbird’s samba server # 与语系方面有关的设定项目喔,为何如此设定请参考前面的说明 unix charset = utf8 display charset = utf8 dos charset = cp950 # 与登录文件有关的设定项目,注意变量 (%m) log file = /var/log/samba/log.%m max log size = 50 # 这里才是与密码有关的设定项目哩! security = share # 修改一下打印机的加载方式,不要加载啦! load printers = no # 2). 分享的资源设定方面:主要得将旧的批注,新的加入! # 先取消 [homes], [printers] 的项目,然后针对 /tmp 的设定,可浏览且可写入喔 [temp] <==分享资源名称 comment = Temporary file space <==简单的解释此资源 path = /tmp <==实际 Linux 分享的目录 writable = yes <==是否可写入?在此例为是的 browseable = yes <==能不能被浏览到资源名称 guest ok = yes <==单纯分享时,让用户随意登入的设定值 3. service smb start service smb start

在使用Samba进行建立Window与Linux共享时,要是不能访问,出现“您可能没有权限使用网络资源”, 那就是SELinux在作怪了 要是想让共享目录能访问,可以使用命令 #setenforce 0 暂时停掉SELinux 使用 #setenforce 1 启用SELinux 有关SELinux 在系统中的作用就不讲了,另外一种方法可以不用关闭SELinux.以下命令将允许这个权限: setsebool -P samba_enable_home_dirs=1 若SElinux啟用中,在Windows檔案總管無法連到 Samba 所分享出來的目錄時, 在Linux 中,可執行下列指令: setsebool -P samba_enable_home_dirs on 參考文件: /etc/samba/smb.conf #————— # SELINUX NOTES: # 分享群組 # If you want to use the useradd/groupadd family of binaries please run: # setsebool -P samba_domain_controller on # # 分享home目錄 # If you want to share home directories via samba please run: # setsebool -P samba_enable_home_dirs on # # If you create a new directory you want to share you should mark it as # “samba-share_t” so that selinux will let you write into it. # Make sure not to do that on system directories as they may already have # been marked with othe SELinux labels. # # Use ls -ldZ /path to see which context a directory has # # Set labels only on directories you created! # To set a label use the following: chcon -t samba_share_t /path # # If you need to share a system created directory you can use one of the # following (read-only/read-write): # setsebool -P samba_export_all_ro on # or # setsebool -P samba_export_all_rw on # # If you want to run scripts (preexec/root prexec/print command/…) please # put them into the /var/lib/samba/scripts directory so that smbd will be # allowed to run them. # Make sure you COPY them and not MOVE them so that the right SELinux context # is applied, to check all is ok use restorecon -R -v /var/lib/samba/scripts # #————– #

接着就是修改etc/vsftpd/vsftpd.conf里面的参数了。 anonymous_enable=YES/NO是否允许匿名访问 1、限制所有的本地用户在自家目录 chroot_local_user=YES 限制部分本地用户在自家目录 chroot_local_user=NO chroot_list_enable=YES chroot_list_file=/etc/vsftpd.chroot_list 在/etc/vsftpd.chroot_list文件中加入要限制的本地用户名。注意一个用户名一行。 有时候要限制某些IP访问服务器,只允许某些IP访问,例如只允许192.168.0.33访问这个FTP,同样修改配置文件: listen_address=192.168.0.33 端口修改:/etc/services,修改,比如改FTP21端口改2121,只要在这里修改,然后在vsftpd.conf配置文件里加一条 listet_port=2121 最主要的是防火墙里的SELinux要允许,不然是不能读取写入的 还有一种就是pasv被动传输模式,可以如下设置 pasv_enable=yes (Default: YES ) 设置是否允许pasv模式 pasv_promiscuous=no (Default: NO ) 是否屏蔽对pasv进行安全检查,(当有安全隧道时可禁用) pasv_min_port=1024(Default: 0 (use any port) ) pasv使用的最大端口 pasv_max_port=10240 (Default: 0 (use any port) ) pasv使用的最小端口 然后在添加防火墙的时候可以加一条 iptables -A INPUT -p tcp –dport 1024:10240 -j ACCEPT(表示1024-10240这些端口通过) iptables -A OUTPUT -p tcp –spotr 1024:10240 -j ACCEPT 最后,如何让vsftpd自动启动 在/etc/rc.local 文件里面添加一句 vsftpd & 这样就可以开机就自动启动了!

一.权限导致vsftpd不能正常访问 安装vsftpd软件后,ftp默认的家目录为/var/ftp, 就是这个/var/ftp的权限设置错误导致的,这个目录的权限是不能打开所有权限的;是您运行了chmod 777 /var/ftp所致。 如下FTP用户的家目录是不能针对所有用户、用户组、其它用户组完全开放; [root@localhost ~]# ls -ld /var/ftp drwxrwxrwx 3 root root 4096 2009-03-23 /var/ftp 修正这个错误,应该用下面的办法; [root@localhost ~]# chown root:root /var/ftp [root@localhost ~]# chmod 755 /var/ftp 二.开启LINUX服务器防火墙后,不能正常登录。 常规设置在防火墙配置文件中添加21端口,还是不能正常访问到FTP服务器。 首先要了解概念; FTP支持两种模式,一种方式叫做Standard (也就是 PORT方式,主动方式),一种是 Passive (也就是PASV,被动方式)。 Standard模式 FTP的客户端发送 PORT 命令到FTP服务器。Passive模式FTP的客户端发送 PASV命令到 FTP Server。 PORT 和 PASV的简单区别如下: Port模式FTP 客户端首先和FTP服务器的TCP 21端口建立连接,通过这个通道发送命令,客户端需要接收数据的时候在这个通道上发送PORT命令。 PORT命令包含了客户端用什么端口接收数据。在传送数据的时候,服务器端通过自己的TCP 20端口连接至客户端的指定端口发送数据。 FTP server必须和客户端建立一个新的连接用来传送数据。 Passive模式在建立控制通道的时候和Standard模式类似,但建立连接后发送的不是Port命令,而是Pasv命令。FTP服务器收到 Pasv命令后,随机打开一个高端端口(端口号大于1024)并且通知客户端在这个端口上传送数据的请求,客户端连接FTP服务器此端口,然后FTP服务器将通过这个端口进行数据的传送,这个时候FTP server不再需要建立一个新的和客户端之间的连接。 因为IE浏览器默认使用的是Passive(被动)模式,所以要连接Linux服务器大于1024端口,而防火墙并没有开发1024以上的端口,导致登录ftp服务器被防火墙阻止。 解决方法:1.客户端设置 去掉 前面的复选框,让IE浏览器使用port(主动)模式,但是要对每个客户端进行设置比较麻烦。 2.服务器端设置(以CentOS为例) 修改vsftpd.conf配置文件让它支持Passive(被动)模式 #vim /etc/vsftpd/vsftpd.conf 在最后一行添加如下内容: pasv_min_port=3000 (设置被动模式的端口范围) pasv_max_port=3010 (设置被动模式的端口范围) 在防火墙配置文件iptables中添加端口 #vim /etc/sysconfig/iptables -A RH-Firewall-1-INPUT -m state –state NEW -m tcp -p tcp –dport 3000:3010 -j ACCEPT 重启服务使其生效 #service vsftpd rstart #service iptables restart

Mysql数据库表的自增主键ID号乱了,需要重新排列。 原理:删除原有的自增ID,重新建立新的自增ID。 1,删除原有主键: ALTER TABLE `table_name` DROP `id`; 2,添加新主键字段: ALTER TABLE `table_name` ADD `id` MEDIUMINT( 8 ) NOT NULL FIRST; 3,设置新主键: ALTER TABLE `table_name` MODIFY COLUMN `id` MEDIUMINT( 8 ) NOT NULL AUTO_INCREMENT,ADD PRIMARY KEY(id);

1、如果遇到mysqld无法启动,提示MySQL Daemon failed to start. 首先使用 #/usr/local/mysql/bin/mysqld_safe & 启动mysqld_safe,再启动mysqld服务试试 2、如果一部机器中有多个数据库,先查看数据库目录,然后再停止 mysql:show variables “%datadir%” cmd:mysqladmin -u root shutdown 3、当遇到mysql locked, 方法1可以使用kill 进程号, 方法2可以使用 mysql> select * from information_schema.processlist order by time ; 查看占用时间多的sql语句进行优化操作。 方法3可以更换存储引擎试试

mysql服务器的主从配置,本来是一件很简单的事情,无奈不是从零开始,总是在别人已经安装好的mysql服务器之上 ,这就会牵扯到,mysql的版本,启动文件,等一些问题。 不过没关系,先问清楚两点 1、mysql配置文件my.cnf的位置 2、如何启动、停止mysql,找好启动文件 假设有两台机器,已经安装好了mysql(尽量同版本,且两台机器同一网络,可以ping通) 有朋友说:“从服务器,不能低于主服务器的版本”,不过我是低于的,没有出现问题。 主机A: 192.168.1.100 从机B:192.168.1.101 可以有多台从机 1、先登录主机 A mysql>GRANT REPLICATION SLAVE ON . TO ‘backup’@’192.168.1.101‘ IDENTIFIED BY ‘123456’; 赋予从机权限,有多台丛机,就执行多次 2、 打开主机A的my.cnf,输入 server-id = 1 #主机标示,整数 log_bin = /var/log/mysql/mysql-bin.log #确保此文件可写 read-only =0 #主机,读写都可以 binlog-do-db =test #需要备份数据,多个写多行 binlog-ignore-db=mysql #不需要备份的数据库,多个写多行 3、打开从机B的my.cnf,输入 server-id = 2 log_bin = /var/log/mysql/mysql-bin.log master-host =192.168.1.100 master-user =backup master-pass =123456 master-port =3306 master-connect-retry=60 #如果从服务器发现主服务器断掉,重新连接的时间差(秒) replicate-do-db =test #只复制某个库 replicate-ignore-db=mysql #不复制某个库 4、同步数据库 有多种方法,我说最笨的一种,先mysqldump导出主机A的数据test为 test.sql 然后在,从机B上建立数据库test,mysql导入 test.sql到test库中 5、先重启主机A的mysql,再重启从机B的mysql 6、验证 在主机A中,mysql>show master statusG; 在从机B中,mysql>show slave statusG; 能看到大致这些内容 File: mysql-bin.000001 Position: 1374 Binlog_Do_DB: test Binlog_Ignore_DB: mysql 可以在主机A中,做一些INSERT, UPDATE, DELETE 操作,看看主机B中,是否已经被修改 以下是一些其他朋友写的,我也做了参考 http://www.ningoo.net/html/2007/mysql\_replication\_configuration.html http://leftleg.hzpub.com/post/645/ http://blog.zhangjianfeng.com/article/705

MySQL Cluster 是 MySQL 适合于分布式计算环境的高实用、高冗余版本。它采用了NDB Cluster 存储引擎,允许在1个 Cluster 中运行多个MySQL服务器。MySQL Cluster 能够使用多种故障切换和负载平衡选项配置NDB存储引擎,但在 Cluster 级别上的存储引擎上做这个最简单。下面我们简单介绍MySQL Cluster如何安装与配置。 基本设定 管理(MGM)节点:192.168.0.111 MySQL服务器(SQL)节点:192.168.0.110 数据(NDBD)节点”A”:192.168.0.112 数据(NDBD)节点”B”:192.168.0.113 一、mysql集群安装 mysql的集群安装可以有三种方式,一是直接下载二进制使用,二是使用rpm安装,三是源码编译。我们这里使用第一种安装。 1、每个节点做相同的操作 cd /tmp wget http://cdn.mysql.com/Downloads/MySQL-Cluster-7.2/mysql-cluster-gpl-7.2.8-linux2.6-i686.tar.gz tar xzf mysql-cluster-gpl-7.2.8-linux2.6-i686.tar.gz mv mysql-cluster-gpl-7.2.8-linux2.6-i686 /usr/local/mysql 注意:这里下载的是32位的二进制包,如果你的系统是64位,需要下载64位的包。 2、存储节点和SQL节点安装 groupadd mysql useradd -g mysql mysql /usr/local/mysql/scripts/mysql_install_db –basedir=/usr/local/mysql –datadir=/usr/local/mysql/data –user=mysql chown -R root /usr/local/mysql chown -R mysql /usr/local/mysql/data chgrp -R mysql /usr/local/mysql cp /usr/local/mysql/support-files/my-medium.cnf /etc/my.cnf 二、节点配置 1、配置存储节点和SQL节点 vi /etc/my.cnf 类似于: # Options for mysqld process: [MYSQLD] ndbcluster # run NDB engine ndb-connectstring=198.168.0.111 # location of MGM node # Options for ndbd process: [MYSQL_CLUSTER] ndb-connectstring=198.168.0.111 # location of MGM node 2、配置管理节点 mkdir /var/lib/mysql-cluster cd /var/lib/mysql-cluster vi config.ini config.ini文件应类似于: # Options affecting ndbd processes on all data nodes: [NDBD DEFAULT] NoOfReplicas=2 # Number of replicas DataMemory=80M # How much memory to allocate for data storage IndexMemory=18M # How much memory to allocate for index storage # For DataMemory and IndexMemory, we have used the # default values. Since the “world” database takes up # only about 500KB, this should be more than enough for # this example Cluster setup. # TCP/IP options: [TCP DEFAULT] portnumber=2202 # This the default; however, you can use any # port that is free for all the hosts in cluster # Note: It is recommended beginning with MySQL 5.0 that # you do not specify the portnumber at all and simply allow # the default value to be used instead # Management process options: [NDB_MGMD] hostname=198.168.0.111 # Hostname or IP address of MGM node datadir=/var/lib/mysql-cluster # Directory for MGM node logfiles # Options for data node “A”: [NDBD] # (one [NDBD] section per data node) hostname=198.168.0.112 # Hostname or IP address datadir=/usr/local/mysql/data # Directory for this data node’s datafiles # Options for data node “B”: [NDBD] hostname=198.168.0.113 # Hostname or IP address datadir=/usr/local/mysql/data # Directory for this data node’s datafiles # SQL node options: [MYSQLD] hostname=198.168.0.110 # Hostname or IP address # (additional mysqld connections can be # specified for this node for various # purposes such as running ndb_restore) 三、首次启动节点 1、启动管理节点 /usr/local/mysql/bin/ndb_mgmd –configdir=/var/lib/mysql-cluster -f /var/lib/mysql-cluster/config.ini 2、启动数据节点 首次启动需要–initial参数初始化,下一次启动就不需要了。 /usr/local/mysql/bin/ndbd –initial 3、启动SQL节点 /usr/local/mysql/bin/mysqld_safe & 4、检查状态 如果一切正常,执行命令 /usr/local/mysql/bin/ndb_mgm -e show应该会输出类似信息: [root@localhost mysql-cluster]# /usr/local/mysql/bin/ndb_mgm -e show Connected to Management Server at: localhost:1186 Cluster Configuration ——————— [ndbd(NDB)] 2 node(s) id=2 @192.168.0.112 (mysql-5.5.27 ndb-7.2.8, Nodegroup: 0, Master) id=3 @192.168.0.113 (mysql-5.5.27 ndb-7.2.8, Nodegroup: 0) [ndb_mgmd(MGM)] 1 node(s) id=1 @192.168.0.111 (mysql-5.5.27 ndb-7.2.8) [mysqld(API)] 1 node(s) id=4 @192.168.0.110 (mysql-5.5.27 ndb-7.2.8) 四、测试服务是否正常 在SQL节点上执行如下数据库操作: /usr/local/mysql/bin/mysql -uroot -p mysql> create database clusterdb;use clusterdb; mysql> create table simples (id int not null primary key) engine=ndb; mysql> insert into simples values (1),(2),(3),(4); mysql> select * from simples; 如果出现: +—-+ | id | +—-+ | 1 | | 2 | | 4 | | 3 | +—-+ 则表示工作正常。 五、安全关闭和重启 1、关闭mysql集群,可在管理节点在执行如下命令: /usr/local/mysql/bin/ndb_mgm -e shutdown 2、重启管理节点 /usr/local/mysql/bin/ndb_mgmd –configdir=/var/lib/mysql-cluster -f /var/lib/mysql-cluster/config.ini 3、重启数据节点 /usr/local/mysql/bin/ndbd 参考:http://dev.mysql.com/doc/refman/5.1/zh/ndbcluster.html

前言 在安装完MySQL之后,肯定是需要对MySQL的各种参数选项进行一些优化调整的。虽然MySQL系统的伸缩性很强,既可以在有很充足的硬件资源环境下高效的运行,也可以在极少资源环境下很好的运行,但不管怎样,尽可能充足的硬件资源对MySQL的性能提升总是有帮助的。在这一节我们主要分析一下MySQL的日志(主要是Binlog)对系统性能的影响,并根据日志的相关特性得出相应的优化思路。 日志产生的性能影响 由于日志的记录带来的直接性能损耗就是数据库系统中最为昂贵的IO资源。 在之前介绍MySQL物理架构的章节中,我们已经了解到了MySQL的日志包括错误日志(ErrorLog),更新日志(UpdateLog),二进制日志(Binlog),查询日志(QueryLog),慢查询日志(SlowQueryLog)等。当然,更新日志是老版本的MySQL才有的,目前已经被二进制日志替代。 在默认情况下,系统仅仅打开错误日志,关闭了其他所有日志,以达到尽可能减少IO损耗提高系统性能的目的。但是在一般稍微重要一点的实际应用场景中,都至少需要打开二进制日志,因为这是MySQL很多存储引擎进行增量备份的基础,也是MySQL实现复制的基本条件。有时候为了进一步的性能优化,定位执行较慢的SQL语句,很多系统也会打开慢查询日志来记录执行时间超过特定数值(由我们自行设置)的SQL语句。 一般情况下,在生产系统中很少有系统会打开查询日志。因为查询日志打开之后会将MySQL中执行的每一条Query都记录到日志中,会该系统带来比较大的IO负担,而带来的实际效益却并不是非常大。一般只有在开发测试环境中,为了定位某些功能具体使用了哪些SQL语句的时候,才会在短时间段内打开该日志来做相应的分析。所以,在MySQL系统中,会对性能产生影响的MySQL日志(不包括各存储引擎自己的日志)主要就是Binlog了。 Binlog 相关参数及优化策略 我们首先看看Binlog的相关参数,通过执行如下命令可以获得关于Binlog的相关参数。当然,其中也显示出了“innodb_locks_unsafe_for_binlog”这个Innodb存储引擎特有的与Binlog相关的参数: mysql> show variables like ‘%binlog%’; +——————————–+————+ | Variable_name | Value | +——————————–+————+ | binlog_cache_size | 1048576 | | innodb_locks_unsafe_for_binlog | OFF | | max_binlog_cache_size| 4294967295 | | max_binlog_size| 1073741824 | | sync_binlog| 0| +——————————–+————+ “binlog_cache_size”:在事务过程中容纳二进制日志SQL语句的缓存大小。二进制日志缓存是服务器支持事务存储引擎并且服务器启用了二进制日志(—log-bin选项)的前提下为每个客户端分配的内存,注意,是每个Client都可以分配设置大小的binlogcache空间。如果读者朋友的系统中经常会出现多语句事务的华,可以尝试增加该值的大小,以获得更有的性能。当然,我们可以通过MySQL的以下两个状态变量来判断当前的binlog_cache_size的状况:Binlog_cache_use和Binlog_cache_disk_use。 “max_binlog_cache_size”:和”binlog_cache_size”相对应,但是所代表的是binlog能够使用的最大cache内存大小。当我们执行多语句事务的时候,max_binlog_cache_size如果不够大的话,系统可能会报出“Multi-statementtransactionrequiredmorethan’max_binlog_cache_size’bytesofstorage”的错误。 “max_binlog_size”:Binlog日志最大值,一般来说设置为512M或者1G,但不能超过1G。该大小并不能非常严格控制Binlog大小,尤其是当到达Binlog比较靠近尾部而又遇到一个较大事务的时候,系统为了保证事务的完整性,不可能做切换日志的动作,只能将该事务的所有SQL都记录进入当前日志,直到该事务结束。这一点和Oracle的Redo日志有点不一样,因为Oracle的Redo日志所记录的是数据文件的物理位置的变化,而且里面同时记录了Redo和Undo相关的信息,所以同一个事务是否在一个日志中对Oracle来说并不关键。而MySQL在Binlog中所记录的是数据库逻辑变化信息,MySQL称之为Event,实际上就是带来数据库变化的DML之类的Query语句。 “sync_binlog”:这个参数是对于MySQL系统来说是至关重要的,他不仅影响到Binlog对MySQL所带来的性能损耗,而且还影响到MySQL中数据的完整性。对于“sync_binlog”参数的各种设置的说明如下: sync_binlog=0,当事务提交之后,MySQL不做fsync之类的磁盘同步指令刷新binlog_cache中的信息到磁盘,而让Filesystem自行决定什么时候来做同步,或者cache满了之后才同步到磁盘。 sync_binlog=n,当每进行n次事务提交之后,MySQL将进行一次fsync之类的磁盘同步指令来将binlog_cache中的数据强制写入磁盘。 在MySQL中系统默认的设置是sync_binlog=0,也就是不做任何强制性的磁盘刷新指令,这时候的性能是最好的,但是风险也是最大的。因为一旦系统Crash,在binlog_cache中的所有binlog信息都会被丢失。而当设置为“1”的时候,是最安全但是性能损耗最大的设置。因为当设置为1的时候,即使系统Crash,也最多丢失binlog_cache中未完成的一个事务,对实际数据没有任何实质性影响。从以往经验和相关测试来看,对于高并发事务的系统来说,“sync_binlog”设置为0和设置为1的系统写入性能差距可能高达5倍甚至更多。 大家都知道,MySQL的复制(Replication),实际上就是通过将Master端的Binlog通过利用IO线程通过网络复制到Slave端,然后再通过SQL线程解析Binlog中的日志再应用到数据库中来实现的。所以,Binlog量的大小对IO线程以及Msater和Slave端之间的网络都会产生直接的影响。 MySQL中Binlog的产生量是没办法改变的,只要我们的Query改变了数据库中的数据,那么就必须将该Query所对应的Event记录到Binlog中。那我们是不是就没有办法优化复制了呢?当然不是,在MySQL复制环境中,实际上是是有8个参数可以让我们控制需要复制或者需要忽略而不进行复制的DB或者Table的,分别为: Binlog_Do_DB:设定哪些数据库(Schema)需要记录Binlog; Binlog_Ignore_DB:设定哪些数据库(Schema)不要记录Binlog; Replicate_Do_DB:设定需要复制的数据库(Schema),多个DB用逗号(“,”)分隔; Replicate_Ignore_DB:设定可以忽略的数据库(Schema); Replicate_Do_Table:设定需要复制的Table; Replicate_Ignore_Table:设定可以忽略的Table; Replicate_Wild_Do_Table:功能同Replicate_Do_Table,但可以带通配符来进行设置; Replicate_Wild_Ignore_Table:功能同Replicate_Ignore_Table,可带通配符设置; 通过上面这八个参数,我们就可以非常方便按照实际需求,控制从Master端到Slave端的Binlog量尽可能的少,从而减小Master端到Slave端的网络流量,减少IO线程的IO量,还能减少SQL线程的解析与应用SQL的数量,最终达到改善Slave上的数据延时问题。 实际上,上面这八个参数中的前面两个是设置在Master端的,而后面六个参数则是设置在Slave端的。虽然前面两个参数和后面六个参数在功能上并没有非常直接的关系,但是对于优化MySQL的Replication来说都可以启到相似的功能。当然也有一定的区别,其主要区别如下: 如果在Master端设置前面两个参数,不仅仅会让Master端的Binlog记录所带来的IO量减少,还会让Master端的IO线程就可以减少Binlog的读取量,传递给Slave端的IO线程的Binlog量自然就会较少。这样做的好处是可以减少网络IO,减少Slave端IO线程的IO量,减少Slave端的SQL线程的工作量,从而最大幅度的优化复制性能。当然,在Master端设置也存在一定的弊端,因为MySQL的判断是否需要复制某个Event不是根据产生该Event的Query所更改的数据 所在的DB,而是根据执行Query时刻所在的默认Schema,也就是我们登录时候指定的DB或者运行“USEDATABASE”中所指定的DB。只有当前默认DB和配置中所设定的DB完全吻合的时候IO线程才会将该Event读取给Slave的IO线程。所以如果在系统中出现在默认DB和设定需要复制的DB不一样的情况下改变了需要复制的DB中某个Table的数据的时候,该Event是不会被复制到Slave中去的,这样就会造成Slave端的数据和Master的数据不一致的情况出现。同样,如果在默认Schema下更改了不需要复制的Schema中的数据,则会被复制到Slave端,当Slave端并没有该Schema的时候,则会造成复制出错而停止。 而如果是在Slave端设置后面的六个参数,在性能优化方面可能比在Master端要稍微逊色一点,因为不管是需要还是不需要复制的Event都被会被IO线程读取到Slave端,这样不仅仅增加了网络IO量,也给Slave端的IO线程增加了RelayLog的写入量。但是仍然可以减少Slave的SQL线程在Slave端的日志应用量。虽然性能方面稍有逊色,但是在Slave端设置复制过滤机制,可以保证不会出现因为默认Schema的问题而造成Slave和Master数据不一致或者复制出错的问题。 Slow Query Log 相关参数及使用建议 再来看看SlowQueryLog的相关参数配置。有些时候,我们为了定位系统中效率比较地下的Query语句,则需要打开慢查询日志,也就是SlowQueryLog。我们可以如下查看系统慢查询日志的相关设置: mysql> show variables like ‘log_slow%’; +——————+——-+ | Variable_name | Value | +——————+——-+ | log_slow_queries | ON | +——————+——-+ 1 row in set (0.00 sec) mysql> show variables like ‘long_query%’; +—————–+——-+ | Variable_name | Value | +—————–+——-+ | long_query_time | 1 | +—————–+——-+ 1 row in set (0.01 sec) “log_slow_queries”参数显示了系统是否已经打开SlowQueryLog功能,而“long_query_time”参数则告诉我们当前系统设置的SlowQuery记录执行时间超过多长的Query。在MySQLAB发行的MySQL版本中SlowQueryLog可以设置的最短慢查询时间为1秒,这在有些时候可能没办法完全满足我们的要求,如果希望能够进一步缩短慢查询的时间限制,可以使用Percona提供的microslow-patch(件成为mslPatch)来突破该限制。mslpatch不仅仅能将慢查询时间减小到毫秒级别,同时还能通过一些特定的规则来过滤记录的SQL,如仅记录涉及到某个表的SlowQuery等等附加功能。考虑到篇幅问题,这里就不介绍mslpatch给我们带来的更为详细的功能和使用,大家请参考官方介绍(http://www.mysqlperformanceblog.com/2008/04/20/updated-msl-microslow-patch-installation-walk-through/) 打开SlowQueryLog功能对系统性能的整体影响没有Binlog那么大,毕竟SlowQueryLog的数据量比较小,带来的IO损耗也就较小,但是,系统需要计算每一条Query的执行时间,所以消耗总是会有一些的,主要是CPU方面的消耗。如果大家的系统在CPU资源足够丰富的时候,可以不必在乎这一点点损耗,毕竟他可能会给我们带来更大性能优化的收获。但如果我们的CPU资源也比较紧张的时候,也完全可以在大部分时候关闭该功能,而只需要间断性的打开SlowQueryLog功能来定位可能存在的慢查询。 MySQL的其他日志由于使用很少(QueryLog)或者性能影响很少,我们就不在此过多分析了,至于各个存储引擎相关的日志,我们留在后面“常用存储引擎优化”部分再做相应的分析。

0%