My MASTER mysql server is on a local network, and I have a new slave which is remote (i.e. on the internet). As MASTER does not have an accessible IP, I gathered from the docs that I should establish a reverse tunnel. I execute this:
ssh -f -N -T -R 7777:localhost:3306 user#slave.slave.com
on the MASTER. The connection seems to work - I can go to the slave and connect
with mysql to the MASTER without problem. For some reason though, replication does
not start. MASTER is already replicating to two other slaves without problems - seems the configuration is correct there.
I initiated replication on the slave as:
CHANGE MASTER TO MASTER_HOST='127.0.0.1',
MASTER_PORT=7777,
MASTER_USER='my_repl',
MASTER_PASSWORD='xxxxx',
MASTER_LOG_FILE='mysql-bin.nnnnn',
MASTER_LOG_POS=mm;
SLAVE STATUS reports mysql trying to connect to the remote, but never succeeding:
error connecting to master 'my_repl#127.0.0.1:7777' - retry-time: 60 retries: 86400
Can anyone suggest how to diagnose this problem?
BTW: OS is Linux.
My apologies... I didn't realize I had to define a new user with 127.0.0.1 as
IP.
So, 'intranet' connections use
replication_user#machine_name
as id, the connection which comes through the reverse tunnel uses
replication_user#127.0.0.1
as id. Both have to be declared to mysql separately. The rest of the info in the original message is valid - maybe this helps someone...
Greetings,
John
PS: Forgot to mention - I debugged this remotely (both MASTER and SLAVE are remote to me) using tcpdump:
tcpdump -i lo 'tcp port 7777'
on the SLAVE side, and
tcpdump -i lo 'tcp port 3306'
on the MASTER (of course that would not be very useful when there is much traffic).
Related
I'm trying to implement a database backup cron (other solutions welcome) in my job but I have a small problem:
I have a large database that is over 10GB in space and the current vm doesn't have space to store it in the temporary file that mysql creates.
I know I can use mysqldump with a host parameter, but my question is, when doing that does the temporary file generated by mysqldump stay at the machine that is running it or does it stay on the database server?
UPDATE:
I forgot to mention that I'm trying to backup a network of websites and that some of them are behind a firewall (needing VPN access), some need server hopping to get to the database server.
You can run a shell script from an archive host, where you've traded password-less ssh keys with the database server. This lets you transfer the file directly over ssh, without creating any temp files on the remote database server:
ssh -C myhost.com mysqldump -u my_user --password=bigsecret \
--skip-lock-tables --opt database_name > local_backup_file.sql
Obviously there are ways to secure that password on the command line, but this a method that could accomplish what you want. One advantage of this method is that it doesn't require the archive host to have access to port 3306 on the remote host.
This guy's version is cool because it also compresses the data on-the-fly before transferring it over the network, and then he uncompresses it before loading it into a local database.
ssh me#remoteserver 'mysqldump -u user -psecret production_database | \
gzip -9' | gzip -d | mysql local_database
But that's why my version uses ssh -C, which enables its own compression algorithm and avoids extra gzip pipes.
Depending on the circumstance it might be a better idea to use MySQL replication. Set up MySQL on your backup server and configure it as a slave of your production database (see http://dev.mysql.com/doc/refman/5.7/en/replication-howto.html). You can then dump the slave database easily.
An advantage of this approach is you're not transferring 10GB each time you want to backup, you're only transferring any changes to the database as and when they occur.
You'll need to keep an eye on the replication though, because if it fails your slave database will become stale.
Closed. This question is off-topic. It is not currently accepting answers.
Want to improve this question? Update the question so it's on-topic for Stack Overflow.
Closed 9 years ago.
Improve this question
I opened a ssh tunnel as described in this post: Zend_Db: How to connect to a MySQL database over SSH tunnel?
But now I don't know what I actually did. Does this command affect anything on the server?
And how do I close this tunnel, because now I can't use my local mysql properly.
I use OSX Lion and the server runs on Ubuntu 11.10.
Assuming you ran this command: ssh -f user#mysql-server.com -L 3306:mysql-server.com:3306 -N as described in the post you linked.
A breakdown of the command:
ssh: that's pretty self-explanatory. Invokes ssh.
-f: (From the man ssh page)
Requests ssh to go to background just before command execution.
This is useful if ssh is going to ask for passwords or
passphrases, but the user wants it in the background.
Essentially, send ssh to background once you've entered any passwords to establish the connection; it gives the shell prompt back to you at localhost rather than logging you in to remote-host.
user#mysql-server.com: the remote server you'd like to log into.
-L 3306:mysql-server.com:3306: This is the interesting bit. -L (from the man ssh page):
[bind_address:]port:host:hostport
Specifies that the given port on the local (client) host is to be
forwarded to the given host and port on the remote side.
So -L 3306:mysql-server.com:3306 binds the local port 3306 to the remote port 3306 on host mysql-server.com.
When you connect to local port 3306, the connection is forwarded over the secure channel to mysql-server.com. The remote host, mysql-server.com then connects to mysql-server.com on port 3306.
-N: don't execute a command. This is useful for "just forwarding ports" (quoting the man page).
Does this command affect anything on the server?
Yes, it establishes a connection between localhost and mysql-server.com on port 3306.
And how do I close this tunnel...
If you've used -f, you'll notice that the ssh process you've opened heads into the background. The nicer method of closing it is to run ps aux | grep 3306, find the pid of the ssh -f ... -L 3306:mysql-server.com:3306 -N, and kill <pid>. (Or maybe kill -9 <pid>; I forget if just kill works). That has the beautiful benefit of not killing all your other ssh connections; if you've got more than one, re-establishing them can be a slight ... pain.
... because now I can't use my local mysql properly.
This is because you've effectively "captured" the local mysql process and forwarded any traffic that attempts to connect to it, off to the remote mysql process. A much nicer solution would be to not use local port 3306 in the port-forward. Use something that's not used, like 33060. (Higher numbers are generally less used; it's pretty common to port-forward a combination like this: "2525->25", "8080->80", "33060->3306" or similar. Makes remembering slightly easier).
So, if you used ssh -f user#mysql-server.com -L 33060:mysql-server.com:3306 -N, you'd then point your Zend connect-to-mysql function to localhost on port 33060, which would connect to mysql-server.com on port 3306. You can obviously still connect to localhost on port 3306, so you can still use the local mysql server.
This will kill all ssh sessions that you have open from the terminal.
sudo killall ssh
Note: adding as answer since comments don't support code blocks.
In my opinion it is better to NOT use -f and instead just background the process as normal with &. That will give you the exact pid you need to kill:
ssh -N -L1234:other:1234 server &
pid=$!
echo "waiting a few seconds to establish tunnel..."
sleep 5
... do yer stuff... launch mysql workbench whatever
echo "killing ssh tunnel $pid"
kill $pid
Or better yet, just create this as a wrapper script:
# backend-tunnel <your cmd line, possibly 'bash'>
ssh -N -L1234:other:1234 server &
pid=$!
echo "waiting a few seconds to establish tunnel..."
sleep 5
"$#"
echo "killing ssh tunnel $pid"
kill $pid
backend-tunnel mysql-workbench
backend-tunnel bash
I have a web app with 2 web servers and 2 database servers. The dbs are setup for multi master replication. (this is the primary environment)
I also have the exact same setup on a different location acting as standby, in case the primary env fails. (this is the backup env)
What I need is for the backup env to be in sync with the dbs of the primary site. However, all dbs in both environments have already replication configured.
How can I achieve my goal?
Thanks
If this is standard MySQL rather than MySQL Cluster (and from your setup I think is has to be), you can't AFAIK.
If you have hierarchical replication then you could make it work, but with multimaster you can't. The basic problem is that a slave can only have one master which is set by the CHANGE MASTER TO command.
MySQL Cluster operates in a more complex manner, you have several servers in each cluster and then the cluster can be replicated to another cluster... or something.
Not very helpful I'm afraid.
You can sync the backup servers to one of the other masters, but the backup servers would not be masters to each other until you have a problem and then you change the master slave relationships yourself.
1 Configure The Master
First we have to edit /etc/mysql/my.cnf. or /etc/my.cnf We have to enable networking for MySQL, and MySQL should listen on all IP addresses, therefore we comment out these lines (if existant):
#skip-networking
skip-external-locking
bind-address=0.0.0.0
log-bin=mysql-bin.log
binlog-do-db=exampledb (database name)
server-id=1
Then we restart MySQL:
/etc/init.d/mysql restart
Create a user with replication privileges
GRANT REPLICATION SLAVE ON *.* TO 'slave_user'#'%' IDENTIFIED BY '<some_password>'; (Replace <some_password> with a real password!)
FLUSH PRIVILEGES;
Take dump of database(exampledb) and run command
SHOW MASTER STATUS
It will give you result like
---------------+----------+--------------+------------------+
| File | Position | Binlog_do_db | Binlog_ignore_db |
+---------------+----------+--------------+------------------+
| mysql-bin.006 | 183 | database name| |
+---------------+----------+--------------+------------------+
1 row in set (0.00 sec
Write down this information, we will need it later on the slave!
Then leave the MySQL shell:
quit;
2 Configure The Slave
On the slave we first have to create the sample database exampledb:
mysql -u root -p
Enter password:
CREATE DATABASE exampledb;
quit;
store databse dump on slave
Now we have to tell MySQL on the slave that it is the slave, that the master is 192.168.0.100, and that the master database to watch is exampledb. Therefore we add the following lines to /etc/mysql/my.cnf or /etc/my.cnf if file doesnot exists copy from other location
server-id=2
master-host=192.168.0.100(ip address of master host machine)
master-user=slave_user(user name)
master-password=secret (password)
master-connect-retry=60
replicate-do-db=exampledb (database name)
Then we restart MySQL:
/etc/init.d/mysql restart
Finally, we must do this:
mysql -u root -p
Enter password:
SLAVE STOP;
In the next command (still on the MySQL shell) you have to replace the values appropriately:
CHANGE MASTER TO MASTER_HOST=’master ip address’, MASTER_USER='slave_user', MASTER_PASSWORD='<some_password>', MASTER_LOG_FILE='mysql-bin.006', MASTER_LOG_POS=183;
MASTER_HOST is the IP address or hostname of the master (in this example it is 192.168.0.100).
MASTER_USER is the user we granted replication privileges on the master.
MASTER_PASSWORD is the password of MASTER_USER on the master.
MASTER_LOG_FILE is the file MySQL gave back when you ran SHOW MASTER STATUS; on the master.
MASTER_LOG_POS is the position MySQL gave back when you ran SHOW MASTER STATUS; on the master.
Now all that is left to do is start the slave. Still on the MySQL shell we run
START SLAVE;
quit;
That's it! Now whenever exampledb is updated on the master, all changes will be replicated to exampledb on the slave. Test it!
Mysql Server1 is running as MASTER.
Mysql Server2 is running as SLAVE.
Now DB replication is happening from MASTER to SLAVE.
Server2 is removed from network and re-connect it back after 1 day. After this there is mismatch in database in master and slave.
How to re-sync the DB again as after restoring DB taken from Master to Slave also doesn't solve the problem ?
This is the full step-by-step procedure to resync a master-slave replication from scratch:
At the master:
RESET MASTER;
FLUSH TABLES WITH READ LOCK;
SHOW MASTER STATUS;
And copy the values of the result of the last command somewhere.
Without closing the connection to the client (because it would release the read lock) issue the command to get a dump of the master:
mysqldump -u root -p --all-databases > /a/path/mysqldump.sql
Now you can release the lock, even if the dump hasn't ended yet. To do it, perform the following command in the MySQL client:
UNLOCK TABLES;
Now copy the dump file to the slave using scp or your preferred tool.
At the slave:
Open a connection to mysql and type:
STOP SLAVE;
Load master's data dump with this console command:
mysql -uroot -p < mysqldump.sql
Sync slave and master logs:
RESET SLAVE;
CHANGE MASTER TO MASTER_LOG_FILE='mysql-bin.000001', MASTER_LOG_POS=98;
Where the values of the above fields are the ones you copied before.
Finally, type:
START SLAVE;
To check that everything is working again, after typing:
SHOW SLAVE STATUS;
you should see:
Slave_IO_Running: Yes
Slave_SQL_Running: Yes
That's it!
The documentation for this at the MySQL site is woefully out of date and riddled with foot-guns (such as interactive_timeout). Issuing FLUSH TABLES WITH READ LOCK as part of your export of the master generally only makes sense when coordinated with a storage/filesystem snapshot such as LVM or zfs.
If you are going to use mysqldump, you should rely instead on the --master-data option to guard against human error and release the locks on the master as quickly as possible.
Assume the master is 192.168.100.50 and the slave is 192.168.100.51, each server has a distinct server-id configured, the master has binary logging on and the slave has read-only=1 in my.cnf
To stage the slave to be able to start replication just after importing the dump, issue a CHANGE MASTER command but omit the log file name and position:
slaveserver> CHANGE MASTER TO MASTER_HOST='192.168.100.50', MASTER_USER='replica', MASTER_PASSWORD='asdmk3qwdq1';
Issue the GRANT on the master for the slave to use:
masterserver> GRANT REPLICATION SLAVE ON *.* TO 'replica'#'192.168.100.51' IDENTIFIED BY 'asdmk3qwdq1';
Export the master (in screen) using compression and automatically capturing the correct binary log coordinates:
mysqldump --master-data --all-databases --flush-privileges | gzip -1 > replication.sql.gz
Copy the replication.sql.gz file to the slave and then import it with zcat to the instance of MySQL running on the slave:
zcat replication.sql.gz | mysql
Start replication by issuing the command to the slave:
slaveserver> START SLAVE;
Optionally update the /root/.my.cnf on the slave to store the same root password as the master.
If you are on 5.1+, it is best to first set the master's binlog_format to MIXED or ROW. Beware that row logged events are slow for tables which lack a primary key. This is usually better than the alternative (and default) configuration of binlog_format=statement (on master), since it is less likely to produce the wrong data on the slave.
If you must (but probably shouldn't) filter replication, do so with slave options replicate-wild-do-table=dbname.% or replicate-wild-ignore-table=badDB.% and use only binlog_format=row
This process will hold a global lock on the master for the duration of the mysqldump command but will not otherwise impact the master.
If you are tempted to use mysqldump --master-data --all-databases --single-transaction (because you only using InnoDB tables), you are perhaps better served using MySQL Enterprise Backup or the open source implementation called xtrabackup (courtesy of Percona)
Unless you are writing directly to the slave (Server2) the only problem should be that Server2 is missing any updates that have happened since it was disconnected. Simply restarting the slave with "START SLAVE;" should get everything back up to speed.
I am very late to this question, however I did encounter this problem and, after much searching, I found this information from Bryan Kennedy: http://plusbryan.com/mysql-replication-without-downtime
On Master take a backup like this:
mysqldump --skip-lock-tables --single-transaction --flush-logs --hex-blob --master-data=2 -A > ~/dump.sql
Now, examine the head of the file and jot down the values for MASTER_LOG_FILE and MASTER_LOG_POS. You will need them later:
head dump.sql -n80 | grep "MASTER_LOG"
Copy the "dump.sql" file over to Slave and restore it:
mysql -u mysql-user -p < ~/dump.sql
Connect to Slave mysql and run a command like this:
CHANGE MASTER TO MASTER_HOST='master-server-ip', MASTER_USER='replication-user', MASTER_PASSWORD='slave-server-password', MASTER_LOG_FILE='value from above', MASTER_LOG_POS=value from above; START SLAVE;
To check the progress of Slave:
SHOW SLAVE STATUS;
If all is well, Last_Error will be blank, and Slave_IO_State will report “Waiting for master to send event”.
Look for Seconds_Behind_Master which indicates how far behind it is.
YMMV. :)
I think, Maatkit utilits helps for you! You can use mk-table-sync. Please see this link: http://www.maatkit.org/doc/mk-table-sync.html
Here is what I typically do when a mysql slave gets out of sync. I have looked at mk-table-sync but thought the Risks section was scary looking.
On Master:
SHOW MASTER STATUS
The outputted columns (File, Position) will be of use to us in a bit.
On Slave:
STOP SLAVE
Then dump the master db and import it to the slave db.
Then run the following:
CHANGE MASTER TO
MASTER_LOG_FILE='[File]',
MASTER_LOG_POS=[Position];
START SLAVE;
Where [File] and [Position] are the values outputted from the "SHOW MASTER STATUS" ran above.
Hope this helps!
Following up on David's answer...
Using SHOW SLAVE STATUS\G will give human-readable output.
Master:
mysqldump -u root -p --all-databases --master-data | gzip > /tmp/dump.sql.gz
scp master:/tmp/dump.sql.gz slave:/tmp/ Move dump file to slave server
Slave:
STOP SLAVE;
zcat /tmp/dump.sql.gz | mysql -u root -p
START SLAVE;
SHOW SLAVE STATUS;
NOTE:
On master you can run SET GLOBAL expire_logs_days = 3 to keep binlogs for 3 days in case of slave issues.
Here is a complete answer that will hopefully help others...
I want to setup mysql replication using master and slave, and since the only thing I knew was that it uses log file(s) to synchronize, if the slave goes offline and gets out of sync, in theory it should only need to connect back to its master and keep reading the log file from where it left off, as user malonso mentioned.
So here are the test result after configuring the master and slave as mentioned by: http://dev.mysql.com/doc/refman/5.0/en/replication-howto.html ...
Provided you use the recommended master/slave configuration and don't write to the slave, he and I where right (as far as mysql-server 5.x is concerned). I didn't even need to use "START SLAVE;", it just caught up to its master. But there is a default 88000 something retries every 60 second so I guess if you exhaust that you might have to start or restart the slave. Anyways, for those like me who wanted to know if having a slave going offline and back up again requires manual intervention.. no, it doesn't.
Maybe the original poster had corruption in the log-file(s)? But most probably not just a server going off-line for a day.
pulled from /usr/share/doc/mysql-server-5.1/README.Debian.gz which probably makes sense to non debian servers as well:
* FURTHER NOTES ON REPLICATION
===============================
If the MySQL server is acting as a replication slave, you should not
set --tmpdir to point to a directory on a memory-based filesystem or to
a directory that is cleared when the server host restarts. A replication
slave needs some of its temporary files to survive a machine restart so
that it can replicate temporary tables or LOAD DATA INFILE operations. If
files in the temporary file directory are lost when the server restarts,
replication fails.
you can use something sql like: show variables like 'tmpdir'; to find out.
Adding to the popular answer to include this error:
"ERROR 1200 (HY000): The server is not configured as slave; fix in config file or with CHANGE MASTER TO",
Replication from slave in one shot:
In one terminal window:
mysql -h <Master_IP_Address> -uroot -p
After connecting,
RESET MASTER;
FLUSH TABLES WITH READ LOCK;
SHOW MASTER STATUS;
The status appears as below: Note that position number varies!
+------------------+----------+--------------+------------------+
| File | Position | Binlog_Do_DB | Binlog_Ignore_DB |
+------------------+----------+--------------+------------------+
| mysql-bin.000001 | 98 | your_DB | |
+------------------+----------+--------------+------------------+
Export the dump similar to how he described "using another terminal"!
Exit and connect to your own DB(which is the slave):
mysql -u root -p
The type the below commands:
STOP SLAVE;
Import the Dump as mentioned (in another terminal, of course!) and type the below commands:
RESET SLAVE;
CHANGE MASTER TO
MASTER_HOST = 'Master_IP_Address',
MASTER_USER = 'your_Master_user', // usually the "root" user
MASTER_PASSWORD = 'Your_MasterDB_Password',
MASTER_PORT = 3306,
MASTER_LOG_FILE = 'mysql-bin.000001',
MASTER_LOG_POS = 98; // In this case
Once logged, set the server_id parameter (usually, for new / non-replicated DBs, this is not set by default),
set global server_id=4000;
Now, start the slave.
START SLAVE;
SHOW SLAVE STATUS\G;
The output should be the same as he described.
Slave_IO_Running: Yes
Slave_SQL_Running: Yes
Note: Once replicated, the master and slave share the same password!
Rebuilding the slave using LVM
Here is the method we use to rebuild MySQL slaves using Linux LVM. This guarantees a consistent snapshot while requiring very minimal downtime on your master.
Set innodb max dirty pages percent to zero on the master MySQL server. This will force MySQL to write all the pages to the disk which will significantly speed up the restart.
set global innodb_max_dirty_pages_pct = 0;
To monitor the number of dirty pages run the command
mysqladmin ext -i10 | grep dirty
Once the number stop decreasing you have reach the point to continue. Next reset the master to clear the old bin logs / relay logs:
RESET MASTER;
Execute lvdisplay to get LV Path
lvdisplay
Output will look like this
--- Logical volume ---
LV Path /dev/vg_mysql/lv_data
LV Name lv_data
VG Name vg_mysql
Shutdown the master database with command
service mysql stop
Next take a snaphot, mysql_snapshot will be the new logical volume name. If binlogs are place on the OS drive those need to be snapshot as well.
lvcreate --size 10G --snapshot --name mysql_snapshot /dev/vg_mysql/lv_data
Start master again with command
service mysql start
Restore dirty pages setting to the default
set global innodb_max_dirty_pages_pct = 75;
Run lvdisplay again to make sure the snapshot is there and visible
lvdisplay
Output:
--- Logical volume ---
LV Path /dev/vg_mysql/mysql_snapshot
LV Name mysql_snapshot
VG Name vg_mysql
Mount the snapshot
mkdir /mnt/mysql_snapshot
mount /dev/vg_mysql/mysql_snapshot /mnt/mysql_snapshot
If you have an existing MySQL slave running you need to stop it
service mysql stop
Next you need to clear MySQL data folder
cd /var/lib/mysql
rm -fr *
Back to master. Now rsync the snapshot to the MySQL slave
rsync --progress -harz /mnt/mysql_snapshot/ targethostname:/var/lib/mysql/
Once rsync has completed you may unmount and remove the snapshot
umount /mnt/mysql_snapshot
lvremove -f /dev/vg_mysql/mysql_snapshot
Create replication user on the master if the old replication user doesn't exist or password is unknown
GRANT REPLICATION SLAVE on *.* to 'replication'#'[SLAVE IP]' identified by 'YourPass';
Verify that /var/lib/mysql data files are owned by the mysql user, if so you can omit the following command:
chown -R mysql:mysql /var/lib/mysql
Next record the binlog position
ls -laF | grep mysql-bin
You will see something like
..
-rw-rw---- 1 mysql mysql 1073750329 Aug 28 03:33 mysql-bin.000017
-rw-rw---- 1 mysql mysql 1073741932 Aug 28 08:32 mysql-bin.000018
-rw-rw---- 1 mysql mysql 963333441 Aug 28 15:37 mysql-bin.000019
-rw-rw---- 1 mysql mysql 65657162 Aug 28 16:44 mysql-bin.000020
Here the master log file is the highest file number in sequence and bin log position is the file size. Record these values:
master_log_file=mysql-bin.000020
master_log_post=65657162
Next start the slave MySQL
service mysql start
Execute change master command on the slave by executing the following:
CHANGE MASTER TO
master_host="10.0.0.12",
master_user="replication",
master_password="YourPass",
master_log_file="mysql-bin.000020",
master_log_pos=65657162;
Finally start the slave
SLAVE START;
Check slave status:
SHOW SLAVE STATUS;
Make sure Slave IO is running and there are no connection errors. Good luck!
I recently wrote this on my blog which is found here... There are few more details there but the story is the same.
http://www.juhavehnia.com/2015/05/rebuilding-mysql-slave-using-linux-lvm.html
I created a GitHub repo with an script to solve this problem quickly. Just change a couple variables and run it (First, the script creates a backup of your database).
I hope this help you (and others people too).
How to Reset (Re-Sync) MySQL Master-Slave Replication
sometimes you just need to give the slave a kick too
try
stop slave;
reset slave;
start slave;
show slave status;
quite often, slaves, they just get stuck guys :)
We are using master-master replication technique of MySQL and if one MySQL server say 1 is removed from the network it reconnects itself after the connection are restored and all the records that were committed in the in the server 2 which was in the network are transferred to the server 1 which has lost the connection after restoration.
Slave thread in the MySQL retries to connect to its master after every 60 sec by default. This property can be changed as MySQL ha a flag "master_connect_retry=5" where 5 is in sec. This means that we want a retry after every 5 sec.
But you need to make sure that the server which lost the connection show not make any commit in the database as you get duplicate Key error Error code: 1062
I have my MySQL database server on Server 1. I want to have my Rails apps on two other servers - say A and B to be able to connect to this Server 1. What's the best way to do this?
In the my.cnf file it appears I can use the bind-address to bind to one and only one IP address. I can't specify the IP addresses of both A and B in my.cnf.
On the other hand, if I comment skip-networking, the gates are wide open.
Is there a golden mean? What are you folks doing to allow a DB server to listen to requests from multiple app servers and still stay secure?
If MySQL is running on Linux:
I am very biased towards using iptables (a.k.a. netfilter, the Linux firewall) to control incoming traffic to various ports. It's simple to use and very robust.
iptables -A INPUT -p tcp -s server1address/32 --dport 3306 -j ACCEPT
iptables -A INPUT -p tcp -s server2address/32 --dport 3306 -j ACCEPT
iptables -A INPUT -p tcp --dport 3306 -j DROP
The bind address is the local IP address of the server, not the allowable client addresses. In your situation, you can provide the static address of your server (in place of localhost) or, if your IP might change, just comment it out.
Again, to clarify: the bind-address is the address on which the server listens for client connections (you could have multiple NICs, or multiple IP addresses, etc.). It is also possible to change the port you want mysql to listen to.
You will want to make sure you configure the root password if you haven't already:
mysql> SET PASSWORD FOR 'root'#'localhost' = PASSWORD('yourpassword');
You would then use other means to restrict access to MySql to something like the local network (i.e. your firewall).
More info about iptables:
The iptables commands above must either be inserted in the existing iptables tables, or else you must delete the existing stuff and start from scratch with the commands above.
Insertion is not hard, but it depends a little bit on the Linux distribution you use, so I'm not sure what to recommend.
To start from scratch, you need to Flush and eXpunge the existing tables first:
iptables -F
iptables -X
Then insert the iptables firewall rules that you need to use, following the model indicated in my previous answer.
Then save the iptables rules. This is again distribution-dependent. On most Red Hat derivatives (Red Hat, Fedora, CentOS), it's enough to run:
service iptables save
Voila, your custom rules are saved. If the iptables service is enabled (check with "chkconfig --list iptables", it must be ":on" on runlevels 3 and 5, depending on your situation, but it's safe to set it ":on" on both 3 and 5 in any case) then your rules will survive the reboot.
At any time, you can check the current running iptables rules. Here's a few commands that do that, with various levels of verbosity:
iptables -L
iptables -L -n
iptables -L -n -v
Without -n, it will try to lookup the domain names and display them instead of IP addresses - this may not be desirable if DNS is not working 100% perfect.
So that's why I almost always use -n.
-v means "verbose", a bit harder to read but it gives more information.
NOTE: If you start from scratch, other services running on that machine may not be protected by iptables anymore. Spend some time and figure out how to insert the MySQL rules in the existing tables. It's better for your system's security.
In addition to getting the bind address right you'll need to open the correct port, create or configure the users and some other details. This explains it pretty clearly.
A DB server will listen to an indefinite number of clients.
Each client Rails app identifies the DB server.
The DB server waits patiently for connections. It has no idea how many clients there are or where the connections come from.
Edit
"how do you securely configure the DB wrt what servers to accept requests from?"
That's what networks, firewalls and routers are for.
That's why the database requires credentials from the Rail apps.