php exec mysql命令-不同版本

Question

I've been messing with this for the past two days and am still trying to figure it out...

As a part of a larger script, I have the following command that I'm trying to run in a php file:

$export = exec("/usr/bin/mysqldump -u MY_USERNAME -pMY_PASS DATABASE_NAME products > /path/to/www/directory/sync/products.sql");

This command doesn't work and if I add and echo $result_var , I get 127 instead of 0, so there's obviously some error. After some research, I've managed to come up with a slightly different command and it works just fine:

$export = exec('mysqldump -u MY_USERNAME -pMY_PASS DATABASE_NAME products -r "/path/to/www/directory/sync/products.sql"');

My first question - what's the difference? Why doesn't the first option work? Maybe worth mentioning: using path on mysqldump makes no difference. I did a which mysqldump and the path in first command is correct.

My second question - I'm trying to run the following command to import a table into my database:

$import = exec('/usr/bin/mysql -h localhost -u MY_USERNAME -p MY_PASS DATABASE_NAME < /path/to/www/directory/sync/products.sql')

But it doesn't work, nothing happens. If I run it in command line, it just throws out the help text, as if I ran mysql -?

What am I missing here? Are there any other parameters (options) that I need to add to the mysql command? And, if so, what has changed? This code was running just fine on another server...

Answer 1

i can address the -r issue immediately. there is also a strong possibility that the -r issue is directly related to your second question.

the -r switch on mysqldump is the short version for --result-file. this switch does two basic things:

1. it stops \\n line endings from being converted by \\r\\n on windows. if your doing this on a windows box, this may be the reason why -r is required.
2. it forces the dump to happen even if there are errors. this may explain why the dump you've created isn't being inserted properly. did you inspect your dump file to make sure it's okay?

so, not a solution exactly, but maybe a help getting you looking in the right direction: inspect your dump file and see if there are problems with it.

edit

this may be a charcter encoding issue if you have utf-8 in your source db.

first check the charset of your centos machine

cat /etc/sysconfig/i18n 

see if it's utf-8. if it isn't that may be why the -r is required.

then test your two dbs to see what their charsets are

select schema_name as 'database', default_character_set_name as 'charset', default_collation_name as 'default_collation' from information_schema.schemata;

if your source db is utf-8 and your target db isn't, this may explain why the insert doesn't work. you can try adding this to your import mysql call:

--default-character-set=utf-8 

although, if your mysql isn't set up to handle utf-8 that may cause a whole separate set of errors

Answer 2

Answering my own question again...

My problem was caused by php safe_mode - after disabling safe_mode and enabling normal shell access for the user, everything is now working just fine.

Also, one minor detail - the command with mysql requires password without space after -p . In other words,

$import = exec('/usr/bin/mysql -h localhost -u MY_USERNAME -p MY_PASS DATABASE_NAME < /path/to/www/directory/sync/products.sql')

is not a valid command and -p must be followed by the password without space. Valid command would be:

$import = exec('/usr/bin/mysql -h localhost -u MY_USERNAME -pMY_PASS DATABASE_NAME < /path/to/www/directory/sync/products.sql')

I hope this helps someone...