Backup/Restore Mysql database

A simple approach on how to backup and restore MySQL databases.

Backup

To save an existing database it is recommended that you create a dump.

• To dump all databases you must run the command:

mysqldump --user=****** --password=****** -A > /path/to/file_dump.SQL 

• To dump several specific databases you must run the command:

mysqldump --user=****** --password=******  db_1 db_2 db_n> /path/to/file_dump.SQL

• To dump all tables from a database you must run the command:

mysqldump --user=****** --password=****** db > /path/to/file_dump.SQL

• To dump specific tables from a database you must run the command:

mysqldump --user=****** --password=****** db --tables tab1 tab2 > /path/to/file_dump.SQL

For each of the following commands you must specify a user (user) and password (password) with administrator rights on the database.

Restore your database

To restore a dump just launch the command:

mysql --user=****** --password=****** db_name < /path/to/file_dump.SQL

Note that

A database dump: is a record of the table structure and the data from a database, usually in the form of a list made of SQL statements.

Change your Hostname without Rebooting in RedHat Linux

Original Article

This tutorial covers changing your hostname in RedHat Linux without having to do a reboot for the changes to take effect. I've tested this on RedHat , Fedora Core , and CentOS . It should work for all the versions in between since they all closely follow the same RedHat configuration.


Make sure you are logged in as root and move to /etc/sysconfig and open the network file in vi.
cd /etc/sysconfig 
vi network



Look for the HOSTNAME line and replace it with the new hostname you want to use. In this example I want to replace localhost with redhat9.

HOSTNAME=redhat9

When you are done, save your changes and exit vi. Next we will edit the /etc/hosts file and set the new hostname.

vi /etc/hosts



In hosts, edit the line that has the old hostname and replace it with your new one.

192.168.1.110  redhat9

Save your changes and exit vi. The changes to /etc/hosts and /etc/sysconfig/network are necessary to make your changes persistent (in the event of an unscheduled reboot).
Now we use the hostname program to change the hostname that is currently set.
hostname redhat9
And run it again without any parameters to see if the hostname changed.
hostname

Finally we will restart the network to apply the changes we made to /etc/hosts and /etc/sysconfig/network.
service network restart

To verify the hostname has been fully changed, logout of your system and you should see your new hostname being used at the login prompt and after you've logged back in.



Quick, painless, and you won't lose your server's uptime.

MySQL Change root Password

How do I change MySQL root password under Linux, FreeBSD, OpenBSD and UNIX like operating system over ssh / telnet session?

Setting up MySQL password is one of the essential tasks. By default root user is MySQL admin account user. Please note that the Linux / UNIX root account for your operating system and MySQL root are different. They are separate and nothing to do with each other. Sometime your may remove mysql root account and setup admin as mysql super user for security purpose.

mysqladmin command to change root password

If you have never set a root password for MySQL server, the server does not require a password at all for connecting as root. To setup root password for first time, use mysqladmin command at shell prompt as follows:
$ mysqladmin -u root password NEWPASSWORD
However, if you want to change (or update) a root password, then you need to use the following command:
$ mysqladmin -u root -p'oldpassword' password newpass
For example, If the old password is abc, you can set the new password to 123456, enter:

$ mysqladmin -u root -p'abc' password '123456'

Change MySQL password for other users

To change a normal user password you need to type (let us assume you would like to change password for user asad) the following command:
$ mysqladmin -u asad -p oldpassword password newpass

Changing MySQL root user password using MySQL sql command

This is another method. MySQL stores username and passwords in user table inside MySQL database. You can directly update password using the following method to update or change password for user vivek:
1) Login to mysql server, type the following command at shell prompt:
$ mysql -u root -p
2) Use mysql database (type command at mysql> prompt):

mysql> use mysql;

3) Change password for user asad, enter:

mysql> update user set password=PASSWORD("NEWPASSWORD") where User='asad';

4) Finally, reload the privileges:

mysql> flush privileges;
mysql> quit

The last method can be used with PHP, Python or Perl scripting mysql API.

SVNSync

Using svnsync

Original Article

