寻觅生命中的那一片浅草......

文章属于类别 MySQL

install_xtrabackup-1.0_on_CentOS_5.4

wget http://www.percona.com/mysql/xtrabackup/1.0/source/xtrabackup-1.0-56.rhel5.src.rpm
mkdir -p /usr/src/redhat/SOURCES/
rpm -i xtrabackup-1.0-56.rhel5.src.rpm
cd /usr/src/redhat/SOURCES/
tar xf xtrabackup-1.0.tar.gz
cd xtrabackup-1.0
./configure
make
cd innobase/xtrabackup/
make
make install

/usr/bin/innobackupex-1.5.1 –help

Got error 28 from storage engine 解决方法

今天碰到数据库出错

Got error 28 from storage engine

查了一下,数据库文件所在的盘应该没事,应该是数据库用的临时目录空间不够

引用
磁盘临时空间不够导致。
解决办法:
清空/tmp目录,或者修改my.cnf中的tmpdir参数,指向具有足够空间目录

上面的说法应该比较清楚,还有一个类似的:

引用
mysql报以下错的解决方法

ERROR 1030 (HY000): Got error 28 from storage engine

出现此问题的原因:临时空间不够,无法执行此SQL语句

解决方法:将tmpdir指向一个硬盘空间很大的目录即可

原创内容如转载请注明:来自 阿权的书房
本帖地址:http://www.aslibra.com/blog/read.php/794.htm

Windows下mysqlimport批量txt文件

在Linux上把MySQL库导出为sql和txt,在Linux上是很容易导入

mysql -u root -ppassword dbname < db_struc.sql

mysqlimport –local -uroot -ppassword dbname `find . -name “*.txt”`

Windows下麻烦了,没有find,又不支持*.txt

后来想到办法,建了个bat文件

用替换的方法将文件修改为

mysqlimport -uroot -ppassword dbname d:\dump\table1.txt

mysqlimport -uroot -ppassword dbname d:\dump\table2.txt

进入cmd
c:
cd “\Documents and Settings\user\桌面\test_2011-03-10\2011-03-10”
创建数据库test
“F:\Program Files\xampp\xampp\mysql\bin\mysql.exe” -uroot -pmanypassword
CREATE DATABASE IF NOT EXISTS test DEFAULT CHARACTER SET utf8 COLLATE utf8_general_ci;
exit

导入数据结构
“F:\Program Files\xampp\xampp\mysql\bin\mysql.exe” -uroot -pmanypassword test < test_db_struc.sql
获取所有表的txt文件名
dir /b *.txt > c:\import.bat
现在的格式是
test_data.txt
test_data_a.txt

然后用editplus打开,替换成这样的格式
“F:\Program Files\xampp\xampp\mysql\bin\mysqlimport.exe” –local -uroot -pmanypassword test test_data.txt
“F:\Program Files\xampp\xampp\mysql\bin\mysqlimport.exe” –local -uroot -pmanypassword test test_data_a.txt

把import.bat放到c:\Documents and Settings\user\桌面\test_2011-03-10\2011-03-10
执行,数据就导进去了

mysql_drop_user错误

mysql> drop user ‘test_s99’@’%’;
ERROR 1268 (HY000): Can’t drop one or more of the requested users

revoke all on test_s99.* from ‘test_s99’@’localhost’;
drop user ‘test_s99’@’localhost’;

The DROP USER statement removes one or more MySQL accounts. To use it, you must have the DELETE privilege for the mysql database. Each account is named using the same format as for the GRANT  statement; for example, ‘jeffrey’@’localhost’. If you specify only the user name part of the account name, a host name part of ‘%’ is used. For additional information about specifying account names, see Section 12.5.1.2, “GRANT Syntax”.

DROP USER was added in MySQL 4.1.1. In MySQL 4.1, it serves only to remove account rows from the user table for accounts that have no privileges. To remove a MySQL account completely (including all of its privileges), you should use the following procedure, performing the steps in the order shown:

1.

Use SHOW GRANTS to determine what privileges the account has. See Section 12.5.5.12, “SHOW GRANTS Syntax”.
2.

