cell_liu_个人页_阿里云开发者社区

发表了文章 2018-11-21

卸载wps后office图标无法显示（亲测有效）

之前电脑上安装了WPS软件，但是发现WPS还是有很多功能比不上OFFICE，于是把WPS卸载掉，安装了OFFICE2016，安装完OFFICE2016后发现EXCEL2016图标是空白的，不能正常显示。用右键选择指定程序打开，也不能关联上EXCEL2016图标。原因是卸载WPS时勾选了“保留用户配置文件”,导致WPS卸载后Office无法自动关联显示.doc.xls.ppt等文档的图标。解决方法如下：1.重新安装WPS,在开始菜单找到WPS的“配置工具”并打开；具体操作：开始–>所有程序–>WPS Office–>WPS Office 工具–>配置工具 2.在“配置工具”中取消勾选WPS默认为我们打开的指定文件；具体操作：配置工具–>高级，在“兼容设置”分页中，取消勾选红框中的选项，点击“确定” 3.点击确定后，桌面的图标会重新关联，即可以Microsoft Office的图标显示Word、Excel、PowerPoint文档啦。 4.最后，卸载WPS Office。具体操作：开始–>所有程序–>WPS Office–>WPS Office 工具–>卸载–>勾选“我想直接卸载WPS”–>取消勾选“保留用户配置文件以便下次使用”–>开始卸载。卸载时务必取消勾选“保留用户配置文件以便下次使用”

发表了文章 2017-05-31

this is incompatible with sql_mode=only_full_group_by

mysql 迁移到5.7后业务日志中出现： this is incompatible with sql_mode=only_full_group_by 解决方法： 1. https://dev.mysql.com/doc/refman/5.7/en/miscellaneous-functions.html ANY_VALUE() 2. SQL MODE 设置为空。

提交了问题 2017-03-14

MHA master宕机后的切换问题

发表了文章 2017-03-14

[error][/usr/local/share/perl5/MHA/Server.pm, ln242] Getting relay log directory or current relay logfile from repication table failed

MHA切换后检查主从复制出现：[root@Devops-mha-150 logs]# masterha_check_repl -conf=/etc/mha/10.66.150.117.cnf Tue Mar 14 12:27:23 2017 - [info] Reading default configuratoins from /etc/masterha_default.cnf..Tue Mar 14 12:27:23 2017 - [info] Reading application default configurations from /etc/mha/10.66.150.117.cnf..Tue Mar 14 12:27:23 2017 - [info] Reading server configurations from /etc/mha/10.66.150.117.cnf..Tue Mar 14 12:27:23 2017 - [info] MHA::MasterMonitor version 0.56.Tue Mar 14 12:27:24 2017 - error Getting relay log directory or current relay logfile from repication table failed on Devops-mysql-150-116(10.66.150.116:3306)!Tue Mar 14 12:27:24 2017 - error Error happend on checking configurations. at /usr/loca/share/perl5/MHA/ServerManager.pm line 269.Tue Mar 14 12:27:24 2017 - error Error happened on monitoring servers.Tue Mar 14 12:27:24 2017 - [info] Got exit code 1 (Not master dead). | relay_log_info_repository | TABLE 为TABLE的时候mha检查切换有问题。这台作为master机器的relay_log_info_repository忘记改为FILE 改为FILE就ok了。

发表了文章 2017-03-10

【总结】mysql半同步

半同步复制解决的问题：如果做读写分离，master insert进数据，由于其他问题，导致slave复制延迟。异步模式，master insert进入数据，就返回给业务正常。半同步模式， master insert进入数据，slave更新后，返回给master，master才返回给业务正常。 show plugins; 是否有semisync字母 show variables like 'plugin_dir' 查看plugins的路径进入到mysql的plugin目录，进入mysql提示符 master: install plugin rpl_semi_sync_master soname 'semisync_master.so' set global rpl_semi_sync_master_enabled=on; slave: install plugin rpl_semi_sync_slave soname 'semisync_slave.so' set global rpl_semi_rsync_slave_enabled=on; 在my.cnf加入 : master: rpl_semi_sync_master_enabled=1 slave: rpl_semi_sync_slave_enabled=1 master上有4个参数： rpl_semi_sync_master_enabled=on 开启半同步复制 rpl_semi_sync_master_timeout=10000 该参数默认10000毫秒，10秒。表示如果主库某次事务中的等待时间超过10秒，则降为异步复制模式，不再等待slave从库。 rpl_semi_sync_master_wait_no_slave 表示是否允许master每个事务提交后都要等待slave接受信号，默认为on rpl_semi_sync_master_trace_level=32 调试级别 slave上有2个参数： rpl_semi_sync_slave_enabled=on rpl_semi_sync_slave_trace_level=32 验证半同步数据： master: show variable like '%semi%'; 关注一下几个参数： rpl_semi_sync_master_status 服务器使用半同步模式还是异步模式 rpl_semi_sync_master_clients 多少个从服务器使用了半同步模式 rpl_semi_sync_master_yes_tx 从服务器确认的成功的提交数量 rpl_semi_sync_master_no_tx 从服务器确认的失败提交数量 slave: show variables like '%semi%' rpl_semi_sync_slave_status = on 从服务器是否是半同步复制模式半同步复制与异步复制的切换 1. stop slave stop slave io_thread; 该操作会将io线程关闭，等待10秒后，如果master未收到slave的接收确认信号，则转换为异步同步 start slave 会转换成半同步模式！半同步模式和io_thread有关系，和sql_thread没有关系。也就是说，slave接收完二进制日志后会给master一个确认，但不会管relay-log是否执行完成。

发表了文章 2017-03-10

SQL中遇到 like'%xx%'怎么优化

