Issues with initial Operation

[Will G.]

Hello,

I have spent the better part of a week attempting to get MMM working
properly in our PCI compliant environment. The monitor server can
communicate with the DB servers without issue and all appears to be
well. However I found that the database servers are having problems
and are unable to assign IPs to themselves. Both of these servers are
running CentOS.

We are running both the Host IP and the floating IPs off of the same
interface. As such, I have the host IPs on eth0, and the floating IPs
on eth0:1. We do not want to put them on another interface as that
would add unnecessary complexity to the network. When everything is
going and the Masters are seen as online, the logs for the agent
indicate that it cannot assign the IP. Below I have included my conf
files, as well as a snippet from the logs. In The common.conf, I
tried both eth0 and eth0:1 for the cluster interface. Both yielded
the same result.

-= mmm_common.conf =-

active_master_role writer

<host default>
cluster_interface eth0:1
pid_path /var/run/mmmd_agent.pid
bin_path /usr/bin/mysql-mmm/
replication_user ******************
replication_password ********************
agent_user **************
agent_password **************
</host>

<host dbmaster01>
ip 192.168.207.13
mode master
peer dbmaster02
</host>

<host dbmaster02>
ip 192.168.207.12
mode master
peer dbmaster01
</host>

<role writer>
hosts dbmaster01, dbmaster02
ips 192.168.207.15
mode exclusive
</role>

<role reader>
hosts dbmaster01, dbmaster02
ips 192.168.207.15
mode exclusive
</role>

=-=-=-=-=-=-=-=-=-=

-= mmm_agent.conf (from dbmaster01)=-
include mmm_common.conf
this dbmaster01

=-=-=-=-=-=-=-=-=-=

-= mmm_mon.conf =-
include mmm_common.conf

<monitor>
ip 192.168.206.11
pid_path /var/run/mmmd_mon.pid
bin_path /usr/bin/mysql-mmm/
status_path /var/lib/misc/mmmd_mon.status
ping_ips 192.168.205.11, 192.168.207.12, 192.168.207.13
</monitor>

<host default>
monitor_user **************
monitor_password **************
</host>

debug 0
=-=-=-=-=-=-=-=-=-=

-= mmmd_agent.error (from dbmaster01) =-
2009/12/03 22:15:04 FATAL Couldn't configure IP '192.168.207.15' on
interface 'eth0:1': undef
2009/12/03 22:15:07 FATAL Couldn't configure IP '192.168.207.15' on
interface 'eth0:1': undef
2009/12/03 22:15:10 FATAL Couldn't configure IP '192.168.207.15' on
interface 'eth0:1': undef
2009/12/03 22:15:13 FATAL Couldn't configure IP '192.168.207.15' on
interface 'eth0:1': undef
2009/12/03 22:15:16 FATAL Couldn't configure IP '192.168.207.15' on
interface 'eth0:1': undef
2009/12/03 22:15:19 FATAL Couldn't configure IP '192.168.207.15' on
interface 'eth0:1': undef
2009/12/03 22:15:22 FATAL Couldn't configure IP '192.168.207.15' on
interface 'eth0:1': undef
=-=-=-=-=-=-=-=-=-=

I am aware that both the read and write IPs are the same and only have
one. That is another thing I have a question about. In our setup,
the software we are using does not support multiple DB servers. I saw
today that MMM will allocate the same IP to multiple devices using
this configuration. Is there a way to fix that so that it works to
ONLY have one server active for both reads and writes using a single
IP at a time? I suppose I could assign an arbitrary "read" ip that
isn't really used for anything, as all of the traffic to the server
will be going on the "write" IP. We are using this setup primarily
for HA, and not really for any kind of load balancing or distribution.


Any help or guidance in regards to both of these issues would be
greatly appreciated.

Thanks,

Will G.

[Miguel Angel Nieto]

Hi,

Its not neccesary to put the virtual IP on another interface, you can
configure "cluster_interface eth0" without problems, it will not
change your real ip. You will see all the IPs with "ip a show"
command. Try configuring the virtual IP on a real interface like eth0.
Some services didn't work well with virtual interfaces (like eth0:1),
for example Asterisk.

Bye!

P.D.: Im trying to improve my english writing skills :P

2009/12/4 Will G. <li...@phaelon.net>:

> --
>
> You received this message because you are subscribed to the Google Groups "MySQL Multi Master Manager Development" group.
> To post to this group, send email to mmm-...@googlegroups.com.
> To unsubscribe from this group, send email to mmm-devel+...@googlegroups.com.
> For more options, visit this group at http://groups.google.com/group/mmm-devel?hl=en.
>
>
>



--
Lo que haría sería hacerme pasar por sordomudo y así no tendría que
hablar. Si querían decirme algo, tendrían que escribirlo en un
papelito y enseñármelo. Al final se hartarían y ya no tendría que
hablar el resto de mi vida.

[Will G.]

Thanks for the input.  I did try on eth0 as well and got the same exact results, which is why I changed to eth0:0 or eth0:1.  I figured that it might have problems with the colon, but I gave it a shot to see if it would make any difference.  It did not.

[Andrew Garner]

You certainly don't want to have a reader and writer role configured
for the same ip (which is what is causing the errors you are seeing).
You aren't required to setup a reader role, and you can read from the
writer role as well. :) So, why not just use the writer role?

~Andrew

[Will G.]

None of the documentation that I read stated anything about roles being optional or not required.  I'm not in the office until Sunday evening, but I will give this a try then and see if it fixes the issue.

I'll follow up then.  Thanks!

[Tim Soderstrom]

The only one that is required, at least in our experience with MMM 1.2 is the writer. The reader roles are optional. I believe in MMM 2.0 you can setup reader-only setups.

Typically, in a 2 server config, I setup 1 writer and 1 reader. That was the server that is not the current master could optionally be doing something useful (like running reports, backups). Even if you are not doing read/write splitting in your application, it's always nice to have that reader role there just in case.

*shrug*

Tim S.

[Will G.]

Thanks for all the input from everyone.  I was able to get this functioning properly today.  After going through all the suggestions here I came across the same issue again.  As such, I went and found the change_ip binary and manually ran it.  It turns out a perl module (Net::ARP) which was supposedly installed was not.  This was causing a failed dependency.

This brings up a question, though.  Why wasn't the system logging the failure as being in the change_ip binary, instead of just "undef"?

[Paul Graydon]

I've hit the same flumoxing problem before, when I was adding an
additional server into the fold. Took me a while to figure out it was a
forgotten dependency (I'd done it in a bit of a hurry.) Given these
modules are necessary for the correct operation of the program is there
any scope for doing a test for them on start up of the agent and logging
or failing to start the agent if it's absent?

Paul

[Walter Heck]

I addeda bug report with this: https://bugs.launchpad.net/mysql-mmm/+bug/493895

cheers,

Walter