背景:升级了一下mysql到最新版本 5.7.9,博客数据没有动,后导出数据备份时出现Couldn't execute 'SHOW VARIABLES LIKE 'gtid\_mode'',加上 --set-gtid-purged=off出现新错误的问题,总之一堆问题,最后还是终于导出了,特别是升级后一定要重启,啥玩意,艹。
实践如下,出现问题:
[root@iZ25dcp92ckZ backup]# mysqldump -uroot -p -ujustwinit_mysql_database > -ujustwinit_mysql_database.cn.sql
Enter password:
mysqldump: Couldn't execute 'SHOW VARIABLES LIKE 'gtid\_mode'': Table 'performance_schema.session_variables' doesn't exist (1146)




用mysqldump备份时出现下面的出错信息:
mysqldump:Couldn't execute  ‘SELECT @@GTID_MODE':Unknown system variable 'GTID_MODE' (1193)
造成此错误的原因是因为5.6引入了Global Transaction Identifiers (GTIDs) 。GTIDs可以让主从结构复制的跟踪和比较变得简单。mysqldump会试图查询这个系统变量,但这个变量在5.6之前的版本中不存在,所以产生错误。解决的方法很简单,在mysqldump后加上–set-gtid-purged=OFF命令
如:
mysqldump -h(主机名或ip) -u(用户名) -p(密码) 数据库名 --set-gtid-purged=off >d:/db.sql

From:http://www.rjkfw.com/s_3139.html
___________________________________________________________________

[root@iZ25dcp92ckZ ~]#  mysqldump  --set-gtid-purged=off -uroot -p -ujustwinit_mysql_database > -ujustwinit_mysql_database.cn.sql
Enter password:
mysqldump: Couldn't execute 'SHOW VARIABLES LIKE 'ndbinfo\_version'': Table 'performance_schema.session_variables' doesn't exist (1146)
解决办法:
[root@iZ25dcp92ckZ ~]# mysql_upgrade -u root -p --force
Enter password:
Checking server version.
Running queries to upgrade MySQL server.
Checking system database.
mysql.columns_priv                                 OK
mysql.db                                           OK
。。。。。。
sys.sys_config                                     OK
temperature.temperature                            OK
temperature.tempsetting                            OK
Upgrade process completed successfully.
Checking if update is needed.

再次导出:
[root@iZ25dcp92ckZ ~]#  mysqldump  --set-gtid-purged=off -uroot -p -ujustwinit_mysql_database > -ujustwinit_mysql_database.cn.sql
Enter password:
mysqldump: Couldn't execute 'SHOW VARIABLES LIKE 'ndbinfo\_version'': Native table 'performance_schema'.'session_variables' has the wrong structure (1682)

忘记重启了,于是重启下,再次导出,出现新的错:
[root@iZ25dcp92ckZ bin]#  mysqldump  --set-gtid-purged=off -u-ujustwinit_mysql_database_mysql_database -p -ujustwinit_mysql_database_mysql > -ujustwinit_mysql_database.cn.sql
Enter password:
mysqldump: Got error: 1044: Access denied for user '-ujustwinit_mysql_database_mysql'@'localhost' to database '-ujustwinit_mysql_database_mysql' when using LOCK TABLES

用mysqldump备份数据库时出现when using LOCK TABLES_:
--skip-lock-tables
普通用户备份mysql 数据库报错

mysql 无lock tables权限 报Access denied for user 'dbuser'@'localhost' to database 'db' when using LOCK TABLES

主要原因是该用户无lock tables 该权限,处理办法:

1. 给该普通用户赋予lock tables 权限,建议是删除该用户,重新用mysql命令建

2. 加上--skip-lock-tables即可

mysqldump -udbuser -p dbname --skip-lock-tables > dbname.sql


3. 使用root 备份


MySQL无lock tables权限 报Access denied for user when using LOCK TABLES:
http://www.linuxidc.com/Linux/2012-01/51802.htm

mysqldump  --set-gtid-purged=off --skip-lock-tables -u-ujustwinit_mysql_database_mysql_database -p -ujustwinit_mysql_database_mysql > -ujustwinit_mysql_database.cn.sql

成功了:
[root@iZ25dcp92ckZ bin]# mysqldump  --set-gtid-purged=off --skip-lock-tables -uroot -p justwinit_mysql_database  > jackxiang.com.database.bak.perfected.2015.12.29.sql
Enter password:



来自:http://www.amznz.com/error-native-table-performance_schema/