技巧如果你经常需要一个以通配符开头的查询，常用的方法是在数据库中保存需要查询的值的反序值。例如，假设你想要找所有以.com 结尾的电子邮件地址，当搜索 email Like '%.com' 时 MySQL不能使用索引；而搜索 reverse_email LIKE REVERSE('%.com')就可以使用定义在 reverse_email 列上的索引。 REVERSE(str) 返回颠倒字符顺序的字符串str。 mysql> select REVERSE('abc'); -> 'cba' 该函数对多字节可靠的。 key_len: 4 // INT NOT NULL key_len: 5 // INT NULL key_len: 30 // CHAR(30) NOT NULL key_len: 32 // VARCHAR(30) NOT NULL key_len: 92 // VARCHAR(30) NULL CHARSET=utf8 mysql> EXPLAIN SELECT p.* FROM parent p WHERE p.id NOT IN (SELECT c.parent_id FROM childc)\G ********************* 1. row *********************** id: 1 select_type: PRIMARY table: p type: ALL possible_keys: NULL key: NULL key_len: NULL ref: NULL rows: 160 Extra: Using where ********************* 2. row *********************** id: 2 select_type: DEPENDENT SUBQUERY table: c type: index_subquery possible_keys: parent_id key: parent_id key_len: 4 ref: func rows: 1 Extra: Using index 2 rows in set (0.00 sec) mysql> EXPLAIN SELECT p.* -> FROM parent p -> LEFT JOIN child c ON p.id = c.parent_id -> WHERE c.child_id IS NULL\G ********************* 1. row *********************** id: 1 select_type: SIMPLE table: p type: ALL possible_keys: NULL key: NULL key_len: NULL ref: NULL rows: 160 Extra: ********************* 2. row *********************** id: 1 select_type: SIMPLE table: c type: ref possible_keys: parent_id key: parent_id key_len: 4 ref: test.p.id rows: 1 Extra: Using where; Using index; Not exists 2 rows in set (0.00 sec) mysql> EXPLAIN SELECT p.* -> FROM parent p -> WHERE NOT EXISTS -> SELECT parent_id FROM child c WHERE c.parent_id = p.id)\G ********************* 1. row *********************** id: 1 select_type: PRIMARY table: p type: ALL possible_keys: NULL key: NULL key_len: NULL ref: NULL rows: 160 Extra: Using where ********************* 2. row *********************** id: 2 select_type: DEPENDENT SUBQUERY table: c type: ref possible_keys: parent_id key: parent_id key_len: 4 ref: test.p.id rows: 1 Extra: Using index 2 rows in set (0.00 sec)

发表了文章 2017-03-10

【总结】日常遇到的一些问题相关知识

RAID卡: bbu force wb 内核： 1. io调度 deadline noop 2. vm 管理 vm.swappiness = 0 文件系统 mount nobarrier data=ordered writeback 1. 加大队列 nr_requests 2. 关闭numa CPU: innodb_read_io_threads = cpu核心数/2 innodb_write_io_threads = cpu核心数/2 read + write = cpu核心数可以根据读写比例调整上述值磁盘： innodb_io_capacity = 硬盘的iops 脏页刷新：当超过innodb_max_dirty_pages_pct的设定值，会将innodb_buffer_pool刷新到磁盘重做日志ib_logfile写满后机器空闲的时候当写操作很频繁的时候，重做日志ib_logfile切换次数就会很频繁，只要有一个写满了，就会将脏页大量的刷入磁盘，这会对系统系统有整体的影响。为了避免过大的磁盘io ， innodb_adaptive_flushing会自适应刷新。参数默认开启。 innodb_buffer_pool: 1. innodb_buffer_poll有2个区域，sublist of new blocks（热数据） sublist of old blocks（不经常访问的数据）用户访问数据，如果缓冲区中有相应的数据，则返回，如果没有，从磁盘空间读入sublist of old blocks区域，然后再移动到2. sublist of new blocks 区域，然后在根据LRU算法将最近最少使用的数据移除旧数据页 3. 但是这其中也有一些问题，假如有些语句做统计用全表扫描，或者做一次mysqldump，这时就会进入sublist of new blocks区域，把一些真正的热数据提走，这样会造成缓冲区的进进出出，导致磁盘io繁忙 4. innodb_old_block_pec参数可以控制进入缓冲区sublist of old blocks的数量，默认37，占整个缓冲区的3/8。当全表扫描一个大表或者做mysqldump可以将innodb_old_block_pec设置的小些使数据块少量的进入缓冲区，从而让更多的热数据不被踢出。 Old database pages 23600 在旧区域存放多少页 pages made young 411111, not young 2987612 移动到新区域多少页 / 没有移动的有多少页 1274 youngs/s 16521 non-youngs/s 如果你没有全表扫描，发现youngs/s值很小，那么就该增大innodb_old_blocks_pec或者减少innodb_old_blocks_time 。如果进行了全表扫描，发现non-youngs/s的值很小，那么就应该增大innodb_old_blocks_time innodb数据恢复时间：依赖于 buffer poll ，脏页面比例，tps等因素 innodb_buffer_pool_instances = 10 innodb_buffer_poll实例的个数最多支持64 。 innodb_buffer_pool_size 必须大于1G innodb_buffer_pool_dump_at_shutdown = 1 关闭mysql时，把热数据dump到本地硬盘 innodb_buffer_pool_dump_now = 1 采用手工方式把数据dump到磁盘 innodb_buffer_pool_load_at_startup = 1 在启动时把热数据load到内存 innodb_buffer_pool_load_now = 1 采用手工方式把热数据load到内存慢日志：当数据库连接数很高时，此时需要注意，可以通过cacti监控软件观察时间点，然后把这一段时间点的慢日志截取出来 sed -n '/#Time:110720 16:17:20/,/end/p' mysql.slow > slow.log 然后用mysqldumpslow 命令取出最耗时的最长的10条慢sql进行分析 mysqldumpslow -s t -t 10 slow.log 主从同步： slave_exec_mode参数可自动处理同步复制错误 set global slave_exec_mode='IDEMPOTENT' 默认值是 STRICT 严格模式设置完毕后，当出现1023（记录没有找到）， 1026（主键复制）时，会自动跳过错误，并且记录到错误日志中。如果从库某几张表的数据和主库不一致，解决方法： 1. 停止slave 2. 在主库上导出这几张表，并记录下同步的binlog时间点和pos点 mysqldump -uroot -pxxx -q --single-transation --master-data=2 yourdb table1 table2 > xxxx.sql 3. 导入sql文件到从库。找出备份的sql文件中的binlog和pos点 4. change master 直到sql_thread线程为NO，这期间同步报错可以一律跳过 stop slave ; set global sql_slave_skip_counter=1 ; start slave; 如何干净的清除slave的同步信息 stop slave ; reset slave 不行。要使用 reset slave all；主从切换：事件调度器在主从切换出现的问题: set global event_scheduler = 1; 在主从架构中 event只能在主上触发，在slave上不能被触发，如果再slave上触发了，同步就会坏掉。 show event status ：slaveside_disabled 需要执行 alter event 'insert' enable 人工误删除innodb ibdata 数据文件，如何恢复：先找到mysqld进程的pid netstat -nlp | grep mysqld 这里是30246 执行 ll /proc/30426/fd | grep 'ib_|ibdata' 关闭前端业务，执行 flush tables with read lock set global innodb_max_dirty_pages_pct=0; 让脏页尽快刷新到磁盘 show engine innodb status\G;查看innodb状态信息，确保脏页已经刷新到磁盘。复制文件到mysql的数据目录。重启mysql where 从句中的in 子查询： select * from tables1 where filed in (select filed from table2 where cacheld='xxxx') 工作原理：mysql先要为内层的查询语句查询结果建立一个临时表，然后外层查询语句才能在临时表中查询记录，查询完成后，还需要撤销这些临时表。 sql优化案例分析： 1. not in 子查询优化在生产环境中，尽量避免子查询，可以用表连接取代。（select update delete ） 2. 模糊匹配 like '%xxx%'优化不要使用select * ， select * 无法覆盖索引。 select 字段必须存在索引。 3. limit 分页优化 select xx,xx,xx from logdb order by id limit 9999,10; select xx,xx,xx from logdb where id >=10000 order by id limit 10 4. count(*) 统计如何加快速度 count(*)如果数据量大一般都是比较慢的 select count(*) from L_user; 走聚集索引，innodb聚集索引就是数据，需要全表扫描统计。 select count(*) from L_user where Sid >=0; 如果加条件，走where后的Sid辅助索引，辅助索引不存放数据，而是由一个指针指向对应的数据块。统计时消耗的资源少，速度也更快。虽然上述方法加快了速度，类似统计的sql语句 select count(*) select sum() 。这不建议在主库执行，会导致锁表。不走索引，表锁。 5. or 条件优化 select * from USER where name='bob' or age='30'; 这条语句是不会走索引的。全表扫描。 select * from USER where name='bob' union all select * from USER where age='30' ############################################################################## 6. 不必要的排序 select count(1) as rs_count from ( select a.id,a.title,a.content,b.log_time,b.name from a b where a.content like 'rc_%' and a.id=b.id order by a.title desc ) as rs_table; select count(1) as rs_count from ( select a.id from a join b on a.id = b.id and a.content like 'rc_%' ) as rs_table 7. 不必要的嵌套 select 子查询 select count(1) as rs_count from ( select a.id,a.title,a.content,b.log_time,b.name from a b where a.content like 'rc_%' and a.id=b.id order by a.title desc ) as rs_table; select a.id,a.title,a.content,b.log_time,b.name from a join b on a.id = b.id and a.content like 'rc_%' order by a.title ######################################################################################################### 10.用where代替having 这个简单，就不举例子了