Use REVOKE to revoke the privileges displayed by SHOW GRANTS. This removes rows for the account from all the grant tables except the user table, and revokes any global privileges listed in the user table. See Section 12.5.1.2, “GRANT Syntax”.
3.

Delete the account by using DROP USER to remove the user table row.

In MySQL 5.0.2 and up, DROP USER removes the account row in the user table and also revokes the privileges held by the account. It is not necessary to use DROP USER in conjunction with REVOKE.
Important

DROP USER does not automatically close any open user sessions. Rather, in the event that a user with an open session is dropped, the statement does not take effect until that user’s session is closed. Once the session is closed, the user is dropped, and that user’s next attempt to log in will fail. This is by design.

Before MySQL 4.1.1, DROP USER is not available. You should first revoke the account privileges using SHOW GRANTS and REVOKE as just described. Then delete the user table row and flush the grant tables as shown here:

http://dev.mysql.com/doc/refman/4.1/en/drop-user.html

mysql时区的修正

昨天暴风的技术人员找我要核对充值数据,说是时间对不上;我检查了之后发现二服的数据库的时间有问题,我使用from_unixtime()这个方法查看1257868800这个时间戳顯示的不是2009-11-11,而是2009-11-10 11:00:00,时间差了十三个小时。而后台显示那里是用from_unixtime()这个方法来显示时间格式的,所以所有的订单数据都对不上他们那边系统记录的时间。据说是因为装MYSQL的时候的时间不对,导致后来MYSQL的时区就不对了,后来系统虽然把时区改过来了,但是MYSQL的时区还是在装机的时候的那个时区,显示就错误了。

知道了原因之后就能解决了,上网搜索了一下,找到了解决的方法。现在把我的解决方式记录一下。

先检查MYSQL的时区,打开一台MYSQL时区正确的机器,然后打开有问题的机器,确认是时区错误。

先打开时区正确的机器:进入MYSQL,在命令行输入:mysql -uroot -p****(root的密码),进去之后输入show variables like ‘%time_zone%’;然后回车,得到如下的显示:

+——————+——–+
| Variable_name    | Value  |
+——————+——–+
| system_time_zone | CST    |
| time_zone        | SYSTEM |
+——————+——–+
2 rows in set (0.00 sec)

然后再输入select from_unixtime(1257868800);回车,得到如下结果:

+—————————+
| from_unixtime(1257868800) |
+—————————+
| 2009-11-11 00:00:00       |
+—————————+
1 row in set (0.00 sec)

好了,再去有问题有机器上执行相同的操作发现执行show variables like ‘%time_zone%’;得到的结果是:

+——————+——–+
| Variable_name    | Value  |
+——————+——–+
| system_time_zone | EDT    |
| time_zone        | SYSTEM |
+——————+——–+
2 rows in set (0.01 sec)

执行select from_unixtime(1257868800);得到的结果是:

+—————————+
| from_unixtime(1257868800) |
+—————————+
| 2009-11-10 11:00:00       |
+—————————+
1 row in set (0.00 sec)

时间差了十三个小时。怎么样把时区调回我们想要的呢?虽然网上说可以在命令行下执行set time_zone = ‘+8:00′;之后就设置了时区,但是这样的操作没有对全司有效。只是在执行这个之后再在命令行下执行其它的操作可以得到正确的数据。但是在phpmyadmin下得到的结果还是错的。所以要修改MYSQL的配置文件来达到修改全局变量的目的。

先去找到mysql的配置文件my.cnf,一般在/etc/my.cnf下面,可以cd /etc 然后find my.cnf找找,看能不能找到。找到之后就修改它,用VI打开:vi /etc/my.cnf,打开之后查找[mysqld],在VI输入“/”然后输入[mysqld],就定位到[mysqld]所在的位置,在它的下面加上default-time-zone = ‘+8:00′这一行,然后保存退出,重新启动MYSQL,使时区生效。这个时候再去MYSQL下查看刚才的那两条命令,就会发现时区都设置正确了。

到此,时区不对的问题就解决了。

转载自:http://www.codeo4.cn/?p=318

2025年五月
« 5月    
 1234
567891011
12131415161718
19202122232425
262728293031