背景:作者的服务器之前是Windows的后迁移到linux上,发现SQL查询的表在Linux上对大小写敏感,出现找不到该表,如何不改变服务器的表名称为对应的小写或代码改大写就能做到呢,改下my.cnf即可做到,如下摘录。
为什么在Windows能正常运行的程序和数据库,在Linux就会出现问题呢。这时一般会怀疑系统环境的问题,因为程序和数据库是一样的。
然而其实是英文字母大小写导致的结果。
比如在首页调取数据库数据的SQL文如下。
SELECT user_name,id from User;
User表在Windows系统上的Table名为user,因为不区别英文字母大小写所以没问题。
而在Linux会怎么样呢?
迁移过来的Table名是user,而在SQL文里指定的是User表。别忘了这家伙(Linux)区别英文字母大小写,因此会提示该表(User表)不存在。
解决方法
大概有3种解决方法,第一个是修改数据库的Table名,第二个是修改程序,第三个是修改MySQL的参数。
第一和第二,就无需多做说明了,而第三种方法是利用MySQL参数lower_case_table_names。
lower_case_table_names
参数lower_case_table_names是,在MySQL里怎么区别Table英文字母大小的,默认是0。
0:区别大小写1:不区别大小写(Table名以小写保存)2:不区别大小写(Table名以原来的大小写保存)
这样一来就简单了,可以让MySQL不区别Table名的大小写。在/etc/my.cnf(yum安装时的默认路径)文件的[mysqld]下面添加lower_case_table_names = 1就可以了。
[mysqld]
...
lower_case_table_names = 1
...
修改MySQL参数之后,重启一下数据库。

来自:http://m.toutiao.com/i6223691155964428802/?tt_from=android_share&iid=3283494589&app=news_article&utm_medium=toutiao_android&utm_campaign=client_share
背景:一外包项目其字段名为order,且是字符串,还order by order,这样的一个搞法,为此,这块Mysql通过sql排序是有问题的,因为里面存的是整数,这块直接修改表为整数也就Ok了。
MySQL字符串相信大家都不陌生,在MySQL字符串排序时经常会遇到一些问题,比如下面的这
今天解决了一个关于MySQL字符串排序的很奇怪的问题,在数据里面定义的是varchar类型,实际存放的是Int类型的数据,按一下查询语句进行排序:
将字段*1或者+0可以将MySQL字符串字段按数值排序
如:
select * from table where 1 order by id*1 desc;
或者
select * from table where 1 order by id+0 desc;
除了上述方法外,这里附上一种排序方法,利用find_in_set()进行无敌排序
附上Mysql函数 find_in_set() 的用法:
-------------------------------------------------------
举个例子来说:
有个文章表里面有个type字段,他存储的是文章类型,有 1头条,2推荐,3热点,4图文 .....11,12,13等等
现在有篇文章他既是 头条,又是热点,还是图文,
type中以 1,3,4的格式存储.
们我们如何用sql查找所有type中有4图文标准的文章呢??

这就要我们的find_in_set出马的时候到了.
以下为引用的内容:
select * from article where FIND_IN_SET('4',type)
FIND_IN_SET(str,strlist)
Returns a value 如果字符串 str 在由 N 个子串组成的列表 strlist 中,返回一个 1 到 N 的值。一个字符串列表是由通过字符 “,” 分隔的多个子串组成。如果第一个参数是一个常数字符串,并且第二个参数是一个 SET 列类型,FIND_IN_SET() 函数将被优化为使用位运算!如果 str 在不 strlist 中或者如果 strlist 是一个空串,返回值为 0。如果任何一个参数为 NULL,返回值也是 NULL。如果第一个参数包含一个 “,”,这个函数将完全不能工作:
mysql> SELECT FIND_IN_SET('b','a,b,c,d');
-> 2
for example:
$sql = "select p.*, find_in_set(p.products_id,$string_hot_pid) as rank from products p where p.products_id in ($string_hot_pid) order by rank";
大家有什么好的想法和建议可以留下宝贵的意见 以便共同进步
来自:http://www.cnblogs.com/yhyjy/archive/2012/07/25/2607818.html
http://1055592535.iteye.com/blog/1674734
背景:Raspberry Pi下的mysql启动出现如下:
151017  8:33:10 [Note] Server socket created on IP: '127.0.0.1'.
151017  8:33:10 [ERROR] Can't start server: Bind on TCP/IP port: Cannot assign requested address
151017  8:33:10 [ERROR] Do you already have another mysqld server running on port: 3306 ?


注意关键词 Bind
  这时,可以打开/etc/mysql/my.cnf
  ...
  bind-address  = 192.168.141.25
  ...
  如果你也是这么写的,那么把它改成
  bind-address  = 0.0.0.0
  然后重启即可
  另外,mysql在启动时进行了端口的bind,那么当ip更换时,请注意这些细节

vi /etc/mysql/my.cnf

#bind-address           = 127.0.0.1
bind-address            = 0.0.0.0

来自:http://www.educity.cn/wenda/403390.html

实际情况是因为自己把lo给干掉了,没有127.0.0.1这个端口:
vi /etc/network/interfaces
auto lo
iface lo inet loopback
....