发表了文章 2017-03-10

如何看mysql锁信息

正在等待所有锁的信息： select * from innodb_lock_waits; 阻塞事物的列表： admin@172.17.0.81 15:15: [information_schema]>select * from innodb_locks where lock_trx_id in (select blocking_trx_id from innodb_lock_waits); 或者 admin@172.17.0.81 15:18: [information_schema]>select * from innodb_locks join innodb_lock_waits on (innodb_locks.lock_trx_id=innodb_lock_waits.blocking_trx_id); 特定表上的锁列表： admin@172.17.0.81 15:20: [information_schema]>select * from innodb_locks where lock_table='table_name'; 等待锁的事物列表： admin@172.17.0.81 15:39: [information_schema]>select trx_id,trx_requested_lock_id,trx_mysql_thread_id,trx_query from innodb_trx where trx_state='LOCK_WAIT';

发表了文章 2017-03-10

【总结】mysql log

Mysql 日志： 1. 错误日志 2. 查询日志 3. binlog日志 4. 慢查询日志 5. 审核日志 6. 二进制日志 1. 二进制日志bunlog日志：启用： log-bin[=PATH/[FILENAME]] expire_logs_days=30 max_binlog_size=1024M 删除：删除所有的binlog日志 ----> reset master ，binlog文件从00001开始只删除部分二进制日志 ----> purge master logs to 'log_name' purge master logs before 'date' 查看: show binlog events; show binlog events in 'log_name' 详细的可以用mysqlbinlog 还原： mysqlbinllog -----》重要的2个参数 --start-datetime、--stop-datetime --start-position、--stop--position 还原到时间点： mysqlbinlog --stop-datetime="xxx-xx-xx" binlog_name ..... 暂时停止： set sql_log_bin = {0|1} 2. 错误日志：启用： log-error=[path/[file_name]] 删除：删除错误日志后，需要执行flush logs 重新生成日志文件 > error.log 3. 查询日志：启用： log=path/[filename] 删除：删除查询日志后，需要执行flush logs 重新生成日志文件 > access.log 4. 慢查询日志启用： log-slow-queries[=path/[filename]] long_query_time=1 查看： mysqlslowdump 删除：删除慢查询日志后，需要执行flush logs 重新生成日志文件 > access.log 写事物流程： Mysql 日志： 1. 错误日志 2. 查询日志 3. binlog日志 4. 慢查询日志 5. 审核日志 6. 二进制日志 1. 二进制日志bunlog日志：启用： log-bin[=PATH/[FILENAME]] expire_logs_days=30 max_binlog_size=1024M 删除：删除所有的binlog日志 ----> reset master ，binlog文件从00001开始只删除部分二进制日志 ----> purge master logs to 'log_name' purge master logs before 'date' 查看: show binlog events; show binlog events in 'log_name' 详细的可以用mysqlbinlog 还原： mysqlbinllog -----》重要的2个参数 --start-datetime、--stop-datetime --start-position、--stop--position 还原到时间点： mysqlbinlog --stop-datetime="2014-7-2 15:27:48 binlog_name ..... 暂时停止： set sql_log_bin = {0|1} 2. 错误日志：启用： log-error=[path/[file_name]] 删除：删除错误日志后，需要执行flush logs 重新生成日志文件 > error.log 3. 查询日志：启用： log=path/[filename] 删除：删除查询日志后，需要执行flush logs 重新生成日志文件 > access.log 4. 慢查询日志启用： log-slow-queries[=path/[filename]] long_query_time=1 查看： mysqlslowdump 删除：删除慢查询日志后，需要执行flush logs 重新生成日志文件 > access.log mysql写日志流程：

