Recently, I was checking the apache error logs of a project I was working on and found that it has lot of 404 errors for images. I used my apache error parsing script and found that most of the errors were because the production db was still having some references to images present in the stage machine.
I had to do a quick find and replace in the MySQL db and after a quick search came up with the following query, using the replace function.
UPDATE table SET field = REPLACE(field, 'stage-url', 'prod-url');
Since I was about to run this query on a prod db directly, I wanted to add another condition to replace only rows that contained the stage url as an additional precaution (of course after taking backup of the db 😉 ).
UPDATE table SET field = REPLACE(field, 'stage-url', 'prod-url') WHERE INSTR(field, 'stage-url') > 0;
Hope this query is useful for someone who also had a shock like me when they looked at the apache error logs 😉
Posted in Database Programming
Tagged Apache, MySQL, Query, replace
Today, I learned a very valuable lesson. Make sure you always enable binary logs in MySQL. I would have lost atleast 3 months of effort, if it was not enabled. Luckily it was enabled and I was able to do a point in time restore after someone did a wrong click.
If you maintain any kind of MySQL server (even if it is just a stage machine) make sure you enable binary logs in it. It is very easy to do and when something bad happens, you will be happy that you enabled it.
How to enable it
To enable binary logs all you have to do is to enable the following two settings in your
my.cnf config file.
log_bin = /var/log/mysql/mysql-bin.log
expire_logs_days = 100
The first setting specifies the location where the logs should be kept and the second setting specifies the number of days to keep the logs. The default value is 10, but I changed it to 100.
How to restore from binary logs
You can do a point in time restore by using the
mysqlbinlog tool, which comes with MySQL. Refer to this excellent tutorial to find out how to use
Posted in Database Programming
Tagged backup, MySQL, restore
During my days with dreamhost, in order to access MySQL from my local machine, I used to add my ip to the allowed host list. Even though security is compromised here, I really liked to use HeidiSQL for accessing MySQL database server instead of the built in MySQL console. But after my move to SliceHost, I found a little trick using which I can continue to use HeidiSQL from my local machine without adding my ip to the allowed host list.
This nice little trick is called port forwarding. Let me show you how I configured PuTTY so as to enable port forwarding.
First install MySQL and then configure SSH to use key based authentication and change the default port by following the articles at Slicehost. After installing MySQL and configuring SSH, download and install PuTTY from its download page. I recommend you to download the zip file containing all the files.
Then create a new session in PuTTY by entering the ip address and also the port. Then choose Connection -> SSH -> Tunnels. In the source port field enter a valid port number like 8600. In the destination field enter the value 127.0.0.1:3306. 3306 is the default port in which MySQL runs. The reason why I asked you to enter a different port in the source is that, in future if you run a MySQL server in your local machine for testing, it will clash with your port forwarding. Click the Add button and then start the session. Don’t forget to save the session.
Now open your favourite MySQL GUI client. Mine is HeidiSQL. In the connection settings, enter 127.0.0.1 as the Hostname and enter the port which you specified in the source field in PuTTY (8600) as port. Also enter your username, password, default database name and the click connect.
Now the request which goes to port 8600 of your local machine is forwarded to port 3600 of your MySQL server by PuTTY and you can safely use a GUI client for MySQL without adding any ip to the allowed host list. Note that it will work only when PuTTY is having the session opened.
I hope this is of help to you and let me know how it is working for you. Happy PuTTYing 😉
Posted in Database Programming, Unix/Server Stuff
Tagged HeidiSQL, Linux/Unix, MySQL, PuTTY, slicehost, SSH
Recently I moved my WordPress blog to a new server. I took the dump of the old database and imported it into the new MySQL server. Everything was fine except that I stated getting some strange characters in my posts. For instance I was getting (Nov â€” 3rd â€” 2007) instead of (Nov – 3rd – 2007).
It took me lot of research and googling to find the solution and so I thought of sharing it here so that it would be helpful for others who might face the same problem.
First I raised a support request in WordPress, but didn’t get a reply. After some googling, I found that it was due to wrong character set in my new MySQL server. Instead of having utf8 as the character set the MySQL database server was running in the default latin1 character set.
I changed the character set in the MySQL my.conf file and also in the wp-config.php file of WordPress and re imported the tables. Even this didn’t solve my problem. Later I found that there were certain characters in my wp-posts table which were encoded in latin1 character set even though the table is set to utf8 character set.
I then exported the table using a tool called Heidisql (which is by the way an excellent alternative to the command line MySQL client). I then opened the sql file in a text editor and changed all instances of latin1 to utf8 (basically a find/replace). I saved the file and imported the tables again and the junk characters are gone. 🙂
So the lesson learned the harder way, KEEP EVERYTHING IN UTF-8, ABSOLUTELY EVERYWHERE, FROM DAY ONE. You’ll be glad you did some day.
Posted in Database Programming, WordPress
Tagged Character, MySQL, set, utf8, WordPress