同理,apache2也是一样的道理,因为这个软的IP,没有了,于是也没法访问,得特别注意:
vi /etc/network/interfaces
背景:有时一些小的网站,比如个人博客需要每天备份数据,鉴于此,得自动化不是,这儿就是一个简单可行的好方法,配置上后就不用管了。更牛B点就是主辅助同步,在辅库上运行下面的脚本更发妥当。
1)备份权限列表需要哪些?
1.Select  读取
2.SHOW DATABASES 允许访问完整的数据库列表
4. LOCK TABLES 允许锁定表
5.RELOAD 允许载入和刷新服务器缓存
以上几点是必须的.请注意
主辅助是不复制角色表的。

2)实践添加备份用户如下:
grant SELECT, RELOAD, SHOW DATABASES, LOCK TABLES on *.* to 'back'@'localhost' identified by "************"

3)实现下面自动备份脚本:
cat backUpJustWinDatas.sh


4) 定时生成定时删除命令:
1)定时生成:
0 0 * * * /bin/bash /usr/local/scripts/backUpJustWinDatas.sh
2)删除旧的:
0 1 * * * find /data/backup/db.JustWin.com -mtime +7 -exec rm -R {} \;

最后,参考实践来源自:http://www.jb51.net/article/49099.htm
http://blog.163.com/o5655@126/blog/static/166742834201181393837133/
阿里有卖这玩意,有的是自己运维搞,放这儿备案下:
如何选择你的RDS:
http://help.aliyun.com/knowledge_detail.htm?knowledgeId=5989703
如何快速平稳的迁入RDS:
http://hidba.org/?p=899
http://hidba.org/?p=919
http://hidba.org/?p=929
http://hidba.org/?p=941
关系数据库:除了上面说的Facebook的MySQL的例子,PCIe闪存SSD卡通过缓存(又名读缓存)写入的功能也非常有利于关系数据库。热文件、索引、元数据都可以被放置在SSD中作为缓存使用。数据也可以被放置其中。当有查询、排序和计算操作时,数据库反应速度可以成倍地增加。

facebook的MySQL数据库使用FusionIO公司的IODrive PCIe闪存卡。使用这种闪存卡来代替传统的HDD,Facebook就可以关闭MySQL的低效冗余日志系统,并且能充分利用FusionIO的记录系统。通过结合PCIe闪存与较少的写入量,与同等HDD存储相比,可以将数据存储量减少50%,并降低50%的延迟,还能增加33%的吞吐量。从Facebook的角度来看,他们降低了存储基础设施和成本的投入,因为他们的客户获得了更快的响应时间。


推动PCIe/NVMe标准化和做更多的固态硬盘产品和解决方案仍然是见效非常快的角色

摘自:http://stor.zol.com.cn/386/3865458.html
ORACLE发给ACE的邮件中提到MySQL 5.7.8新功能,有几个地方比较感兴趣:

1、新增super_read_only选项防止read_only开启后,仍有SUPER权限的用户修改数据(这时只有复制线程能写数据),避免主从数据不一致等问题;

2、新增disabled_storage_engines选项,比如说可用来强制禁用MyISAM引擎,避免有人再意外创建MyISAM表;

3、即将发布mysqlpump客户端工具以取代mysqldump,这是全新的并行备份工具。测试备份6个一样大小的表,默认并发2线程时相比mysqldump提速2.1倍,并发6线程时则提速5倍,并发的威力还是很猛的,当然了,实际线上使用时还要考虑服务器的I/O压力能否承载得住。



总的来说,5.7版本是非常值得期待的
1.在http://www.percona.com/downloads/XtraBackup/LATEST/  下载对应平台的XtraBackup,这里使用的是 http://www.percona.com/redir/downloads/XtraBackup/XtraBackup-2.0.0/binary/Linux/x86_64/percona-xtrabackup-2.0.0.tar.gz



2.解压tar -zvxf percona-xtrabackup-2.0.0.tar.gz -C /usr/local/



3.因为MySQL我安装的是Percona-Server-5.5.21,而且安装目录为:/usr/local/Percona-Server-5.5.21-rel25.0-227.Linux.x86_64/,注:同样可以用于其他MySQL版本
Shell代码  收藏代码

    cd /usr/local/percona-xtrabackup-2.0.0/bin  
    cp * /usr/local/Percona-Server-5.5.21-rel25.0-227.Linux.x86_64/bin/  

因为系统Path里面已经加入
Shell代码  收藏代码

    export PATH=$JAVA_HOME/bin:/usr/local/Percona-Server-5.5.21-rel25.0-227.Linux.x86_64/bin:$PATH  



4.我的mysql的配置文件是/etc/my.cnf,如果不指定,XtraBackup默认使用此文件识别mysql安装目录,数据文件目录等信息



5.全量备份:innobackupex --user=DBUSER --password=DBUSERPASS /path/to/BACKUP-DIR/,我使用/data/backup/mysql/作为mysql备份文件存放目录
Shell代码  收藏代码

    innobackupex --user=YOUS --password=YOUS /data/backup/mysql  

看到类似输出说明备份成功,如出错,根据提示解决
Shell代码  收藏代码

    innobackupex: Backup created in directory '/data/backup/mysql/2012-05-28_19-01-32'  
    innobackupex: MySQL binlog position: filename 'mysql-bin.000063', position 44718229367  
    120528 19:07:53  innobackupex: completed OK!  