发表了文章 2017-03-10

mysql processlist 线程状态（备查）

mysql processlist线程状态今天遇见Creating sort index 忘了是什么状态，记录以备查。 Analyzing 线程是对MyISAM 表的统计信息做分析(例如, ANALYZE TABLE )。 checking permissions 线程是检查服务器是否具有所需的权限来执行该语句。 Checking table 线程正在执行表检查操作。 cleaning up 线程处理一个命令,并正准备以释放内存和重置某些状态变量。 closing tables 线程是改变表中的数据刷新到磁盘和关闭使用的表。这应该是一个快速的操作。如果没有,你应该确认你没有一个完整的磁盘和磁盘是不是在十分繁重的情况下使用。 converting HEAP to MyISAM 线程是从转换内部临时表MEMORY内存表磁盘MyISAM表。 copy to tmp table 线程正在处理一个ALTER TABLE语句。这种状态发生后,与新结构的表已创建,但前行复制到它。 Copying to group table 如果语句有不同的ORDER BY和GROUP BY标准,按组排序的行复制到一个临时表。 Copying to tmp table 服务器复制到内存中的临时表。 Copying to tmp table on disk 服务器复制到一个临时表在磁盘上。临时结果集已经变得过于庞大(见7.8.4节,“MySQL如何使用内部临时表” )。因此,线程从内存中的临时表基于磁盘的格式,以节省内存。 Creating index 线程正在处理ALTER TABLE ... ENABLE KEYS ALTER TABLE ... ENABLE KEYS为MyISAM MyISAM表。 Creating sort index 线程正在处理一个SELECT就是使用内部临时表解决。 creating table 线程创建一个表。这包括建立临时表。 Creating tmp table 线程是创建一个临时表在内存或磁盘上。如果表是在内存中创建,但后来被转换成一个磁盘上的表,在该操作的Copying to tmp table on disk在磁盘上。 deleting from main table 服务器正在执行多表删除的第一部分。它只能从第一个表中删除,并保存列和删除从其他表(参考)偏移。 deleting from reference tables 服务器正在执行多表删除的第二部分,从其他表中删除匹配的行。 discard_or_import_tablespace 线程正在处理一个ALTER TABLE ... DISCARD TABLESPACE ALTER TABLE ... DISCARD TABLESPACE或ALTER TABLE ... IMPORT TABLESPACE ALTER TABLE ... IMPORT TABLESPACE语句。 end 这发生在年底前的清理ALTER TABLE , CREATE VIEW , DELETE , INSERT , SELECT或UPDATE语句。 executing 线程已开始执行语句。 Execution of init_command 线程正在执行中的价值陈述init_command系统变量。 freeing items 线程已执行的命令。释放一些在这种状态下完成的项目,涉及的查询缓存。这种状态通常后跟 cleaning up 。 Flushing tables 线程正在执行FLUSH TABLES ,等待所有线程关闭其表。 FULLTEXT initialization 该服务器是准备执行一个自然语言的全文检索。 init 这发生之前的初始化ALTER TABLE , DELETE , INSERT , SELECT或UPDATE语句。服务器在这种状态下采取的行动包括冲洗二进制日志中InnoDB日志,和一些查询缓存清理操作。对于end状态,以下操作可能会发生的事情：更改后删除表中的数据查询的缓存条目二进制日志中写一个事件释放内存缓冲区,包括为斑点 Killed 有人发送一个KILL线程的语句,它应该中止在下一次检查杀死标志。检查该标志是在每个MySQL中的主要循环,但在某些情况下可能还需要很短的时间为线程死亡。如果线程是由其他线程锁定,杀死尽快生效的其他线程释放它的锁。 Locked 查询被锁定由另一个查询。 logging slow query 线程正在写一慢查询日志的语句。 NULL 这种状态是用于SHOW PROCESSLIST状态。 login 连接线程的初始状态,直到客户端已成功通过身份验证。 Opening tables , Opening table 线程试图打开一个表。这应该是非常快的过程中,除非有阻止打开。例如,一个ALTER TABLE或LOCK TABLE语句可以防止打开一个表的语句,直到完成。您的table_cache值足够大,这也是值得一试。 optimizing 服务器执行查询的初始优化。 preparing 这种状态出现在查询优化过程中。 Purging old relay logs 线程是消除不必要的中继日志文件。 query end 这种状态发生后处理查询,但在此freeing items的项目状态。 Reading from net 服务器是阅读从网络数据包。 Removing duplicates 查询使用SELECT DISTINCT在这样一种方式是MySQL不能优化掉在早期阶段的不同操作。正因为如此,MySQL需要一个额外的的阶段,将结果发送到客户端之前删除所有重复行。 removing tmp table 线程是消除处理后,内部的SELECT表SELECT语句。如果没有创建临时表,这种状态是不使用。 rename 线程重命名表。 rename result table 线程正在处理一个ALTER TABLE语句,创建新表,并重新命名它来取代原来的表。 Reopen tables 线程有一个表锁,但注意到后锁底层表结构改变。它释放的锁,关闭表,并试图重新打开它。 Repair by sorting 修复代码是使用排序创建索引。 Repair done 该线程已完成了一个多线程的MyISAM表。 Repair with keycache 修复代码是使用创建密钥通过关键缓存。这是远远高于速度Repair by sorting进行排序。 Rolling back 线程回滚事务。 Saving state 如修理或分析MyISAM MyISAM表操作,线程是节能的新表的状态.MYI文件头。国家包括行数,如信息AUTO_INCREMENT计数器,以及关键的分布。 Searching rows for update 线程正在做第一阶段前更新他们找到所有匹配的行。这工作要做, UPDATE UPDATE正在改变,是用来寻找所涉及的行的索引。 Sending data 线程处理一个SELECT语句行,将数据发送到客户端。因为在这个状态发生的操作往往执行大量的磁盘访问(读取),它往往是在一个给定的查询的生命周期最长的运行状态。 setup 线程开始一个ALTER TABLE操作。 Sorting for group 线程是做一个分类,以GROUP BY集团。 Sorting for order 线程是做来满足ORDER BY排序。 Sorting index 线程排序索引的网页,更高效的访问MyISAM表的优化操作。 Sorting result 对于SELECT语句,这是Creating sort index类似,但nontemporary表。 statistics 服务器计算统计数据,以制定一个查询执行计划。如果一个线程处于这种状态很长一段时间,服务器可能是磁盘绑定执行其他工作。 System lock 该线程将要求或正在等待内部或外部的系统锁表。如果这种状态是造成外部锁的请求和您不使用多个mysqld的访问相同的MyISAM MyISAM表,你可以禁用与外部系统--skip-external-locking锁定选项。然而,外部锁定是默认禁用的,所以这个选项很可能不会有任何效果。 SHOW PROFILE ,这种状态意味着线程请求锁(不等待)。 Table lock 后的下一个线程状态System lock锁定。线程已经收购了外部锁定,并要求内部表锁。 Updating 线程正在寻找要更新的行和更新他们。 updating main table 服务器正在执行多表更新的第一部分。它是只更新第一个表,并节省列和用于更新其他表(参考)偏移。 updating reference tables 服务器正在执行多表更新的第二部分和更新从其他表匹配的行。 User lock 线程请求或要求与咨询锁等待GET_LOCK()调用。 SHOW PROFILE ,这种状态意味着线程请求锁(不等待)。 Waiting for release of readlock 线程正在等待另一个线程(与获得全局读锁FLUSH TABLES WITH READ LOCK TABLES)被释放。 Waiting for tables , Waiting for table 线程得到一个表的基本结构发生了变化的通知,它需要重新打开表,以获取新的结构。然而,重新打开表,它必须等到所有其他线程已经关闭了表中的问题。此通知发生,如果另一个线程已FLUSH TABLES或桌子上的问题下面的语句之一FLUSH TABLES tbl_name tbl_name ALTER TABLE , RENAME TABLE TABLE REPAIR TABLE TABLE ANALYZE TABLE TABLE, OPTIMIZE TABLE TABLE 。 Waiting on cond 在该线程正在等待一个条件,成为真正的一般状态。没有特定的状态信息是可用的。 Waiting to get readlock 线程已发出一个FLUSH TABLES WITH READ LOCK语句获得全局读锁,并正在等待获取锁。 Writing to net 服务器写一个数据包到网络上。

