On 06/18/2012, YesGood wrote: > The build load balancer cluster of database, in this moment is an > investigation. > the response of why are: > > - I have web server in a load balancer environment, and > - I search other system, which can offer load balancing. > - I choice database, because it's would be interesting, in a much client > environment > - and so offer best service.
The definition of "best service" may vary - what's yours? > In short of all response receive > > - build a load balance system of database is possible. > - type are: > - master-master (both offer write ), is most difficult and > complicated. That can be worse than only server. It did take Oracle a few years to write RAC and 11g, so it shouldn't be that easy :-) > - master-standby (write and only read), only one server the master > can receive write request, and other server is standby and only receive > read request. But need logic in app. What is it? The application, who acts as a "client" to the database, needs to know when it's fine to ask the "probably" outdated standby system. For example, it may be fine to retrieve information for the product page of an online shop from a standby system, who usually isn't off by more than a few seconds. However, when prices are being calculated at the paygate, your application clearly wants to have accurate pricing and so ask the write master. This is stuff which is clearly out of scope of what LVS can do. LVS is working on OSI layers 2 to 5. Your database queries are being done on higher levels and out of scope of the capabilities of LVS. In terms of databases, the MySQL proxy tries to implement a highlevel loadbalancer: MySQL proxy is an application, who looks like "the database server" to the client. It analyzes incoming SQL queries and according to one's own configuration, may send some kind of queries to one node, while other queries are being sent to a different node. However, the risk of doing it "wrong" (for the application) is at that level still fairly high. > - but build a load balance system for database, isn't best choice. > Because could offer outdated data Right? Either poor performance or outdated data. Or a hefty price tag. Maybe more than one of them. Poor Performance: If the master has to ensure that all data is replayed on the standby system, any write request may only be marked as "done" when it has been written on both servers. So in the best case (parallel IO, very rare for database replication), the slowest of both servers defines the maximum performance. Usually, your write requests in synchronous IO need to wait for the master to complete, the master in behind asks the standby to complete the write request, and when both have agreed on being "done", the master reports the write request as "done" to the client application. So basically, this setup is adding about every possible latencies. Outdated data: When the master is reporting something as "done", while it hasn't yet made it to the standby system, you may describe this as an asynchronous operation. While "usually", the time needed to process the write requests on the standby system may be very low and barely recognizable, there may also other situations occur. For example, the standby server has to rebuild a broken disk in its local RAID, and so a lot of IO performance goes to rebuilding the disk instead of the DBMS. Instead of a few milliseconds, a write request may need at least a few seconds to proceed from master to standby. If the application doesn't know when it's fine to ask the standby system and when it has to ask the master, this may also result in data loss: 1: application writes to master 2: application reads from standby before changes have been replicated from master 3: application uses the read data to compute changes, which are again written to master. Result: the changes from step 1 are lost. Hefty price tag: In clusters of in-memory databases, don't need to rely that much on disk performance, as data is being stored in RAM. Once Infiniband or Myrinet network adapters are installed for the inter-cluster-communication, the network latency decreases quite a lot (compared to Ethernet), so one may run with synchronous data replication at still a high performance. However, your 100G-Database will also require 100G of RAM - per node. And in order to reduce network latency, you may need to install a secondary network for replication of your database data, ideally using low-latency network adapters like Infiniband or Myrinet. Which is also not that cheap like standard ethernet. > - Now, are there some references, bibliography that speak about that? Hmmm. I consider this as being basic knowledge in computer science. Starting from simple physics to CAP theorem, to fallacies of distributed computing. For example: in terms of storage speed and latency, the caches in a CPU is usually fastest, then it's "usual" RAM, afterwards local disk storage, and later ethernet network. If one application needs to access a networked remote disk storage, you can simply add up two of the worst latencies and see this performance won't be that fast like with about any given local disk storage. Anders -- 1&1 Internet AG Expert Systems Architect (IT Operations) Brauerstrasse 50 v://49.721.91374.0 D-76135 Karlsruhe f://49.721.91374.225 Amtsgericht Montabaur HRB 6484 Vorstände: Henning Ahlert, Ralph Dommermuth, Matthias Ehrlich, Robert Hoffmann, Andreas Hofmann, Markus Huhn, Hans-Henning Kettler, Dr. Oliver Mauss, Jan Oetjen Aufsichtsratsvorsitzender: Michael Scheeren _______________________________________________ Please read the documentation before posting - it's available at: http://www.linuxvirtualserver.org/ LinuxVirtualServer.org mailing list - [email protected] Send requests to [email protected] or go to http://lists.graemef.net/mailman/listinfo/lvs-users