可以在/data/backup/mysql/2012-05-28_19-01-32看到备份的文件

此时,cat xtrabackup_checkpoints会看到
Shell代码  收藏代码

    backup_type = full-backuped  
    from_lsn = 0  
    to_lsn = 44718229367  
    last_lsn = 44718229367  





6.全量Preparing:innobackupex --apply-log /path/to/BACKUP-DIR
Shell代码  收藏代码

    innobackupex --user=YOUS --password=YOUS --apply-log /data/backup/mysql/2012-05-28_19-01-32/  



可以看到如下生成文件:
Shell代码  收藏代码

    -rw-r--r--. 1 root root          13 May 28 19:07 xtrabackup_binary  
    -rw-r--r--. 1 root root          26 May 29 15:07 xtrabackup_binlog_info  
    -rw-r--r--. 1 root root          43 May 29 15:07 xtrabackup_binlog_pos_innodb  
    -rw-r-----. 1 root root          85 May 29 15:07 xtrabackup_checkpoints  
    -rw-r-----. 1 root root     2097152 May 29 14:03 xtrabackup_logfile  

cat xtrabackup_checkpoints,可以看出是全量备份并且做了prepare的
Shell代码  收藏代码

    backup_type = full-prepared  
    from_lsn = 0  
    to_lsn = 49556823920  
    last_lsn = 49556823920  



7.增量备份的前提是必须已经做过全量备份。

增量备份:innobackupex --incremental /path/to/BACKUP-DIR/--incremental-basedir=BASEDIR,当有了INCREMENTAL-DIR-1之后,下一次增量备份的需要基于INCREMENTAL-DIR-1,变成innobackupex --incremental /path/to/BACKUP-DIR/ --incremental-basedir=INCREMENTAL-DIR-1

全量备份的目录是:/data/backup/mysql/2012-05-28_19-01-32
Shell代码  收藏代码

    innobackupex --incremental /data/backup/mysql --incremental-basedir=/data/backup/mysql/2012-05-28_19-01-32/ --user=YOUS --password=YOUS  



增量备份成功会生成目录/data/backup/mysql/2012-05-29_14-25-03

cat xtrabackup_checkpoints
Shell代码  收藏代码

    backup_type = incremental  
    from_lsn = 44718229367  
    to_lsn = 49556823920  
    last_lsn = 49556823920  



8.增量Preparing,对每一个增量备份目录:

innobackupex --apply-log --redo-only BASE-DIR --incremental-dir=INCREMENTAL-DIR-1
innobackupex --apply-log --redo-only BASE-DIR --incremental-dir=INCREMENTAL-DIR-2
Shell代码  收藏代码

    innobackupex --apply-log --redo-only /data/backup/mysql/2012-05-28_19-01-32/ --incremental-dir=/data/backup/mysql/2012-05-29_14-25-03 --user=YOUS--password=YOUS  

看到如下输出:
Shell代码  收藏代码

    120529 14:29:43 InnoDB: Shutdown completed; log sequence number 49556823920  
    120529 14:29:43 innobackupex: completed OK!  

cd BASE-DIR,cat xtrabackup_checkpoints
Shell代码  收藏代码

    backup_type = full-prepared  
    from_lsn = 0  
    to_lsn = 49556823920  
    last_lsn = 49556823920  

当把所有的增量备份都执行Preparing后,还可以全量备份和全部的增量备份做一次Preparing,

innobackupex --apply-log BASE-DIR



9.恢复数据:innobackupex --copy-back BASE-DIR



参考:http://www.percona.com/doc/percona-xtrabackup/innobackupex/innobackupex_script.html
来自:http://willvvv.iteye.com/blog/1544043
mysqlbinlog的问题求助:通过mysqlbinlog 导出来的日志文件,mysql如论如何都认不到File is not a binary log file

mysqlbinlog  mysql-bin.000067 >xxx.sql
mysqlbinlog  xxx.sql 这里就报错了
ERROR: File is not a binary log file

mysqlbinlog --start-position=433760210 --stop-position=433761222 mysql-bin.000067 >xx.sql
mysqlbinlog  xx.sql 也是报一样错
ERROR: File is not a binary log file
这个?
先确定 /home/mysql/bin/mysqlbinlog 是你当前运行的mysqld对应的版本,另外,可能是该binlog已经损坏了

Egg:
/usr/local/mysql/bin/mysqlbinlog --version
/usr/local/mysql/bin/mysqlbinlog Ver 3.4 for Linux at x86_64


摘自:http://zhidao.baidu.com/link?url=GB02-myeLDIVy8Y5koL8U1LYUThvflxxdhzP3NHU1FknlfF5JSYpkLmJb4Lxf7K5rIVFHGeinykj74rTsHlZVROVGkRorLxCBnjqVOwDxiq
经常给别人安装lnmp但是安装时间过长MYSQL密码容易忘记,在这里给大家介绍下如何更改密码。