发表了文章 2017-03-09

innobackupex 出现Unrecognized character \x01; marked by <-- HERE after <-- HERE near column 1 at - line 1374.

centos 7.2 mysql 5.7.16 innobackupex version 2.4.6 [root@Devops-mysql-150-115 sh]# innobackupex --defaults-file=/app/mysql/servers/etc/ --user=root --password=xxxxxx /backup/mysql/ 备份出现错误：（有2个提示） 1. Unrecognized character \x01; marked by <-- HERE after <-- HERE near column 1 at - line 1374. google搜索后说bug。 170309 00:42:54 innobackupex: Starting the backup operation Failed to connect to MySQL server: Can't connect to local MySQL server through socket '/var/lib/mysql/mysql.sock' 看这个不像。 ####错误具体信息： IMPORTANT: Please check that the backup run completes successfully. At the end of a successful backup run innobackupex prints "completed OK!". Unrecognized character \x01; marked by <-- HERE after <-- HERE near column 1 at - line 1374. 170309 00:42:54 Connecting to MySQL server host: localhost, user: root, password: set, port: not set, socket: not set Failed to connect to MySQL server: Can't connect to local MySQL server through socket '/var/lib/mysql/mysql.sock' (2). ###### 解决方法：指定sock文件位置就ok了 innobackupex --defaults-file=/app/mysql/servers/etc/ --socket=/app/mysql/data/mysql.sock --user=root --password=xxxx /backup/mysql/ 备份成功

发表了文章 2017-03-08

ENFORCE_GTID_CONSISTENCY与临时表的问题

业务从5.6切到5.7后，启用gtid，业务有临时表。出现：修改 SET @@GLOBAL.ENFORCE_GTID_CONSISTENCY = off; 配置文件中 ENFORCE_GTID_CONSISTENCY = off; ### Checkpoint 1. Ensure that your workload is compatible with GTIDs. This checkpoint is needed because GTIDs do put (small) restrictions on the SQL you can execute. The following statements are disallowed: CREATE TABLE … SELECT; CREATE TEMPORARY or DROP TEMPORARY inside a transaction context; and mixing transactional tables with nontransactional tables in the same statement or in the same transaction context. Such statements must be eliminated from the workload (this is a good practice anyways, because the non-transactional nature of these statements makes them unsuitable for replication). We do not expect these to be severe limitations for most users. But, to be sure that enabling GTIDs does not cause any surprises, you can now pre-check your workload by enabling a mode that generates warnings for the GTID-violating statements. To complete checkpoint 1, do the following: 1. On each server, execute: SET @@GLOBAL.ENFORCE_GTID_CONSISTENCY = WARN, and set enforce-gtid-consistency=WARN in my.cnf. 2. Let it run for a while with your normal workload. Any GTID-violating statement will execute correctly, but generate a warning in the server log, like: 1 [Warning] Statement violates GTID consistency: Updates to non-transactional tables can only be done in either autocommitted statements or single-statement transactions, and never in the same statement as updates to transactional tables. or 1 [Warning] Statement violates GTID consistency: CREATE TABLE ... SELECT. or 1 [Warning] Statement violates GTID consistency: CREATE TEMPORARY TABLE and DROP TEMPORARY TABLE can only be executed outside transactional context. Look in the log for these warnings. If there are any warnings , adjust your SQL so that it only uses GTID-compatible statements. E.g., replace CREATE TABLE … SELECT by a CREATE TABLE statement followed by an INSERT statement, move CREATE/DROP TEMPORARY out of transactional context, or switch to InnoDB for any table that needs to be updated in the same transaction or in the same statement as other InnoDB tables. Notice that these statements are risky to use together with replication, so all this is good to do anyways. Repeat until it does not generate any warning. 3. On each server, execute: SET @@GLOBAL.ENFORCE_GTID_CONSISTENCY = ON, and set enforce-gtid-consistency=ON in my.cnf so that the value is preserved next time you need to restart (you don’t need to restart due to this procedure, but there could always be some other reason).

