主库修改lower_case_table_names导致从库中断

今天软件商来部署应用,发现程序有问题,原因是他们给的数据库脚本中创建表的时候有大小写,但是程序里面读表的时候又没有严格的区分大小写,导致有些表找不到,因为Linux 的MySQL默认是区分大小写的,也就是lower_case_table_names=0,于是软件商要求我将该参数修改为lower_case_table_names=1,不然就只能回去修改程序了

为了别人方便,我想改就改吧,应该没啥影响,lower_case_table_names=是静态参数,只能修改my.cnf,并且还需要重启数据库,结果修改的时候只是改了主库,没有改从库,导致从库应用数据的时候报错,不得不重做从库

这里记录一下修改静态参数的顺序:如果是主从库环境的话,修改静态参数,静态参数指需要修改my.cnf配置文件的情况,应该先修改从库的配置文件,然后再修改主库的配置文件,等两边的参数一致了,再在主库上做其他的操作,这样从库应用就不会出错了

参数说明:

mysql> show variables like ‘%lower%‘;

+------------------------+-------+

| Variable_name      | Value|

+------------------------+-------+

| lower_case_file_system | OFF|

| lower_case_table_names | 1  |

+------------------------+-------+

2 rows in set (0.00 sec)

lower_case_file_system 表示数据目录所在的文件系统是否对文件名的大小写敏感。ON说明对文件名的大小写不敏感,OFF表示敏感。

lower_case_table_names

0:区分大小写

1:不区分大小写,其实是将程序发送的所有大写字符改成小写字符存储,适用于数据库名和表名

说明:Windows系统对大小写不敏感,MySQL也默认设置为对大小写不敏感。Linux对大小写敏感,MySQL默认设置对大小写敏感。MySQL只是对库名、表名,变量名区分大小写,列名与列的别名在所有的情况下均是忽略大小写的

将大小写敏感转换为不敏感方法

如果原来所建立库及表都是对大小写敏感的,想要转换为对大小写不敏感,主要需要进行如下3步:

1.将数据库数据通过mysqldump导出。

2.在my.cnf中更改lower_case_tables_name = 1,并重启mysql数据库。

3.将导出的数据导入mysql数据库。

需要注意的地方:

1、为了避免大小写引发的问题,一种推荐的命名规则是:在定义数据库、表、列的时候全部采用小写字母加下划线的方式,不使用任何大写字母

2、在任何系统中可以使用lower_case_tables_name=1。但使用该选项的不利之处是当使用show tables 或show databases 时,看不出表名是用大写还是小写。

3、请注意在Linux中如果需要将lower_case_tables_name = 0,设置为lower_case_tables_name=1,再重启mysqld之前,必须先将旧的数据库名和表名转换为小写。否则之前大写的表会无法识别了

时间: 2024-10-12 03:00:56

主库修改lower_case_table_names导致从库中断的相关文章

mongo主库地址变更,从库修改数据源IP

大概过程如下: 1.关闭原主库,拷贝所有的文件至新的服务器,启动主库 2.进入从库变更source use local > db.sources.find() { "host" : "10.x.x.1:35010″, "source" : "main", "syncedTo" : { "t" : 1399858333, "i" : 13 } } > db.sourc

修改hostname导致mysql重启slave失败的修复方法

修改hostname导致mysql重启slave失败的修复方法 (只针对于把slave的信息存在文件里面会出现这种情况,如果存在表里就不会有这种问题发生): 有时候我们很早之前修改完主机名后,跑了好几个月后,突然系统出问题,重启了数据库,发现start slave起不来了.提示找不到relay-log的文件名和位移了. 解决方法: > show slave status\G 记下目前的执行到的master的binlog的文件名和binlog pos: **********************

中兴U960E修改系统文件导致无法开机的解决办法

中兴的手机开启飞行模式时不能开启wifi,用惯了三星手机之后真的不习惯这一点.昨晚躺着床上终于忍受不了,照着网上的教程修改了一下.教程复制如下:------------------------------------------------------------------------------------------------------[转]中兴的手机开启飞行模式时无法开启WIFI.蓝牙很蛋疼!我喜欢开飞行,但却还会用手机开WIFI上会网.玩游戏1.手机安装RE管理器:2.手机安装SQ

主库创建存储过程时从库显示 Error 1049

MySQL Bugs: #72682: Replication MBR halts - stored procedure from unreplicated schema MySQL Bugs: #59135: replicate-wild-do-table: cross-database updates and create SPs break replication 如果从库只使用了replicate-wild-do-table,那么当主库创建存储过程时,从库会不同步,报错信息如下: 150

Linux 修改inittab导致系统无法启动修复

以红帽Linux为例,由于修改inittab内容不当,导致系统无法启动. 解决思路:启动时修改grub参数,进入单用户模式,将inittab文件恢复,重新启动系统即可.而且该方法不需要光盘启动,特别适合虚拟机下的inittab等文件的恢复. 解决步骤: 1.修改grub参数. 在启动Linux时,按上下键,进入启动参数选择模式. 2.按e键进入grub参数编辑模式. 3.选择启动项,将rhgb参数修改为single,敲回车返回,再按b键启动Linux. 将 grub append>ro root

004.MySQL主库手动复制至从库

一 主库手动复制至从库 1.1 Master主库锁表 1 mysql> flush tables with read lock; 2 Query OK, 0 rows affected (0.00 sec) 1.2 主库备份 1 [[email protected] ~]# mysqldump -uroot -p -B mydb > master.sql 说明:-B参数有建库语句. 1.3 从库导入数据库 1 [[email protected] ~]# mysql -uroot -padmi

selinux配置文件修改错误导致无法启动虚拟机

selinux配置文件修改错误导致无法启动虚拟机 问题 [[email protected] ~]# cat /etc/selinux/config # This file controls the state of SELinux on the system. # SELINUX= can take one of these three values: # enforcing - SELinux security policy is enforced. # permissive - SELin

备份宽带不足,innobackupex备份导致从库不可写

一.问题描述 收到从库写入失败的报警,于是上线查看,发现主要是由备份引起,但线上的MySQL众多,其它实例都没问题,只有这个实例报了,一定有其它原因,继续查找. 首先,我们来看备份的日志,在20:14:16的时候,备份程序将idb文件备份完,然后开始准备备份frm文件,首先执行flush no_write_to_binlog tables,然后执行flush tables with read lock,这都没问题, 但这从一秒开始,会阻塞住从库的DDL和DML操作.由于备份日志太长了,下面我只截

mysql主键的缺少导致备库hang

最近线上频繁的出现slave延时的情况,经排查发现为用户在删除数据的时候,由于表主键的主键的缺少,同时删除条件没有索引,或或者删除的条件过滤性极差,导致slave出现hang住,严重的影响了生产环境的稳定性,也希望通过这篇博客,来加深主键在innodb引擎中的重要性,希望用户在使用RDS,设计自己的表的时候,一定要为表加上主键,主键可以认为是innodb存储引擎的生命,下面我们就来分析一下这个案例(本案例的生产环境的binlog为row模式,对于myisam存储引擎也有同样的问题):(1).现象