1.停掉LNMP

/root/lnmp stop

2.修改MYSQL配置文件

vim /etc/my.cnf

光标到[mysqld]后面按一次“i”进入插入模式,然后按enter回车输入“skip-grant-tables”,在按ESC输入“:wq”回车即可保存。

3.启动LNMP

/root/lnmp start

4.修改密码

mysql
update user set Password = password ( '123456' ) where user = 'root' ;
exit

其中123456就是你的新密码,别忘记最后的分号要不然是不会更新好的。

5.将刚才配置过的my.cnf修改回来,删除掉skip-grant-tables即可,这样安全。

6.重启LNMP。

/root/lnmp restart

来自:http://jinzhe.net/post/42.html
Windows是my.ini,Linux是my.cnf:
背景:# Query_time: 3.124972  Lock_time: 0.000162 Rows_sent: 0  Rows_examined: 1
SET timestamp=1413791419;
UPDATE LOW_PRIORITY `boblog_blogs` SET `views`=`views`+1 WHERE `blogid`='4588';
阅读全文
在mysql数据库的err文件中看到如下信息:
  Plugin 'FEDERATED' is disabled
  InnoDB: The InnoDB memory heap is disabled

解决方法:vi /etc/my.cnf
  tmpdir = /tmp
  innodb_use_sys_malloc =0

重启问题解决?
这个参数是不是新的过时了呢?
InnoDB: Warning: Setting innodb_use_sys_malloc to FALSE is DEPRECATED. This option may be removed in future releases, together with the InnoDB's internal memory allocator.
InnoDB:警告:设置innodb_use_sys_malloc假是过时的。此选项可能会在未来的版本中删除,连同InnoDB的内存分配器。

[Note] Plugin 'FEDERATED' is disabled.
这个不用理会的,没事。
__________________________________________
在网上找到解决方案:

1、在MY.INI文件中的 [mysqld] 中增加一行tmpdir="D:/MySQL/data/"修改后,还是启动不了或者能启动但关机后又出现同样问题,接着我做了第二步,重启正常。

2、删除DATA目录下除数据库文件夹外的其他文件,重启mysql,问题解决.

上面办法我按做了但是不行,自己摸索出一个解决办法与上面差不多

第一步:只要删除MySQL目录下的ib_logfile0和ib_logfile1两个文件.

第二步:找出了无法启动的原因,MySQL在安装的时候不会自动初始tmpdir,临时文件目录,所以要在配置文件my.ini中添加tmpdir路径.

最后在my.ini中添加:

[mysqld]

#自己指定的临时文件目录

tmpdir="E:/Program Files/MySQL/MySQL Server 5.1/Temp/" //phpfensi.com

来自:http://www.phpfensi.com/mysql/20140927/6253.html


[root@jackxiang mysql]# ls ib_logfile
ib_logfile0  ib_logfile1  ib_logfile2  
查看mysql启动日志:
2014-10-01 11:08:45 0 [Warning] TIMESTAMP with implicit DEFAULT value is deprecated. Please use --explicit_defaults_for_timestamp server option (see documentation for more details).
这是数据库升级过程中,timestamp在5.6以前的数据库中默认not null,如果没有显示声明timestamp的默认值,那么该列用全0的”0000-00-00 00:00:00″作为默认值



加上还是会报这个问题,听说有一个坑,于是查了一下,这个Url有点用:http://cuelog.com/archives/4.html
如果初始化时出现
1  [Warning] TIMESTAMP with implicit DEFAULT value is deprecated. Please use --explicit_defaults_for_timestamp server option (see documentation for more details).

在mysql的安装根目录下生成的my.cnf中加入:
2  explicit_defaults_for_timestamp = true

还是报错,按mysql提示的执行下面的mysql启动命令:
按mysql的说明,接下来是执行:
3  ./bin/mysqld_safe --user=mysql --explicit_defaults_for_timestamp=1 &

——————————————————————————————————————————————
来自:
http://www.kankanews.com/ICkengine/archives/110105.shtml
http://www.williamsang.com/archives/818.html
背景:skip-name-resolve 参数的目的是不再进行反解析(ip不反解成域名),这样可以加快数据库的反应时间。修改配置文件添加并需要重启:[mysqld] skip-name-resolve添加后发现错误日志有警告信息:



[root@jackxiang mysql]# vi my.cnf
skip-name-resolve
# 禁止MySQL对外部连接进行DNS解析,使用这一选项可以消除MySQL进行DNS解析的时间。但需要注意,如果开启该选项,
# 则所有远程主机连接授权都要使用IP地址方式,否则MySQL将无法正常处理连接请求

实践如下:



重启mysql,发现日志还有:



1)按提示作下查询,果然有一个空账户和root帐户的Host是jackxiang:
select * from user where Host="jackxiang"\G;