发表了文章 2017-03-02

ERROR 1114 (HY000): The table 'table1' is full

导出数据的时候提示表满了。 1. tmp空间不足： tmp_table_size = 1024Mmax_heap_table_size = 1024M 2. 磁盘空间不足: 清理磁盘空间.

提交了问题 2017-03-01

percona 5.7.16 bug

发表了文章 2017-03-01

percona 5.7.17遇到bug了！！

2017-03-01T02:06:28.098477Z 0 [Note] /usr/sbin/mysqld (mysqld 5.7.17-11-log) starting as process 117548 ... 2017-03-01T02:06:28.101658Z 0 [Warning] InnoDB: Using innodb_file_format is deprecated and the parameter may be removed in future releases. See http://dev.mysql.com/doc/refman/5.7/en/innodb-file-format.html 2017-03-01T02:06:28.101678Z 0 [Warning] InnoDB: Using innodb_file_format_max is deprecated and the parameter may be removed in future releases. See http://dev.mysql.com/doc/refman/5.7/en/innodb-file-format.html 2017-03-01T02:06:28.101722Z 0 [Note] InnoDB: PUNCH HOLE support available 2017-03-01T02:06:28.101728Z 0 [Note] InnoDB: Mutexes and rw_locks use GCC atomic builtins 2017-03-01T02:06:28.101730Z 0 [Note] InnoDB: Uses event mutexes 2017-03-01T02:06:28.101733Z 0 [Note] InnoDB: GCC builtin __atomic_thread_fence() is used for memory barrier 2017-03-01T02:06:28.101736Z 0 [Note] InnoDB: Compressed tables use zlib 1.2.7 2017-03-01T02:06:28.101738Z 0 [Note] InnoDB: Using Linux native AIO 2017-03-01T02:06:28.102704Z 0 [Note] InnoDB: Number of pools: 1 2017-03-01T02:06:28.102791Z 0 [Note] InnoDB: Using CPU crc32 instructions 2017-03-01T02:06:28.105548Z 0 [Note] InnoDB: Initializing buffer pool, total size = 200G, instances = 16, chunk size = 128M 2017-03-01T02:06:28.105560Z 0 [Note] InnoDB: Setting NUMA memory policy to MPOL_INTERLEAVE 2017-03-01T02:06:33.567127Z 0 [Note] InnoDB: Setting NUMA memory policy to MPOL_DEFAULT 2017-03-01T02:06:33.567156Z 0 [Note] InnoDB: Completed initialization of buffer pool 2017-03-01T02:06:34.965669Z 0 [Note] InnoDB: If the mysqld execution user is authorized, page cleaner thread priority can be changed. See the man page of setpriority(). 2017-03-01T02:06:34.977998Z 0 [Note] InnoDB: Recovering partial pages from the parallel doublewrite buffer at /var/lib/mysql/xb_doublewrite 2017-03-01T02:06:34.980687Z 0 [Note] InnoDB: Opened 3 undo tablespaces 2017-03-01T02:06:34.980696Z 0 [Note] InnoDB: 3 undo tablespaces made active 2017-03-01T02:06:34.980874Z 0 [Note] InnoDB: Highest supported file format is Barracuda. 2017-03-01T02:06:35.909477Z 0 [Note] InnoDB: Log scan progressed past the checkpoint lsn 43724088852 2017-03-01T02:06:36.036472Z 0 [Note] InnoDB: Doing recovery: scanned up to log sequence number 43729331712 2017-03-01T02:06:36.197614Z 0 [Note] InnoDB: Doing recovery: scanned up to log sequence number 43734574592 2017-03-01T02:06:36.338243Z 0 [Note] InnoDB: Doing recovery: scanned up to log sequence number 43739817472 2017-03-01T02:06:36.503259Z 0 [Note] InnoDB: Doing recovery: scanned up to log sequence number 43745060352 2017-03-01T02:06:37.542996Z 0 [Note] InnoDB: Doing recovery: scanned up to log sequence number 43726710272 2017-03-01T02:06:37.728222Z 0 [Note] InnoDB: Doing recovery: scanned up to log sequence number 43731953152 2017-03-01T02:06:37.875146Z 0 [Note] InnoDB: Doing recovery: scanned up to log sequence number 43737196032 2017-03-01T02:06:38.053155Z 0 [Note] InnoDB: Doing recovery: scanned up to log sequence number 43742438912 2017-03-01T02:06:38.206974Z 0 [Note] InnoDB: Doing recovery: scanned up to log sequence number 43747681792 2017-03-01T02:06:38.372973Z 0 [Note] InnoDB: Doing recovery: scanned up to log sequence number 43752924672 2017-03-01T02:06:38.544097Z 0 [Note] InnoDB: Doing recovery: scanned up to log sequence number 43758167552 2017-03-01T02:06:38.689065Z 0 [Note] InnoDB: Doing recovery: scanned up to log sequence number 43763410432 2017-03-01T02:06:38.822492Z 0 [Note] InnoDB: Doing recovery: scanned up to log sequence number 43767254868 2017-03-01T02:06:38.822957Z 0 [ERROR] [FATAL] InnoDB: Missing MLOG_FILE_NAME or MLOG_FILE_DELETE for redo log record 41 (page 4278124286:4278124286) at 43767234886. 2017-03-01 10:06:38 0x7ff88e714840 InnoDB: Assertion failure in thread 140705518405696 in file ut0ut.cc line 917 InnoDB: We intentionally generate a memory trap. InnoDB: Submit a detailed bug report to http://bugs.mysql.com. InnoDB: If you get repeated assertion failures or crashes, even InnoDB: immediately after the mysqld startup, there may be InnoDB: corruption in the InnoDB tablespace. Please refer to InnoDB: http://dev.mysql.com/doc/refman/5.7/en/forcing-innodb-recovery.html InnoDB: about forcing recovery. 02:06:38 UTC - mysqld got signal 6 ; This could be because you hit a bug. It is also possible that this binary or one of the libraries it was linked against is corrupt, improperly built, or misconfigured. This error can also be caused by malfunctioning hardware. Attempting to collect some information that could help diagnose the problem. As this is a crash and something is definitely wrong, the information collection process might fail. Please help us make Percona Server better by reporting any bugs at http://bugs.percona.com/ key_buffer_size=8388608 read_buffer_size=16777216 max_used_connections=0 max_threads=2001 thread_count=0 connection_count=0 It is possible that mysqld could use up to key_buffer_size + (read_buffer_size + sort_buffer_size)*max_threads = 98340377 K bytes of memory Hope that's ok; if not, decrease some variables in the equation. Thread pointer: 0x0 Attempting backtrace. You can use the following information to find out where mysqld died. If you see no messages after this, something went terribly wrong... stack_bottom = 0 thread_stack 0x40000 /usr/sbin/mysqld(my_print_stacktrace+0x3b)[0xeff3ab] /usr/sbin/mysqld(handle_fatal_signal+0x471)[0x79ff11] /lib64/libpthread.so.0(+0xf100)[0x7ff88e2f9100] /lib64/libc.so.6(gsignal+0x37)[0x7ff88c4835f7] /lib64/libc.so.6(abort+0x148)[0x7ff88c484ce8] /usr/sbin/mysqld[0x76e15c] /usr/sbin/mysqld(_ZN2ib5fatalD1Ev+0xfd)[0x11a093d] /usr/sbin/mysqld[0x106e7ff] /usr/sbin/mysqld(_Z18recv_parse_log_recP9mlog_id_tPhS1_PmS2_bPS1_+0xe2)[0x1071ad2] /usr/sbin/mysqld[0x107290e] /usr/sbin/mysqld[0x1073259] /usr/sbin/mysqld(_Z35recv_recovery_from_checkpoint_startm+0x1f52)[0x1075512] /usr/sbin/mysqld(_Z34innobase_start_or_create_for_mysqlv+0x45af)[0x114cf1f] /usr/sbin/mysqld[0x10067f0] /usr/sbin/mysqld(_Z24ha_initialize_handlertonP13st_plugin_int+0x51)[0x801e61] /usr/sbin/mysqld[0xcf5145] /usr/sbin/mysqld(_Z11plugin_initPiPPci+0x610)[0xcfc5d0] /usr/sbin/mysqld[0x7985cb] /usr/sbin/mysqld(_Z11mysqld_mainiPPc+0x656)[0x799bc6] /lib64/libc.so.6(__libc_start_main+0xf5)[0x7ff88c46fb15] /usr/sbin/mysqld[0x78f505] You may download the Percona Server operations manual by visiting http://www.percona.com/software/percona-server/. You may find information in the manual which will help you identify the cause of the crash.