svnsync is a one way replication system for Subversion. It allows you to create a read-only replica of a repository over any RA layer (including http, https, svn, svn+ssh).
First, lets setup the initial sync. We have two repositories, I will skip the details of svnadmin create. For the remote access to the replica repository, I used svnserve, and I added a user with full write access. The destination repository should be completely empty before starting.


So, to make this easier, I am going to put the repository URIs into enviroment variables:

$ export FROMREPO=svn://svn.example.com/
$ export TOREPO=svn://dest.example.com/

Because the svnsync is allowed to rewrite anything on the TOREPO, we need to make sure the commit hooks are configured to allow our ‘svnsync’ user to do anything it wants.
On the server hosting TOREPO, I ran this:

$ echo "#!/bin/sh" > hooks/pre-revprop-change
$ chmod 755 hooks/pre-revprop-change

Now we are ready to setup the sync:

$ svnsync init ${TOREPO} ${FROMREPO}

This will prompt you for the username, password, and also sets several revision properties on the $TOREPO, for revision zero. It doesn’t actually copy any of the data yet. To list the properties that it created, run:

$ svn proplist --revprop -r 0 ${TOREPO}

  svn:sync-from-uuid
  svn:sync-last-merged-rev
  svn:date
  svn:sync-from-url

$ svn propget svn:sync-from-url --revprop -r 0 ${TOREPO}

  svn://svn.example.com/

So all the knowledge about what we are syncing from is stored at the destination repository. No state about this sync is stored in the source repository.
We are now ready to begin copying data:

$ svnsync --non-interactive sync ${TOREPO}

And if everything is setup correctly, you will start replicating data.
Except, I suck. And the first thing I did was hit control+c. I figured this is a cool replication system, so I just ran the sync command from above again, and got this:

$ svnsync --non-interactive sync ${TOREPO}

Failed to get lock on destination repos, currently held by 'svn.example.com:0e4e0d98-631d-0410-9a00-9320a90920b3'
Failed to get lock on destination repos, currently held by 'svn.example.com:0e4e0d98-631d-0410-9a00-9320a90920b3'
Failed to get lock on destination repos, currently held by 'svn.example.com:0e4e0d98-631d-0410-9a00-9320a90920b3'
Failed to get lock on destination repos, currently held by 'svn.example.com:0e4e0d98-631d-0410-9a00-9320a90920b3'
Failed to get lock on destination repos, currently held by 'svn.example.com:0e4e0d98-631d-0410-9a00-9320a90920b3'
Failed to get lock on destination repos, currently held by 'svn.example.com:0e4e0d98-631d-0410-9a00-9320a90920b3'
Failed to get lock on destination repos, currently held by 'svn.example.com:0e4e0d98-631d-0410-9a00-9320a90920b3'
Failed to get lock on destination repos, currently held by 'svn.example.com:0e4e0d98-631d-0410-9a00-9320a90920b3'
Failed to get lock on destination repos, currently held by 'svn.example.com:0e4e0d98-631d-0410-9a00-9320a90920b3'
Failed to get lock on destination repos, currently held by 'svn.example.com:0e4e0d98-631d-0410-9a00-9320a90920b3'
svnsync: Couldn't get lock on destination repos after 10 attempts

Oh snap. I guess its not so easy to restart after an aborted sync.
I started debugging, and found that svnsync kept its lock state in a special property in revision zero again.
So, To fix this, we can safely just delete this lock:

$ svn propdel svn:sync-lock --revprop -r 0  ${TOREPO}

Now running sync again works! Hurrah!
After the sync finishes, we will want to keep the replica up to date.
I personally set a ‘live’ sync, but it is also possible to use a crontab or other scheduling method to invoke sync whenever you want.
To setup a live sync, on the FROMREPO server, I appended this to my hooks/post-commit file:

svnsync --non-interactive sync svn://dest.example.com/ &

You will want to make sure that the user-running subversion (and the hook script) has a cached copy of the authentication info for the destination repository.
Unfortunately, the post-commit hook won’t catch everything, so we also need to added this to the post-revprop-change hook:

svnsync --non-interactive copy-revprops  svn://dest.example.com/ ${REV} &

This will help propagate things like editing svn:log messages.
And there you go, thats the path I took to mirror one of my repositories onto another machine.