mysql> select Host,User,Password from user where Host="jackxiang";
+-----------+------+-----------------------------------------------------+
| Host          | User  | Password                              |
+-----------+------+-----------------------------------------------------+
| jackxiang  |           |                                                                            |
| jackxiang |root      | *2CD42BDFDF0EB0E*Z****3458EB72EE1F17F26F |
+-----------+------+------------------------------------------------------+


2)查下localhost,因为大都是限定本机连接,不让外面机器连接,确保安全:
mysql> select Host,User,Password from user where Host="localhost" limit 2;
+-----------+-----------------+-------------------------------------------+
| Host      | User                     | Password                                               |
+-----------+-----------------+-------------------------------------------+
| localhost |                           |                                                               |
| localhost | jack_mysql          | *2CD42BDFDF0E***3458EB72EE1F17F26F |
+-----------+-----------------+-------------------------------------------+
3)把Host既是 jackxiang的,用户是空或root的Host修改为localhost:
mysql> update user set Host="localhost" where Host="jackxiang";
ERROR 1062 (23000): Duplicate entry 'localhost-' for key 'PRIMARY'
这样搞不行,得一个一个干掉,看有没有root同名的,查下:
mysql> select Host,User,Password from user where User="";
+-----------+------+----------+
| Host      | User | Password |
+-----------+------+----------+
| localhost |            |               |
| jackxiang |            |               |
+-----------+------+----------+

mysql> delete from user where  User="" and Password="";
Query OK, 2 rows affected (0.01 sec)

4)查下user为root的
mysql> select Host,User,Password from user where User="root";                                      
+-----------+------+-------------------------------------------+
| Host      | User | Password                                  |
+-----------+------+-------------------------------------------+
| localhost | root | *2CD42BDFDF0EB0E1A7777777777EE1F17F26F |
| jackxiang | root | *2CD42BDFDF0EB0E1A7777777777EE1F17F26F |
| 127.0.0.1 | root | *2CD42BDFDF0EB0E1A7777777777EE1F17F26F |
| ::1       | root | *2CD42BDFDF0EB0E1A7777777777EE1F17F26F |
+-----------+------+-------------------------------------------+

5)留下localhost就足够了,其余删除掉:
mysql> delete from user where Host !="localhost" and User="root";
Query OK, 3 rows affected (0.00 sec)

6)restart mysql:


日志warning还有一个:
[Warning] 'proxies_priv' entry '@ root@jackxiang' ignored in --skip-name-resolve mode.
解决办法:
然后删除表mysql.proxies_priv中和cvs类似与具体域名有关的行,方法同上。
mysql> select Host,User,Proxied_host,Proxied_user,With_grant,Grantor,Timestamp from proxies_priv ;
+-----------+------+--------------+--------------+------------+---------+----------------+
| Host      | User | Proxied_host | Proxied_user | With_grant | Grantor | Timestamp           |
+-----------+------+--------------+--------------+------------+---------+----------------+
| localhost | root |              |              |                              1 |         | 2014-07-14 13:26:08 |
| jackxiang | root |              |              |                              1 |         | 2014-07-14 13:26:08 |
+-----------+------+--------------+--------------+------------+---------+----------------+

mysql> delete from proxies_priv where Host="jackxiang";
Query OK, 1 row affected (0.02 sec)
这下彻底清静了。


原来是当时安装mysql后,多次grant授权引起的,。

备注:
  skip-name-resolve是禁用dns解析,避免网络DNS解析服务引发访问MYSQL的错误,一般应当启用。   启用后,在mysql的授权表中就不能使用主机名了,只能使用IP ,出现此警告是由于mysql 表中已经存在有 root@jackxiang 帐号信息。     我们把它删除就好了。   mysql>use mysql; mysql> delete  from user where HOST='localhost.localdomain'; Query OK, 2 rows affected (0.00 sec)   重启MYSQL ,发现警告已经没有啦。

来自:http://www.dedecms.com/knowledge/data-base/mysql/2012/0819/7084.html
http://blog.itpub.net/14184018/viewspace-1061224/
MySQL的用户密码可以为特殊字符么?  
不能出现"!" 其它都可以的。(MySQL用户密码中的特殊字符叹号(!)的妙用,把!后面的字符串做为命令执行了,在本文最后讲。)
但是当出现有* &号时,在登录时会出现:
mysql -uroot -pjack&*vac //这样是不行的(-p后不能有空格,否则还得输入密码,认为是db。),用双引号引起来也不行,最后,只能单引号,才能成功:
mysql -uroot -p'jack&*vac'
[root@jackxiang cache]#  mysql -uroot p'jack&*vac'
mysql>

登录成功!


_______________________Mysql密码里包含叹号,其!后面的字符串做为命令执行了_______________________________
MySQL用户密码中的特殊字符叹号(!)的妙用:
这篇文章主要介绍了MySQL用户密码中的特殊字符叹号(!)的妙用,本文介绍的是如果你的密码中含有叹号(!),那么在控制台登录时会出现错误哦,需要的朋友可以参考下

使用叹号(!)禁止用户终端进入的一个方法。