发表了文章 2017-02-28

sqlserver2014忘记所有用户密码

我是o和m的dba啊，公司tfs sqlserver的所有密码都忘记了 nt账号以及sa 方法： mstsc.msc 服务 --> 停掉sqlserver服务。单用户，维护模式： C:\Users\administrator.EXPOPAY>net start mssqlserver /m The SQL Server (MSSQLSERVER) service is starting. The SQL Server (MSSQLSERVER) service was started successfully. 启动sqlserver management studio 后连接到数据库引擎修改sqlserver的身份验证sql和win身份验证重启server服务。 done。随笔记录。

发表了文章 2017-02-28

systemctl start mysql.service报错问题

pid文件位置问题： cat /etc/systemd/system/mysql.service [Unit] Description=MySQL Server Documentation=man:mysqld(8) Documentation=http://dev.mysql.com/doc/refman/en/using-systemd.html After=network.target After=syslog.target [Install] WantedBy=multi-user.target Alias=mysql.service [Service] User=mysql Group=mysql Type=forking PIDFile=/var/lib/mysql/Devops-mysql-slave-150.pid //修改为正确的mysql pid位置 # Disable service start and stop timeout logic of systemd for mysqld service. TimeoutSec=0 # Execute pre and post scripts as root PermissionsStartOnly=true # Needed to create system tables ExecStartPre=/usr/bin/mysqld_pre_systemd # Start main service ExecStart=/usr/sbin/mysqld --daemonize --pid-file=/var/lib/mysql/Devops-mysql-slave-150.pid $MYSQLD_OPTS ## 修改pid位置 # Use this to switch malloc implementation EnvironmentFile=-/etc/sysconfig/mysql # Sets open_files_limit LimitNOFILE = 5000 Restart=on-failure RestartPreventExitStatus=1 PrivateTmp=false 启动： systemctl start mysql.service 如果嫌mysql.service 麻烦，可以修改Alias=mysql.service为mysqld systemctl start mysqld

发表了文章 2017-02-22

into outfile csv问题：

