drupal replication
Aaron Johnson
article:
http://www.codership.com/content/scaling-drupal-stack-galera-part-1
Currently I have two nodes up and running with the latest version of
drupal 7 and mysql/galera 5.5.17 and it seems to be replicating
properly. I used this guide as my main reference:
http://blog.secaserver.com/2011/07/install-mysql-replication-and-cluster-using-galera/
I am able to access and login to drupal on both machines, make
changes, view changes, etc. It seems to be working perfectly.
My question is, are there any specific configuration changes that I
need to make other than the main configuration of galera or should
drupal 'just work'?
Also, what is the recommended method for syncing the actual webroot
data files for drupal? So far I have simply tar'd up the drupal files
after completing the installation and extracted on the other server
and it works. I was planning on implementing rsync over ssh via
crontab but I didn't know if anyone has a different recommendation for
this.
Henrik Ingo
Congratulations on successfully getting Galera running! Yeah, it's
simple like that, it should just work :-)
The only question is what you plan to do if there is a failure. Which
MySQL server did you use in the Drupal config? What if that node
crashes/reboots/etc?
A simple answer might be that you plan to just manually change the
Drupal config to point to the healthy MySQL node.
For a really fancy way of doing the failover, see:
http://blog.ulf-wendel.de/2011/php-and-mysql-cluster-load-balancing-without-rw-split/
henrik
> --
> You received this message because you are subscribed to the Google Groups "codership" group.
> To post to this group, send email to codersh...@googlegroups.com.
> To unsubscribe from this group, send email to codership-tea...@googlegroups.com.
> For more options, visit this group at http://groups.google.com/group/codership-team?hl=en.
>
--
henri...@avoinelama.fi
+358-40-8211286 skype: henrik.ingo irc: hingo
www.openlife.cc
My LinkedIn profile: http://www.linkedin.com/profile/view?id=9522559
Alex Yurchenko
> I see that drupal can be successfully ran on mysql/galera per this
> article:
> http://www.codership.com/content/scaling-drupal-stack-galera-part-1
>
> Currently I have two nodes up and running with the latest version of
> drupal 7 and mysql/galera 5.5.17 and it seems to be replicating
> properly. I used this guide as my main reference:
>
>
> http://blog.secaserver.com/2011/07/install-mysql-replication-and-cluster-using-galera/
>
> I am able to access and login to drupal on both machines, make
> changes, view changes, etc. It seems to be working perfectly.
>
> My question is, are there any specific configuration changes that I
> need to make other than the main configuration of galera or should
> drupal 'just work'?
Some people reported that it "just worked". Some people reported
issues. I'm not sure about its current InnoDB compatibility. Drupal 5.x
used to totally freak out on one InnoDB bug (returning duplicate key
error on a valid key), so that we even had to implement
wsrep_drupal_282555_workaround variable. I'm pretty sure that the bug is
still in InnoDB, not sure if Drupal 7 is more tolerant. So you might
need to set this variable on.
This is however where my experience with Drupal ends. Hope others may
have more substantial advice.
> Also, what is the recommended method for syncing the actual webroot
> data files for drupal? So far I have simply tar'd up the drupal files
> after completing the installation and extracted on the other server
> and it works. I was planning on implementing rsync over ssh via
> crontab but I didn't know if anyone has a different recommendation
> for
> this.
--
Alexey Yurchenko,
Codership Oy, www.codership.com
Skype: alexey.yurchenko, Phone: +358-400-516-011
Aaron Johnson
My setup is rather simple really. I have a fully redundant
implementation on every single node like this:
powerdns->nginx->php-fpm->galera/mysql
My failover is in the DNS. On each node I have to maintain different
copies of my DNS zone, each copy points to itself. When the node goes
down, DNS fails over to another nameserver thus returning the IP of a
web server that is still online. The only downside is DNS caching
getting in the way but I have TTL set to 1 sec for all records so
we'll see how it goes. Also I haven't accounted for service failure
yet. If I have problems with mysql crashing every now and then I will
have to implement a monitoring solution to restart/report when the
mysql service goes down.
This is why I am asking how I should manage the data replication
aspect. Actually I would just use drbd but varying kernel versions are
getting in the way keeping me from being able to settle on a specific
drbd version. It looks like either rsync or unison will be my option
here.
Haris Zukanovic
I tried to use the mysql_nd load balancer plugin.
Load balancing was ok, although, please correct me if I am wrong, it is
not very "smart" to use when doing writes. With Galera there is the
possibility of row-level conflict when writing to the same table on
multiple servers. Then again it depends on your application db
requirements as well...
.. but it did not failover correctly.
I believe it was because it was unable to detect as failure the "Unknown
command" which Galera returns when the node is no longer in primary
component. The node can be connected to but all SQL statements fail with
the "Unknown command".
Have I missed some configuration? Is it possible to configure to
failover correctly with Galera?
kind regards
Haris
--
--
Haris Zukanovic
Henrik Ingo
<haris.zu...@gmail.com> wrote:
> Hi Henrik,
>
>
> I tried to use the mysql_nd load balancer plugin.
Thanks for reporting. I have not actually used it myself.
> Load balancing was ok, although, please correct me if I am wrong, it is not
> very "smart" to use when doing writes. With Galera there is the possibility
> of row-level conflict when writing to the same table on multiple servers.
> Then again it depends on your application db requirements as well...
This is true. In my experience such conflicts don't happen a lot, but
of course even spurious failures can be bad if not handled correctly.
(And Drupal might not handle them correctly.)
In this case it is better to direct writes to one node and then fail
over to another when needed. This could of course still be provided by
the client library.
> .. but it did not failover correctly.
> I believe it was because it was unable to detect as failure the "Unknown
> command" which Galera returns when the node is no longer in primary
> component. The node can be connected to but all SQL statements fail with the
> "Unknown command".
> Have I missed some configuration? Is it possible to configure to failover
> correctly with Galera?
No, you're right. This is a known weakness. The problem is that this
feature was designed by Oracle developers with MySQL NDB Cluster in
mind. And even then it was quite a quick thing by them, I'm sure also
NDB might have failure modes they don't handle correctly. But in
Galera's case it is exactly what you say, the situation where the
connection succeeds but accessing InnoDB fails with "Unknown command"
is not handled correctly by the plugin.
Realistically, someone has to develop a few lines of code to fix this,
since Oracle is not supporting Galera yet. Alternatively Galera could
adapt to this and generate some other error to match what mysql_nd
expects, but that sounds like backward.
henrik
Alex Yurchenko
> Realistically, someone has to develop a few lines of code to fix
> this,
> since Oracle is not supporting Galera yet. Alternatively Galera could
> adapt to this and generate some other error to match what mysql_nd
> expects, but that sounds like backward.
Well, we are totally impartial here. We just could not find any better
error code out of existing ones and we don't want to invent anything
that is not recognized by the standard MySQL protocol. Any suggestions
about the error code to be returned in case of partitioning are welcome.
UNKNOWN COMMAND is certainly not the perfect fit.
Alex
Henrik Ingo
Actually, it would be great to return a more meaningful error code.
But what I mean is, you should not try to "retrofit" the error to look
like some error NDB might produce an mysql_nd would "understand". We
can just improve mysql_nd, it's in PHP, anyone can submit a patch.
henrik
Haris Zukanovic
In my opinion also the mysql_nd is the place to match up error codes
with failure detection.
I have no knowledge of how mysql_nd node failure detection works but it
could be made configurable as to allow instructing it to recognize
certain mysql error codes as node failure.
On the other side, in Galera, when a node fails, I would rather use any
other mysql error code that is more on the level of node failure, like
some "internal error", "storage engine failure" or similar.
"Unknown command" (if I understand it correctly) belongs to SQL level
and does not imply any kind of node failure but rather error on the user
side, error in SQL syntax or similar...
kind regards
Haris
On 08/02/12 15.18, Henrik Ingo wrote:
> On Wed, Feb 8, 2012 at 4:13 PM, Alex Yurchenko
> <alexey.y...@codership.com> wrote:
>> On 2012-02-08 15:21, Henrik Ingo wrote:
>>> Realistically, someone has to develop a few lines of code to fix this,
>>> since Oracle is not supporting Galera yet. Alternatively Galera could
>>> adapt to this and generate some other error to match what mysql_nd
>>> expects, but that sounds like backward.
>>
>> Well, we are totally impartial here. We just could not find any better error
>> code out of existing ones and we don't want to invent anything that is not
>> recognized by the standard MySQL protocol. Any suggestions about the error
>> code to be returned in case of partitioning are welcome. UNKNOWN COMMAND is
>> certainly not the perfect fit.
> Actually, it would be great to return a more meaningful error code.
> But what I mean is, you should not try to "retrofit" the error to look
> like some error NDB might produce an mysql_nd would "understand". We
> can just improve mysql_nd, it's in PHP, anyone can submit a patch.
>
> henrik
>
--
--
Haris Zukanovic
Alex Yurchenko
> Hi Alex, Henrik,
>
> In my opinion also the mysql_nd is the place to match up error codes
> with failure detection.
> I have no knowledge of how mysql_nd node failure detection works but
> it could be made configurable as to allow instructing it to recognize
> certain mysql error codes as node failure.
>
> On the other side, in Galera, when a node fails, I would rather use
> any other mysql error code that is more on the level of node failure,
> like some "internal error", "storage engine failure" or similar.
>
> "Unknown command" (if I understand it correctly) belongs to SQL level
> and does not imply any kind of node failure but rather error on the
> user side, error in SQL syntax or similar...
>
Well there is an obscure ER_READY code which does not seem to be used
anywhere. Does anybody know if using it would cause any ramifications?
Haris Zukanovic
I am not sure if that is an error code or an "ok" code? -- -- Haris Zukanovic
Alex Yurchenko
admin extremeshok.com
we'll see how it goes.[/quote]
From experience, anything less than 180 will cause the TTL to be significantly higher, as most dns servers will over write the 1sec TTL to their default value, usually 3600sec.
IF the servers are on the same network, consider a floating ip across 2 servers and i would suggest UCARP or VRRP to keep the floating ip available.
Haris Zukanovic
not easy to find any 100% suitable code for partitioning failure.
These seem to resemble the partiotioned state a little
http://dev.mysql.com/doc/refman/5.0/en/gone-away.html
--
--
Haris Zukanovic
Haris Zukanovic
all the DNS caching servers on the globe will react. They will react
differently to low TTL values that is the only sure thing.
On the other side, using multiple IP adresses per DNS name should be
handled correctly by modern browsers a used to failover. Does anyone
have experience with this?
kind regards
Haris
--
--
Haris Zukanovic
Henrik Ingo
the connection to the server. I'm not sure if it is even possible to
return those from server side, but even if it is, it would be
confusing. Otoh, for mysql_nd it would probably trigger exactly the
wanted behavior!
What we really want is an error code that says that yes, you are
connected to MySQL but the storage engine is not responding.
henrik
> --
> You received this message because you are subscribed to the Google Groups
> "codership" group.
> To post to this group, send email to codersh...@googlegroups.com.
> To unsubscribe from this group, send email to
> codership-tea...@googlegroups.com.
> For more options, visit this group at
> http://groups.google.com/group/codership-team?hl=en.
>
--
admin extremeshok.com
have 2 ip's defined, ip1 will get 50% of the traffic, ip2will get the
other 50%. If ip1 fails, 50% of the traffic will still be sent to it.
Only reliable method is with UCARP/VVRP (floating ip), (speak to your
host, they might be willing to set this up @ router level aswell)
Oli Sennhauser
We have the pleasure to announce that the FromDual Performance Monitor
for MySQL (MPM) v0.9 was released yesterday: http://bit.ly/H9L5Ms
One of the main new features is that it now collects all relevant
information for Galera Cluster (up to v2.0) and has some alerts set and
displays Graphs for Performance Monitoring.
Further many bugs were fixed, items added, graphs reniced and cleaned-up...
Have fun trying it out...
Oli
Henrik Ingo
This is great news, thanks for sharing. I have yet to see MPM (why not FPM???) in action at work but it is in the pipeline...
henrik
--
You received this message because you are subscribed to the Google Groups "codership" group.
To post to this group, send email to codership-team@googlegroups.com.
To unsubscribe from this group, send email to codership-team+unsubscribe@googlegroups.com.
For more options, visit this group at http://groups.google.com/group/codership-team?hl=en.
seppo....@codership.com
This is very welcomed release, cluster monitoring is a tad more
complicated than a single server monitoring. Having specialized tools
for this is a great improvement.
-seppo
Oli Sennhauser
Wir freuen uns, Ihnen unsere Galera Cluster für MySQL Schulung anbieten
zu können. Diese MySQL Schulung bieten wir erstmals an und sie ist
weltweit bisher einzigartig.
Die nächsten Schulungstermine sind am 23. und 24. September 2013 in
Essen (Deutschland) sowie am 17. und 18. Oktober 2013 in Zürich (Schweiz).
Galera Cluster für MySQL ist eine synchrone Multi-Master Replikation für
MySQL basierend auf der InnoDB Storage Engine. Mit dieser Lösung
erreichen Sie 99.999% Hochverfügbarkeit. Updates sind im laufenden
Betrieb möglich.
Weitere Informationen, Termine und eine Möglichkeit sich anzumelden
finden Sie hier: http://www.fromdual.com/de/mysql-schulung
Ihr FromDual Schulungsteam
----
We will have a Galera Cluster Training in Essen (Germany) and in Zurich
(Switzerland) this year.
If there is a significant need in other countries as well let us know.
Starting from 4 participants we can have local trainings...