[Openstack] [designate]Strange behavior of Designate.

Kiall Mac Innes kiall at macinnes.ie
Fri Mar 13 15:02:18 UTC 2015


Hi Yukutomi,

I believe the issue is that Percona Cluster requires an odd number of
cluster members. When you stop the B side Percona, the A side Percona is
unable to determine if the B side was stopped, of if there was a network
partition. Because of this, it stops accepting any SQL queries and
results in the behaviour you're seeing.

If you have 3x Percona's,  or 2x Percona's and 1x Galera Arbitrator[1],
the DB cluster will remain functional during the loss of any single
cluster component.

Thanks,
Kiall

[1]: http://galeracluster.com/documentation-webpages/arbitrator.html

On 13/03/15 11:24, Nobumasa Yukutomi wrote:
> Hi all,
> 
> I'm Nobumasa Yukutomi.  I'm working on Designate since last year.
> 
> We are using Designate for '20141003' Git Hub repository of Icehouse.
> 
> We have built Designate with mysql(Percona) cluster shown below.
> 
> 
>     designate.conf                  designate.conf
>       IP:xxx.xx.x.x                   IP:yyy.yy.y.y
>           A-side                          B-side
>   -----------------               -----------------
>   | designate-api |               | designate-api |
>   -----------------               -----------------
>           |                               |
>   -----------------    cluster    -----------------
>   |   rabbitMQ    |---------------|   rabbitMQ    |
>   -----------------               -----------------
>           |                               |
>   --------------------            --------------------
>   | designate-central |           | designate-central |
>   --------------------            --------------------
>           |                               |
>           |IP:xxx.xx.x.x                  |IP:yyy.yy.y.y
>   ------------------   cluster    ------------------
>   | mysql(Percona) |--------------| mysql(Percona) |
>   ------------------              ------------------
>           |                               |
>           |                               |
>   -----------------               -----------------
>   |   PowerDNS    |               |    PowerDNS    |
>   -----------------               -----------------
> 
> Let's assume some situation that mysql cluster encounters some problem. So
> let's stop B-side mysql.
> 
> The A-side mysql(active) itself continues running. But designate-api
> services of both sides stop working, even if the process of designate-api
> continues running on both sides.  User gets returned Error500(internal
> server error) from designate-api.
> 
> Here are more details.
> 
> 1. Listing domains
> For example, if a user access designate-api of A-side, designate-central
> accesses to both sides of mysql and the user experiences to succeed and
> fail to list domains every other time.
> 
> 2. Listing records
> Also, listing records fails 100% in both sides when a user accesses to
> designate-api of either A-side or B-side.
> 
> And here are my questions.
> 
> Question 1
> In designate.conf of A-side, the destination of mysql is
> A-side IP: xxx.xx.xx
> 
> In designate.conf of B-side, the destination to mysql is
> B-side IP: yyy.yy.yy
> 
> But, for some reason, designate-central accesses to both IP addresses.
> 
> I would like to know why this is happening.
> 
> Question 2
> I would like to know how to change configuration to make designate-central
> to access "only" to active-mysql, not to inactive-mysql.
> 
> Thank you in advance.
> 
> Best regards,
> 
> ---
> Nobumasa Yukutomi yukutomi at m.ieice.org
> 
> 
> 
> _______________________________________________
> Mailing list: http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack
> Post to     : openstack at lists.openstack.org
> Unsubscribe : http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack
> 

-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 473 bytes
Desc: OpenPGP digital signature
URL: <http://lists.openstack.org/pipermail/openstack/attachments/20150313/8fec4e08/attachment.sig>


More information about the Openstack mailing list