mysql> grant all privileges on wubx.* to ‘wubx'@'172.16.100.185′ identified by ‘fd52!wubx&,';
Query OK, 0 rows affected (0.00 sec)
mysql>quit;
#mysql -h 172.16.100.185 -u wubx -pfd52!wubx&,
-bash: !wubx@,: event not found

仔细看一下,原来他把!后面的字符串做为命令执行了。又试了一个Navicat的管理端,也一样存在密码不正常的问题。

在测一下程序方面是不是可以用,写一个PHP测一下。

$link = mysql_connect('172.16.100.185′,'wubx','fd52!wubx&,');
if (!link){
die(‘Could not connect:'.mysql_error());
}
echo ‘Connected successfully';mysql_close($link);
?>
#php testdb.php
Connected successfully
还看程序中能正常识别。
PHP还是可以OK通过的。

摘自:http://www.jb51.net/article/52526.htm
背景:MYSQL多实例配置、dc提到在实际开发中,其实在生产环境上也有类似的运用,因多种原因,1.存储技术飞速发展,IO不再是瓶颈  2.MySQL对多核CPU利用率低 3.NUMA对MySQL性能的影响等,链接在:http://blog.csdn.net/hylongsuny/article/details/7892488 。
在实际的开发过程中,可能会需要在一台服务器上部署多个MYSQL实例,那建议使用MYSQL官方的解决方案 mysqld_multi
1.修改my.cnf
  
如一个定义两个实例的参考配置:

[mysqld_multi]
mysqld = /usr/local/mysql/bin/mysqld_safe
mysqladmin = /usr/local/mysql/bin/mysqladmin
user = your_user
password = your_password

[mysqld1]
datadir = /data/db/my1

#连接
port = 3306
socket = /tmp/mysql3306.sock

#binlog
log-bin=/data/db/mylog1/mysql-bin
binlog_format=mixed
binlog_cache_size = 32M
expire_logs_days = 30

[mysqld2]
datadir = /data/db/my2

#连接
port = 3307
socket = /tmp/mysql3307.sock

#binlog
log-bin=/data/db/mylog2/mysql-bin
binlog_format=mixed
binlog_cache_size = 32M
expire_logs_days = 3



2.创建数据目录
mkdir -p /data/db/my21
mkdir -p /data/db/my2
chown mysql.mysql /data/db/my1 -R
chown mysql.mysql /data/db/my2 -R


3.初始化DB
/usr/local/mysql/scripts/mysql_install_db --datadir=/data/db/my1/ -uroot (mysql_install_db也是MYSQL官方自带工具)
/usr/local/mysql/scripts/mysql_install_db --datadir=/data/db/my2/ -uroot
chown mysql.mysql /data/db/my1/ -R
chown mysql.mysql /data/db/my2/ -R



4. 安装工具
cp /usr/local/mysql/bin/my_print_defaults /usr/bin/
cp /usr/local/mysql/bin/mysqld_multi /usr/bin/



5.创建、授权用户
CREATE USER "your_user"@"192.168.1.%" IDENTIFIED BY 'your_password';
GRANT ALL PRIVILEGES ON *.* TO "your_user"@"192.168.1.%";
flush privileges;



至此,mysql多实例配置已经完毕。我们看到多个不同的MYSQL实例是共用my.cnf的。多实例命令行管理:
1.mysql启动
mysqld_multi start 1 启动实例1
mysqld_multi start 1-2 启动实例1,2



2.mysql重启
mysqld_multi restart 1 重启实例1
mysqld_multi restart 1-2 重启实例1,2



3.mysql关闭
mysqld_multi stop 1 关闭实例1
mysqld_multi stop 1-2 关闭实例1,2



4.命令行登陆实例2
mysql -u your_user -p your_password -P3307 -S /tmp/mysql3307.sock


摘自Dc(施俊伟)兄弟的唐品blog:
http://www.dcshi.com/?p=410#more-410
背景:我查一些按顺序的uuid,后用select in(uuid,uuid2...),查出来的顺序是按uuid ,uuid2么?会不会出现不一致的情况。

select * from table_name where id in ()的时候,MySQL会自动按主键自增排序,要是按给定的顺序来取,如何实现呢?

select * from table_name where id in (122,1,5,323,23,1200) order by find_in_set(id, '122,1,5,323,23,1200')
这样读取出来的顺序为 122,1,5,323,23,1200

来自:http://blog.163.com/zhaoyingzhaoying@yeah/blog/static/168024152201110149140931/
示例:


Mysql FIND_IN_SET 语句原始排序:
find_in_set()
问:
mysql中怎么按in语句中的id顺序取数据
select * from ecs_goods where goods_id in (14,1,33,23)
按14,1,33,23这个顺序取
答:
在程序中,$idList='14,1,33,23';
select * from ecs_goods where goods_id in ($idList) order by FIND_IN_SET(goods_id,'$idList')

来自:http://jianzhong5137.blog.163.com/blog/static/9829049201201421430839/


注意,这个find_in_set单条记录没问题,比如唯一id的in。多条记录order会失效(instr也不全行,大部分可以,不过对于特殊的,比如CD是会认为C也在里面的情况。):
select * from act_log where answer in ('B','C','CD') order by instr( "'B','C','CD'",answer)
正确排序: B,B,C
select * from act_log where answer in ('B','C','CD') order by find_in_set( answer,"'B','C','CD'")
排序错误:CD,C,BB,C。
背景:mysql的严格模式有一句:my.cnf加了:sql-mode="STRICT_TRANS_TABLES,NO_AUTO_CREATE_USER,NO_ENGINE_SUBSTITUTION",中间有一个:NO_AUTO_CREATE_USER。
参看:https://jackxiang.com/post/6810/
阅读全文
[mysql]不要再执着于thread_concurrency
结论:
thread_concurrency 在GNU/Linux系统上没有用的。

不过很多LINUX自带的mysql包里面的配置文件都有thread_concurrency选项,
甚至Mysql官方源码里面的my-large.cnf my-innodb-heavy-4G.cnf里面也有。。
Xml代码  收藏代码

    # This permits the application TO give the threads system a hint FOR the  
    # desired NUMBER OF threads that should be run at the same TIME.  This  
    # VALUE ONLY makes sense ON systems that support the thread_concurrency()  
    # FUNCTION CALL (Sun Solaris, FOR example).  
    # You should try [NUMBER OF CPUs]*(2..4) FOR thread_concurrency  
    thread_concurrency = 8  
于是在网上就流传开了,在一些优化mysql配置的文章中,都说要把thread_concurrency设置为 CPU核数*2。

但是千万别上当,调整这个选项纯属浪费时间。
它只在Solaris < 9 的系统中有用。。。
而且从mysql5.6.1开始,这个选项就被废了。
http://bugs.mysql.com/bug.php?id=55001

INNODB:
innodb_thread_concurrency = 128
innodb_purge_threads = 32 # 5.6之后才支持大于1, 5.5上会自动变成1
# 默认设置为 0,表示不限制并发数,这里推荐设置为0,更好去发挥CPU多核处理能力,提高并发量


转至 http://blog.netzhou.net/?p=93

基本上用了mysql作为oltp业务的,基本上都会配置mysql的主从,一方面用mysql的主从做数据库的读写分离,另一方面mysql本身的单机备份不是很强,一般采用主从架构,在从上进行数据备份。
在这过程中或多或少出现一些主从不同步的情况,本文将对数据主从不同步的情况进行简单的总结,在看这篇文章请注意了本文主要从数据库层面上探讨数据库的主从不一致的情况,并不对主从的本身数据不一致引起的主从不同步进行说明:
1.网络的延迟
由于mysql主从复制是基于binlog的一种异步复制,通过网络传送binlog文件,理所当然网络延迟是主从不同步的绝大多数的原因,特别是跨机房的数据同步出现这种几率非常的大,所以做读写分离,注意从业务层进行前期设计。
2.主从两台机器的负载不一致
由于mysql主从复制是主上面启动1个io线程,而从上面启动1个sql线程和1个io线程,当中任何一台机器的负载很高,忙不过来,导致其中的任何一个线程出现资源不足,都将出现主从不一致的情况。
3.max_allowed_packet设置不一致
主上面设置的max_allowed_packet比从大,当一个大的sql语句,能在主上面执行完毕,从上面设置过小,无法执行,导致的主从不一致。
4.key自增键开始的键值跟自增步长设置不一致引起的主从不一致。
5.mysql异常宕机情况下,如果未设置sync_binlog=1或者innodb_flush_log_at_trx_commit=1很有可能出现binlog或者relaylog文件出现损坏,导致主从不一致。
6.mysql本身的bug引起的主从不同步。
7.版本不一致,特别是高版本是主,低版本为从的情况下,主上面支持的功能,从上面不支持该功能。
以上是我遇到的一些主从不同步的情况。或许还有其他的一些不同步的情况,请说出你所遇到的主从不一致的情况。
基于以上情况,先保证max_allowed_packet,自增键开始点和增长点设置一致,再者牺牲部分性能在主上面开启sync_binlog,对于采用innodb的库,推荐配置下面的内容
innodb_flush_logs_at_trx_commit = 1
innodb-support_xa = 1 # Mysql 5.0 以上
innodb_safe_binlog      # Mysql 4.0

同时在从上面推荐加入下面两个参数
skip_slave_start
read_only
背景:MySQL-Fullltext: 使用 MySQL 实现简单的搜索引擎,搜索下博文啥的,方便自己。
http://blog.csdn.net/zajin/article/details/10970207

零、 Mysql下的Web程序,如何实现全文检索:
使用逻辑搜索修饰符(Boolean search modifiers)
++表示必须
+表示要有的-表示不能有的
不带+或者-表示,任意一种
http://blog.csdn.net/froole/article/details/3497907
阅读全文
分页: 2/4 第一页 上页 1 2 3 4 下页 最后页 [ 显示模式: 摘要 | 列表 ]