into outfile 问题：导出数据出现：ERROR 1290 (HY000): The MySQL server is running with the --secure-file-priv option so it cannot execute this statement root@localhost 17:54: [(none)]>SELECT CategoryCode '类别编码',CategoryName '类别名称',ParentCode AS '父编码',LEVEL AS '级别',CASE IsLeaf WHEN 1 THEN '是' ELSE '否' END AS '是否末类',CASE STATUS WHEN 1 THEN '有效' ELSE '无效' END AS '状态' FROM erp_cms.category into outfile '/tmp/a.csv'; ERROR 1290 (HY000): The MySQL server is running with the --secure-file-priv option so it cannot execute this statement root@localhost 17:55: [(none)]>show variables like 'secure-file-priv'; root@localhost 17:57: [(none)]>show variables like '%secure_file%'; +------------------+-----------------------+ | Variable_name | Value | +------------------+-----------------------+ | secure_file_priv | /var/lib/mysql-files/ | +------------------+-----------------------+ 1 row in set (0.00 sec) mysql定义了outfile的导出目录，默认是/var/lib/mysql-files/ 解决方法有2种 1. 导出数据到/var/lib/mysql-files/ 中 root@localhost 17:57: [(none)]>SELECT CategoryCode '类别编码',CategoryName '类别名称',ParentCode AS '父编码',LEVEL AS '级别',CASE IsLeaf WHEN 1 THEN '是' ELSE '否' END AS '是否末类',CASE STATUS WHEN 1 THEN '有效' ELSE '无效' END AS '状态' FROM erp_cms.category into outfile '/var/lib/mysql-files/a.csv'; Query OK, 313 rows affected (0.00 sec) 2. 修改my.cnf 加入 [mysqld] secure-file-priv ##不对mysql导出目录做限制（不建议）打开后发现csv乱码： mysql默认编码： root@localhost 18:00: [(none)]>show variables like '%char%'; +--------------------------+-------------------------------------+ | Variable_name | Value | +--------------------------+-------------------------------------+ | character_set_client | utf8 | | character_set_connection | utf8 | | character_set_database | utf8 | | character_set_filesystem | binary | | character_set_results | utf8 | | character_set_server | utf8 | | character_set_system | utf8 | | character_sets_dir | /usr/share/percona-server/charsets/ | +--------------------------+-------------------------------------+ 8 rows in set (0.00 sec) 解决方法：导出时指定编码： GBK 。分隔符可选。 root@localhost 17:57: [(none)]>SELECT CategoryCode '类别编码',CategoryName '类别名称',ParentCode AS '父编码',LEVEL AS '级别',CASE IsLeaf WHEN 1 THEN '是' ELSE '否' END AS '是否末类',CASE STATUS WHEN 1 THEN '有效' ELSE '无效' END AS '状态' FROM erp_cms.category into outfile '/var/lib/mysql-files/a.csv' CHARACTER SET gbk FIELDS TERMINATED BY ',' OPTIONALLY ENCLOSED BY '"' LINES TERMINATED BY '\n'

发表了文章 2017-02-22

INFORMATION_SESSION_VARIABLES feature is disabled问题

mysql5.7 客户端连接出现：INFORMATION_SESSION_VARIABLES feature is disabled问题：从mysql5.7.6开始information_schema.global_status已经开始被舍弃，为了兼容性，mysql提供了向下兼容的参数：show_compatibility_56，默认是OFF。临时调整：set global show_compatibility_56=on; 修改mysql配置文件：[mysqld]show_compatibility_56=on

发表了文章 2017-02-22

group_concat长度限制问题

研发今天说group_concat函数导致结果显示不全。 group_concat作用：group_concat()函数，对查询的数据进行字符串连接操作。默认group_concat的值为1024 临时调整： set global group_concat_max_len=201400; 修改配置文件/etc/my.cnf group_concat_max_len = 102400 具体SQL： SELECT B.app_service AS Descr, COUNT(B.CountInInteval) AS TotalCount, GROUP_CONCAT(B.SysId) AS DetailLastSysIdStr, GROUP_CONCAT(B.CountInInteval) AS DetailCountStr FROM ( SELECT A.SysId, A.app_service, COUNT(A.DiffTime) AS CountInInteval FROM ( SELECT al2.SysId, al2.app_service, (UNIX_TIMESTAMP(al1.create_date) - UNIX_TIMESTAMP(al2.create_date)) AS DiffTime, al1.create_date AS create_date1, al2.create_date FROM ( SELECT al.SysId, al.app_service, al.create_date FROM access_log al WHERE al.system_id = @SystemId AND al.app_service <> 'System/GetSystemMenuList' AND al.create_date BETWEEN @StartDate AND @EndDate ) AS al1, ( SELECT al.SysId, al.app_service, al.create_date FROM access_log al WHERE al.system_id = @SystemId AND al.app_service <> 'System/GetSystemMenuList' AND al.create_date BETWEEN @StartDate AND @EndDate ) AS al2 WHERE al1.app_service = al2.app_service ) A WHERE A.DiffTime >= @Inteval AND A.DiffTime <= 0 GROUP BY A.SysId, A.app_service HAVING CountInInteval > 1 ORDER BY CountInInteval DESC ) B GROUP BY B.app_service ORDER BY TotalCount DESC LIMIT 5;

cell_liu_个人页

个人介绍

擅长的技术

卸载wps后office图标无法显示（亲测有效）

this is incompatible with sql_mode=only_full_group_by

MHA master宕机后的切换问题

[error][/usr/local/share/perl5/MHA/Server.pm, ln242] Getting relay log directory or current relay logfile from repication table failed

【总结】mysql半同步

SQL中遇到 like'%xx%'怎么优化

【总结】日常遇到的一些问题相关知识

如何看mysql锁信息

【总结】mysql log

mysql processlist 线程状态（备查）

innobackupex 出现Unrecognized character \x01; marked by <-- HERE after <-- HERE near column 1 at - line 1374.

ENFORCE_GTID_CONSISTENCY与临时表的问题

ERROR 1114 (HY000): The table 'table1' is full

percona 5.7.16 bug

percona 5.7.17遇到bug了！！

sqlserver2014忘记所有用户密码

systemctl start mysql.service报错问题

into outfile csv问题：

INFORMATION_SESSION_VARIABLES feature is disabled问题

group_concat长度限制问题

卸载wps后office图标无法显示（亲测有效）

this is incompatible with sql_mode=only_full_group_by

[error][/usr/local/share/perl5/MHA/Server.pm, ln242] Getting relay log directory or current relay logfile from repication table failed

【总结】mysql半同步

SQL中遇到 like'%xx%'怎么优化

【总结】日常遇到的一些问题相关知识

如何看mysql锁信息

【总结】mysql log

mysql processlist 线程状态（备查）

innobackupex 出现Unrecognized character \x01; marked by <-- HERE after <-- HERE near column 1 at - line 1374.

ENFORCE_GTID_CONSISTENCY与临时表的问题

ERROR 1114 (HY000): The table 'table1' is full

percona 5.7.17遇到bug了！！

sqlserver2014忘记所有用户密码

systemctl start mysql.service报错问题

into outfile csv问题：

INFORMATION_SESSION_VARIABLES feature is disabled问题

group_concat长度限制问题

MHA master宕机后的切换问题

percona 5.7.16 bug