CB Gallery Module

Deprecated: Function ereg() is deprecated in /home/templates/public_html/demo/mycommunity/j15/modules/mod_cbgallery/mod_cbgallery.php on line 380


CB Online

Planet MySQL
Planet MySQL - http://www.planetmysql.org/

  • Geographic replication with MySQL and Galera
    Introduction With the introduction of Galera replication for MySQL, Codership has, in my opinion, provide the most significant support to MySQL that the community had seen in the last tree years. Codership had filled a significant gap in MySQL replication capability, succeeding in a task where many before had failed. Not only Codership is constantly committed in doing their solution better and more solid, and they are the most friendly and helpful team I have met in years. In short chapeau to all of the guys! Great job, I am really proud to have the opportunity to discuss, interact with you. Said that, no product or code around is unmingled of errors and/or issues at different level. So also if Galera help us a lot solving many replication and architectural issues it still has some limitation that must be taken in consideration. Galera is easy to setup, especially to perform a basic setup, which will work fine for almost all basic OLTP low level and local traffic. Unfortunately I have seen many implementations that had start as basic and then become something different, in usage and very often in design. The most common mistake, from architectural point of view, I have seen is when customers starts with a simple cluster of 3 nodes all based on local network, and then given it "works so great" they decide to add one/two nodes on a geographic distributed site. This solution is not wrong "per se" but it is how it is implemented that makes the difference. The easiest way to explain what I mean and what should not be done, it is to use a real case, and describe what was implemented and how we had evolve the solution, while Codership was optimizing their product. {autotoc enabled=yes} Customer scenario The customer approaches us after few months from an activity that was focus on showing them the basics of how MySQL/Galera works. They reach us as an emergency given their cluster was totally stuck and their production site was down. In order to understand what happened we need first take a look to what the customer put up. Customer environment description The customer approaches us after few months from an activity that was focus on showing them the basics of how MySQL/Galera works. They reach us as an emergency given their cluster was totally stuck and their production site was down. In order to understand what happened we need first take a look to what the customer put up. Customer environment description The initial environment of one single application node pointing to a cluster of 3 MySQL/Galera nodes, was transformed into a 6 (or more) application nodes getting traffic from a balancer, each application nodes could write in any Data node (round robin) residing in the same geographic area (at least), but cluster was geographically distributed 3 nodes in site A, 3 nodes in site B. As result the customer navigation was jumping from one application server to another, and from one Data node to another as well. Transactions were small and relevant only for a single request. Finally each application node had a timer to clean up "old" session, the concept of OLD was relevant only to the local node and it could happen that an OLD session was in fact still on going on another application node. In short, the customer was pushing randomly traffic to both zones, using a single table for the sessions to coordinate the activities, but also purging them without any good locking mechanism: Problem description When I connect to the machine, I was not aware of the architecture as it was; I was still referring to what I had found in our history, so one Application node and a simple cluster. Takes me 5 seconds, to see that the situation was quite different. The cluster was suffering from many point of view, Flow Control was high very often, and nodes between the zones were declare dead often. Takes me some time to let the customer understand why that was not working correctly, and why the architecture was design wrongly. Mostly because they were claiming that it was working fine before (reminds me "on my machine works" doesn't it?). Discussion on what before was, how much traffic/load and so on. Finally, they redirect all the traffic to one zone only and at least the FC went down enough to have the site to work, and to give me the chance to review the settings and try to optimize it. To keep it up I had to increase the FC related variable, to modify galera parameters for nodes time out, and obviously optimize MySQL itself, and we survive a bit. For the scope of the article focus on the geographic replication, I am not to report all the review, but the part related to the subject. As said I had extended time outs and FC, but I was not happy and as such I had tested in more details what the network was really allowing to transmit.     [root@xx ~]# netperf -H -t TCP_RR -v 2 -- -b 6 -r 32K -S 256K -S 256K MIGRATED TCP REQUEST/RESPONSE TEST from ( port 0 AF_INET to () port 0 AF_INET : first burst 6 Local /Remote Socket Size Request Resp. Elapsed Trans. Send Recv Size Size Time Rate bytes Bytes bytes bytes secs. per sec   16384 87380 32768 32768 10.01 97.45 249856 249856 Alignment Offset RoundTrip Trans Throughput Local Remote Local Remote Latency Rate 10^6bits/s Send Recv Send Recv usec/Tran per sec Outbound Inbound 8 0 0 0 71830.852 97.451 25.546 25.546 <------------ 71ms     So a simple round trip for a small record of 32K takes 71 ms, what if I simulate a basic load of 1Mb?   [root@xx ~]# netperf -H -t TCP_RR -v 2 -- -b 6 -r 1M,32K -S 256K -S 256K MIGRATED TCP REQUEST/RESPONSE TEST from ( port 0 AF_INET to () port 0 AF_INET : first burst 6 Local /Remote Socket Size Request Resp. Elapsed Trans. Send Recv Size Size Time Rate bytes Bytes bytes bytes secs. per sec   16384 87380 1048576 32768 10.00 2.70 249856 249856 Alignment Offset RoundTrip Trans Throughput Local Remote Local Remote Latency Rate 10^6bits/s Send Recv Send Recv usec/Tran per sec Outbound Inbound 8 0 0 0 2592709.047 2.700 22.648 0.708 <-- we have 2592.709047 ms latency       Note, to understand better what was going on and why I use this method to evaluate the network read my other article (Effective way to check the network connection performance, when using replication geographically distributed) What we had to do With this kind of connectivity, it is very unluckily that we can have the galera replication working correctly. Not even if we keep only one site as master and the other as stand by. The way the nodes communicate and validate the writesets will be too demanding. See the below diagram from Codership to understand why   The only alternative to this is to use asynchronous connection and set two nodes, one for each site in master-master mode: Setup a master-master, means that we loose the automatic replication shift from one node to another. That is it, this solution while fix the latency problem because use asynchronous replication, it does imply that in case of crash of one of the two nodes connected, you must manually move the replication to another node. How to set it up how to fix when it breaks Setting up asynchronous replication in a galera cluster is quite easy. Assuming you have two nodes connected as master master (A1 B1) and assuming the only active was A1 and that it crashes, the only thing you need to do is to check on B1 for:   +----------------------+-----------+ | Variable_name | Value | +----------------------+-----------+ | wsrep_last_committed | 221463896 | +----------------------+-----------+       In the status variables, then look on the node you had choose as master say A2, for the binary log containing the   Xid = 221463896     And issue the command CHANGE MASTER with the coordinates you will find there. Then on A2 set the node as slave of the B1 using the Master coordinates from that node. The procedure is simple and obviously worked decently, given the situation. Customer was obviously not happy because they would like to have the two cluster in perfectly sync, but that was at least good enough to keep the site working efficiently. Not only after we set it up, we had at least two incidents to production, and we had successfully able to fail over to DR and then Failback with less then few seconds of service interruption. Anyhow our friends in Codership had already release the new version of Galera (3.x), working on MySQL 5.6. So while the customer was refining and correcting a lot of issues their side, mainly in the code and how the application was using the common table. I had review, test and crashed MySQL 5.6/Galera3. Galera 3.0 comes with some interesting new enhancement, see for an overview http://www.slideshare.net/Severalnines/webinar-slides-27249453. At the moment of writing Seppo is close to deliver the speech about the new features in Galera 4 at Percona Live London 2014. (http://www.percona.com/live/london-2014/sessions/galera-cluster-new-features) Galera 3.X group replication and how this can change everything. In Galera 3, the introduction of the segment concept basically isolate/identify a group of data nodes inside a cluster. The meaning is that any node with the same segment value will communicate extensively to each other, while intra-segments they elect one node for each segment as communication channel:   Quorum calculation is also taken in to account the segments allocation. In the presentation I have linked here there is mention that using segments will allow managing WAN latency of 100-300 ms. Given I am a skeptical, I decide to perform extensive tests, and see/identify what it is really possible to accomplish. Investigations I did several tests, involving many parameters in galera, but at the end I had two main actors I was playing with, the max_packet size and gcache pagesize. All the others ones changed had prove to be stable and efficient, below the settings I had used. How to test the problem I have setup 8 different tests: 1) simple insert on 1 node from 3 apps 2) simple insert on 1 node for segment on DR only one app on production 2 3) simple insert on 1 node from 3 apps GALERA PACK larger 4) simple insert on 1 node for on DR only one app on production 2 GALERA PACK larger 5) simple insert on 1 node from 3 apps BUT with WAN connection 6) simple insert on 1 node for on DR only one app on production 2 BUT with WAN connection 7) simple insert on 1 node from 3 apps BUT with WAN connection AND GALERA PACK larger 8) simple insert on 1 node on DR only one app on production 2 BUT with WAN connection AND GALERA PACK larger   Each test was using OLTP approach, with 5 main tables and 6 child tables with the following structure:   tbtest1 | CREATE TABLE `tbtest1` ( `autoInc` bigint(11) NOT NULL AUTO_INCREMENT, `a` int(11) NOT NULL, `uuid` char(36) COLLATE utf8_bin NOT NULL, `b` varchar(100) COLLATE utf8_bin NOT NULL, `c` char(200) COLLATE utf8_bin NOT NULL, `counter` bigint(20) DEFAULT NULL, `time` timestamp NOT NULL DEFAULT CURRENT_TIMESTAMP ON UPDATE CURRENT_TIMESTAMP, `partitionid` int(11) NOT NULL DEFAULT '0', `date` date NOT NULL, `strrecordtype` char(3) COLLATE utf8_bin DEFAULT NULL, PRIMARY KEY (`autoInc`,`partitionid`), KEY `IDX_a` (`a`), KEY `IDX_uuid` (`uuid`) ) ENGINE=InnoDB AUTO_INCREMENT=3474631 DEFAULT CHARSET=utf8 COLLATE=utf8_bin |   CREATE TABLE: CREATE TABLE `tbtest_child1` ( `a` int(11) NOT NULL, `bb` int(11) NOT NULL AUTO_INCREMENT, `date` date NOT NULL, `partitionid` int(11) NOT NULL DEFAULT '0', `stroperation` varchar(254) COLLATE utf8_bin DEFAULT NULL, `time` timestamp NOT NULL DEFAULT CURRENT_TIMESTAMP ON UPDATE CURRENT_TIMESTAMP, PRIMARY KEY (`a`,`bb`), UNIQUE KEY `bb` (`bb`) ) ENGINE=InnoDB AUTO_INCREMENT=36289 DEFAULT CHARSET=utf8 COLLATE=utf8_bin 1 row IN SET (0.00 sec)       Using 3 application nodes, each was having 8 children treads for a total of 24 threads writing on the cluster. The tests performed from 1 to 4 where done as baseline so NO WAN network simulation. When I mention Galera pack larger I refer specifically to: gcs.max_packet_size This value is "All writesets exceeding that size will be fragmented." And it is set by default to 32Kb, which means anything larger that will be fragmented in side galera. My understanding is that writeset package exceeding that dimension will be split in smaller packages. But given the dimension of 32K, or even less is significantly larger then the network frame dimension, the packet fragmentation will take place in any case, but at lower level (network). My reasoning here was, why I should want to do that, if I already have frame fragmentation at network (TCP/IP) level? I may get the meaning of the parameter wrong, but if not is worth a try. On this regards I had also optimize the machine network layer: net.core.optmem_max = 40960 net.core.rmem_max = 16777216 net.core.wmem_max = 16777216 net.core.rmem_default = 16777216 net.core.wmem_default = 16777216 net.ipv4.tcp_rmem = 4096 87380 16777216 net.ipv4.tcp_wmem = 4096 65536 16777216 net.core.netdev_max_backlog = 50000 net.ipv4.tcp_max_syn_backlog = 30000 net.ipv4.tcp_congestion_control=htcp net.ipv4.tcp_mtu_probing=1 net.ipv4.tcp_max_tw_buckets = 2000000 net.ipv4.tcp_tw_reuse = 1 net.ipv4.tcp_fin_timeout = 30 net.ipv4.tcp_slow_start_after_idle = 0 I run the tests on 6 data nodes using 2 segments, in virtualized environment, 8 core 8GB raid 10 6 10k RPM disks, CentOS 6. On purpose I had skip HAProxy and prefer to pint directly on the node I had defined. The applications were closing and opening connection at each transaction to emulate the customer behavior. When simulating the wan network I had set a final total latency of :   root@galera1h1n5 galera56N1]# netperf -H -t TCP_RR -v 2 -- -b 6 -r 120K,64K -S 156K -S 156K MIGRATED TCP REQUEST/RESPONSE TEST from ( port 0 AF_INET to () port 0 AF_INET : first burst 6 Local /Remote Socket Size Request Resp. Elapsed Trans. Send Recv Size Size Time Rate bytes Bytes bytes bytes secs. per sec   65536 87380 122880 65536 10.00 1.90 319488 319488 Alignment Offset RoundTrip Trans Throughput Local Remote Local Remote Latency Rate 10^6bits/s Send Recv Send Recv usec/Tran per sec Outbound Inbound 8 0 0 0 3684481.420 1.900 1.868 0.996 <----- 3684.481 ms     With packet reordering 15-20%. Just for the good of comparison a PING whould had report: [root@galera1h1n5 galera56N1]# ping -M do -s 1472 -c 3 PING ( 1472(1500) bytes of data. 1480 bytes from icmp_seq=1 ttl=64 time=403 ms 1480 bytes from icmp_seq=2 ttl=64 time=389 ms 1480 bytes from icmp_seq=3 ttl=64 time=410 ms     So ~400 ms for 1427 (1500) bytes.   With all this in place, I have started to roll the ball and collected my data. To notice that I have run each set of test at least 5 times, to validate the data collected, and data was clean, refresh and InnoDB BP reload at any test. Before reaching the last set of tests (the final 2 sets) I had run a total amount of 64 variants of the tests, sometime crashing galera, sometime getting so bad performance that it was obvious that would not be usable in production, and so on. Anyhow, I was more focus on the replication performance/behavior than on what MySQL/Innodb was doing given I was not looking for an ultra-fine tuning at that level, actually some imperfections had fit my purpose better. Related issues Initially I was not using an optimize network settings, and as soon as I reach the first time the tests 7-8 I had issues, in short the test 7 was taking 4 time longer then test 5 (his twin), and in some cases it was so bad that I had to stop it. But once the network was set up correctly most of the issue disappears. Results Who wins? There is not a single winner; all the tests shows that there is the need to carefully pick the right solution for the job. But these two sets of tests, and settings had proven to be stable and better performing then all the others in my simulation:   This first image show the set of tests perform with the gcahe page set to a lower value of 32Mb and more instances 4.   This second one shows the test with a larger page of 250Mb and only 2 instances. I did not include the starting test where the page/instance was set by defaults, because it was providing less performance. Comparing the two, we can see that there is a different behavior between the tests done on a local network and the ones using the WAN. In the case of a LAN where the cluster is less limited in the performance at network level, the use of more smaller gcache pages with more instances, had allow the cluster and MySQL to insert ~5700-5300 row/sec. The use of a large gcache page and only 2 instances, on the other side see the drop of the performance to ~5500-4950 row/sec. The difference is not significant with this traffic, but is interesting t note that it exists and is consistent on all the tests. My side, this means we have something that add a cost, significant cost when galera need to access a less number of gcache page. Given this is a memory access I am oriented to think there is a mutex that prevent the usage of the single page/resource. On the other hand the Large gcache page, seems providing better support in the case of a distribute cluster. I assume that given the transmission is slowed down by the network, galera/MySQL is able to better utilize the less instances of the gcache memory pages. Never the less, the large gcache with less instances, had be less effective when inserting in multiple nodes then the small gcache page with more instances and larger gcs.max_packet_size. But that is not all. When using larger packet size (gcs.max_packet_size), I was consistently able to complete the tests in less time when I was using a geographically distributed cluster, large gcache page and multiple nodes writing. While when the cluster was performing locally, the small (standard) gcs.max_packet_size was working better. Let us navigate the results. Segments distribution The first test I have done is to be sure that the segments where working as expected. The cluster was compose by 2 segments, each segment 3 nodes. Segment 1 nodes IP ending with: 5,21,23 Segment 2 nodes IP ending with 2,23,33     Local cluster(same network) Display paused 19.1Mb 38.1Mb 57.2Mb 76.3Mb 95.4Mb └───────────────┴────────────────┴────────┴────────────────┴──────────────── <=> 1.65GB 76.8Kb 63.9Kb 67.1Kb <=> 1.63GB 63.8Kb 51.8Kb 55.2Kb <=> 1.58GB 31.8Kb 26.2Kb 28.5Kb <---- <=> 30.8MB 19.3Kb 15.4Kb 16.2Kb <=> 270KB 848b 1.81Kb 1.74Kb     Display paused 19.1Mb 38.1Mb 57.2Mb 76.3Mb 95.4Mb └────────────────┴────────────────┴────────┴────────────────┴──────────────── <=> 1.70GB 70.7Kb 71.6Kb 67.5Kb <=> 83.4MB 44.9Kb 43.3Kb 40.9Kb <=> 31.8MB 15.6Kb 16.9Kb 16.5Kb <---- ?? <=> 32.1MB 15.6Kb 16.8Kb 16.3Kb <---- ?? <=> 269KB 848b 1.34Kb 1.36Kb     Display paused 19.1Mb 38.1Mb 57.2Mb 76.3Mb 95.4Mb └────────────────┴────────────────┴────────┴────────────────┴──────────────── <=> 1.67GB 56.5Kb 58.3Kb 55.7Kb <=> 83.4MB 44.7Kb 43.3Kb 41.5Kb <=> 31.7MB 19.6Kb 17.6Kb 17.2Kb <---- ?? <=> 273KB 848b 1.98Kb 1.89Kb <=> 269KB 848b 1.85Kb 1.72Kb   Display paused 19.1Mb 38.1Mb 57.2Mb 76.3Mb 95.4Mb └───────────────┴───────────────┴─────────┴──────────────┴──────────────── <=> 1.70GB 71.2Kb 71.2Kb 67.6Kb <=> 111MB 58.2Kb 57.6Kb 54.6Kb <=> 31.7MB 20.2Kb 17.7Kb 16.9Kb <---- ?? <=> 30.8MB 15.6Kb 17.3Kb 16.5Kb <---- ?? <=> 31.8MB 15.6Kb 16.9Kb 16.5Kb <---- ??   Display paused 19.1Mb 38.1Mb 57.2Mb 76.3Mb 95.4Mb ───────────────┴───────────────┴────────────────────────┴──────────────── <=> 1.65GB 71.2Kb 71.2Kb 68.3Kb <=> 1.60GB 43.7Kb 43.4Kb 41.7Kb <=> 1.62GB 28.1Kb 29.6Kb 28.3Kb <---- <=> 269KB 848b 1.85Kb 1.76Kb <=> 269KB 848b 1.34Kb 1.36Kb   Display paused 19.1Mb 38.1Mb 57.2Mb 76.3Mb 95.4Mb └───────────────┴────────────────┴───────┴────────────────┴──────────────── <=> 111MB 58.8Kb 57.6Kb 55.4Kb <=> 1.65GB 43.7Kb 43.3Kb 41.9Kb <=> 32.1MB 15.6Kb 16.8Kb 16.5Kb <---- ?? <=> 273KB 848b 1.98Kb 1.89Kb <=> 274KB 848b 1.78Kb 1.73Kb     Wan distributed cluster Display paused 19.1Mb 38.1Mb 57.2Mb 76.3Mb 95.4Mb └───────────────┴───────────┴─────────┴────────────────┴────────────────────── <=> 1.71GB 30.2Kb 31.3Kb 31.0Kb <=> 1.71GB 28.1Kb 30.4Kb 30.4Kb <=> 1.61GB 15.1Kb 16.3Kb 16.6Kb <---- <=> 682KB 1.19Kb 1.91Kb 1.77Kb <=> 8.83MB 3.91Kb 1.77Kb 1.87Kb <---- ?? <=> 5.05KB 0b 0b 572b <=> 5.91KB 0b 0b 535b   Display paused 19.1Mb 38.1Mb 57.2Mb 76.3Mb 95.4Mb └───────────────┴────────────┴────────┴─────────────────┴────────────────────── <=> 194MB 28.7Kb 31.2Kb 31.3Kb <=> 1.76GB 28.5Kb 30.6Kb 30.4Kb <=> 73.8MB 15.6Kb 17.1Kb 17.1Kb <---- ?? <=> 298KB 1.86Kb 2.00Kb 1.91Kb <=> 5.83MB 2.06Kb 1.53Kb 1.42Kb <---- ?? <=> 351KB 1.53Kb 1.34Kb 1.41Kb     Display paused 19.1Mb 38.1Mb 57.2Mb 76.3Mb 95.4Mb └───────────────┴────────────┴────────┴─────────────────┴────────────────────── <=> 1.76GB 28.7Kb 31.3Kb 31.1Kb <=> 192MB 28.7Kb 31.2Kb 31.3Kb <=> 53.3MB 17.8Kb 17.9Kb 17.7Kb <---- ?? <=> 1.23MB 3.93Kb 2.01Kb 2.31Kb <=> 323KB 528b 1.77Kb 1.81Kb <=> 354KB 1.28Kb 1.32Kb 1.38Kb     Display paused 19.1Mb 38.1Mb 57.2Mb 76.3Mb 95.4Mb └───────────────┴───────────┴─────────┴────────────────┴────────────────────── <=> 1.65GB 28.5Kb 30.9Kb 31.2Kb <=> 1.65GB 27.7Kb 30.5Kb 31.0Kb <=> 1.64GB 15.1Kb 16.3Kb 16.6Kb <---- <=> 323KB 528b 1.77Kb 1.81Kb <=> 5.88MB 2.06Kb 1.53Kb 1.46Kb <---- ??   Display paused 19.1Mb 38.1Mb 57.2Mb 76.3Mb 95.4Mb └───────────────┴────────────┴────────┴─────────────────┴────────────────────── <=> 118MB 29.8Kb 31.5Kb 31.5Kb <=> 1.70GB 29.5Kb 30.8Kb 31.2Kb <=> 74.0MB 15.4Kb 16.9Kb 17.0Kb <----?? <=> 1.22MB 3.31Kb 1.85Kb 2.27Kb <=> 8.96MB 3.40Kb 1.67Kb 1.84Kb <---- ?? <=> 359KB 1.47Kb 1.47Kb 1.36Kb   Display paused 19.1Mb 38.1Mb 57.2Mb 76.3Mb 95.4Mb └───────────────┴────────────┴────────┴─────────────────┴────────────────────── <=> 118MB 28.1Kb 31.5Kb 31.4Kb <=> 1.70GB 27.5Kb 30.2Kb 30.7Kb <=> 53.3MB 17.8Kb 17.9Kb 17.7Kb <----?? <=> 298KB 1.86Kb 2.00Kb 1.91Kb <=> 686KB 1.03Kb 1.96Kb 1.78Kb <=> 370KB 1.41Kb 1.44Kb 1.42Kb       Apparently all was working fine, and if you notice the nodes 5 -23 and 5-2 seems to work as bridge between the segments. But if you look carefully (I had point the cases with <---- ??), you will see that there is additional traffic going on, for instance in the first set we have nodes 33-21 exchanging data for 32Mb, and in the second set (wan) even more we have node 23-21 exchanging 73Mb. It seems nothing, but instead it means there is an exchange of some type. What kind of traffic is going on between SOME nodes? I said SOME on purpose, because other nodes are not generating this that I consider an anomaly. May be this is by design, if so I would like to know, and would like to know why. Anyhow a side from this, most of the exchange is actually floating as expected.   More inside the replication As mention before, the whole exercise was to identify if and if yes which is best settings to use for the cluster working in geographically distributed environment. In relation to that the tests that are more relevant are the number 6 and 8: 6) simple insert on 1 node for on DR only one app on production 2 BUT with WAN connection 8) simple insert on 1 node on DR only one app on production 2 BUT with WAN connection AND GALERA PACK larger Comparing the differences existing between the gcache.keep_pages_size and page_size settings as well. Test6 Test8 Reviewing the two graphs above, related to the Replication queue, we can see that both tests do not report Flow Control action. In the case of Test6 the receiving and sending queue had some spikes, that were not present in Test8, meaning the two queues were processed more efficiently when the max_packet_size is larger. To note is that the wsrep_evs_repl_latency in Test8 is higher, as such the messages seems takes longer to be dispatched, but at the end the performance are better.   Test6 Test8 Reviewing the graphs related to Writeset dimension and the Netstat, we can notice that the size of the writesets are larger in the test with default max_packet_size, also network traffic results to be higher. I was surprise about that and I had repeat the tests even more times. At the end magnifying the information related to the transmitted packet, we can notice that when using larger max_packet_size, the distance between received and transmitted is less. Test6 Test8 Given in this test we have writes going on two nodes, my conclusion is that the network layer was able to optimize the data transmission, reducing the number of vectors (frames) and as such reducing the overhead.   Test6 Test8 To complete the review related to the galera replication, let take a look to the parallelization efficiency graphs. Here the differences are more evident. The apply window (Average distance between highest and lowest concurrently applied seqno) when using default max_packet_size is definitely higher, as well the wsrep_commit_window (Average distance between highest and lowest concurrently committed seqno). Also the wsrep_cert_deps_distance (Average distance between highest and lowest seqno value that can be possibly applied in parallel, potential degree of parallelization), in the first case is steady while with larger max_packet_size it is going down. I was oriented to read this as an optimize way to apply and commit the incoming data. Test6 Test8   Reviewing the Writeset_byte graphs we can note that while the bytes replicated remain very close between Test6 and Test8, the received are quite larger in the case of smaller/default max_packet_size. So the node was by the fact receiving less data in Test8, keeping constant the same amount of data from application. Test6 Test8   Analyzing the process information the Test6 (default max_packet_size) has more major page fault then Test8, and both system time and user time are larger in Test6. The meaning of this is more I/Operations The differences are not huge, but they are consistent through the different number of tests.   Conclusions? I had collect and still collecting a lot of additional data, but for the scope of this article focus on the network and replication side, I prefer to stop. There is not A conclusion about the whole MySQL/Galera setup, but let me say that I am strongly suggesting to do not use a monolithic setup for all cases. Instead adapt the configuration following the architecture you are implementing.   So far and from the tests I have done, I can say that: Cluster implemented in a single site with very good connectivity and using MySQL/Galera for HA or ad write distribute platform: Use multiple gcache.keep_pages_size (I had relate the number to the number of cores but I don't see any benefit to go above 8 instance at the moment) Use gcache.page_size never less then 32Mb no more 256Mb total Use small gcs.max_packet_size 32K Cluster implemented in a single site with geographic distributed site and using MySQL/Galera on second site for HA only: Use single or two gcache.keep_pages_size Use default gcache.page_size or little bit larger like 256M Use larger gcs.max_packet_size 2097152K   In the final tests I have being using the two following configurations, and they had work great also with significant load, not only for the tests but also when we had implement them at the customer site, using the same load and operation that was crashing the system with Galera 2.x or with other Galera 3.x configurations. Configuration used for local cluster:   wsrep_provider_options = "gmcast.segment=1|2;socket.ssl_compression=no;gcache.keep_pages_size=2;gcache.page_size=125M; gcache.size=5024M;evs.send_window=512;evs.user_send_window=512; evs.use_aggregate = true; gcs.fc_factor = 1;  gcs.fc_limit = 32; gcs.max_packet_size = 32768;gcs.fc_debug = 0; evs.inactive_check_period = PT1S;  evs.inactive_timeout = PT15S;evs.suspect_timeout = PT5S; evs.stats_report_period = PT1M;"     Configuration used for geographically distributed DR:   wsrep_provider_options = "gmcast.segment=1|2;socket.ssl_compression=no;gcache.keep_pages_size=4;gcache.page_size=64M; gcache.size=5024M;evs.send_window=1024;evs.user_send_window=1024; evs.use_aggregate = true; gcs.fc_factor = 1;  gcs.fc_limit = 260; gcs.max_packet_size = 2097152;gcs.fc_debug = 0; evs.inactive_check_period = PT30S; evs.inactive_timeout = PT1M;evs.suspect_timeout = PT1M; evs.stats_report_period = PT3M;"       Please let me know if in you will experience different results, and how/why.    Great MySQL .... & Galera to all.

  • Aurora for MySQL is coming
    I am excited about Aurora for MySQL. While there aren't many details, I have two conclusions from the information that is available. First, many talented people did great work on this. Second, many customers want the features it provides and some of these features are otherwise unavailable unless you are web-scale and can afford a team of automation experts. This is a big deal and good for the MySQL community. I am not just writing this to boost my priority on the Aurora preview signup list.I don't think it matters whether Aurora has better performance. The big story is much better availability and manageability without having to hire an expert MySQL operations team. The limiting factor might be cost but that depends on whether you come from the land where everything is free or from a commercial DBMS. And even in the land of free, the cost for an operations team is large.SoapboxBefore describing what I learned about it I have a short editorial.Is Amazon the reason we need AGPL? It isn't clear to me that they improve upstream MySQL. They do benefit the community by making it easier to run MySQL in the cloud. But I don't see them in the community. Which means I also don't see their developers in the community and who wants to disappear while working on mostly open-source?Their marketing leads with up to 5X faster than MySQL which is translated by the tech press into 5X faster than MySQL. When I signed up for an Aurora preview the response email from Amazon also used the 5X faster than MySQL claim. I prefer up to 5X faster than MySQL.In the video from AWS re:Invent 2014 James Hamilton makes some interesting claims.I am not sure he heard about InnoDB based on this statement -- Just doing a state of the art storage engine would have been worth doing. Take Jim Gray's black book on transactions, implement it, I would be happy. Someone can tell him to be happy.In big print -- 3X write performance, 5X read performance. In small print -- sysbench. It will take time to determine whether similar performance & availability can be had elsewhere at a similar cost.In big print -- 400X less lag, 2 seconds vs 5 milliseconds. I doubt this. The slide also stated -- synchronous multi-DC replication. I don't see how that is possible except within a datacenter given network latency. Other content from Amazon claims this is async replication. But then Mr. Hamilton stated that everything is there, transactions are not lost were two data centers to instantly disappear. Again, that requires sync replication. This is confusing and I am surprised his claims don't match the other documentation from Amazon.It can fix torn pages. InnoDB does this for writes in progress during a crash. I assume Aurora can also do this for pages written a long time ago and that would be a big deal.InformationWhat is Aurora? I don't know and we might never find out. I assume it is a completely new storage engine rather than a new IO layer under InnoDB. I encourage people to read the details page, FAQ, slides and pricing guide. The response from Clustrix is also useful. At least one answer on Quora is excellent.The big deal is that the database is replicated 6X using 3 availability zones (AZs). I assume this means it uses 2 storage clusters per AZ. Documentation from Amazon states this is done using async replication and (committed) writes are available within a few milliseconds or 10s of milliseconds. I assume this is only for Aurora read replicas in the same AZ as the master. Network latency will make that impossible for some remote AZs.  In the presentation at AWS re:Invent there are claims that the replication is synchronous. That is confusing.For now I will assume that Aurora does async replication to the two remote AZs and the non-primary storage cluster in the primary AZ -- which means that 5 of the 6 copies are updated via async replication. If this is true, then an outage at the primary storage cluster can mean that recent commits are lost. It would be great if someone were to make this clear. My preferred solution would be sync replication within the primary AZ to maintain copies in 2 storage clusters, and then async replication to the 4 copies in the 2 remote AZs. We will soon have multiple solutions in the MySQL community that can do sync replication within a datacenter and async replication elsewhere -- Galera, upstream and lossless semisync. But Aurora is much easier to deploy than the alternatives. My standard question is what commit rate can be sustained when all updates are to the same row? Sync replication with cross-country network round trips makes that slow.The presentation also claimed this was mostly drop-in compatible. I am interested in compatibility with InnoDB. What are the semantics for cursor isolation? PostgreSQL, InnoDB and Oracle all do snapshot isolation with different semantics for writes. PostgreSQL has excellent documentation to describe the behavior.Does Aurora support clustered indexes? What is the max size of an index key?How are large columns supported? Is data always inline?How is multi-versioning implemented? InnoDB usually does updates in place so there isn't much work for purge to do except for deletes and updates to secondary index columns. Does this use pessimistic or optimistic concurrency control?Does this support partitioning?What is the block size for reads?Does this use compression?FeaturesThe brief description of features is very interesting. I will summarize that here. The features sound great and I expect them to get a lot of customers.Unplanned failover to an Aurora read replica takes a few minutes. Unplanned failover to a new instance can take up to 15 minutes. This happens for customers who aren't spending money on Aurora read replicas. This is another feature that will make Aurora very popular. While it will be nice to make failover faster, the big deal is that they provide this. The usual MySQL deployment required some do-it-yourself effort to get something similar.Storage uses SSD. I assume this is based on EBS. They do background scrubbing to detect and correct corrupt pages. Storage grows in 10G increments. You don't have to provision for a fixed amount of GB or TB, they will grow as needed up to 64T (or 64T/table). I am not sure I would want 64T in one instance, but it can make it easy to archive data in place. Also automatic growth to such large database sizes will make it much easier for deployments to avoid sharding especially when an instance has many TB of cold data.There are interesting features for point-in-time recovery, incremental backup and snapshots. This is integrated with S3. Incremental backups make it affordable to archive data in place as you don't do full backups for data that doesn't change. But I don't understand all of their backup options. Database is replicated 2 times within 3 AZs so there are 6 copies. Up to 2 copies can be lost and writes are still possible. Up to 3 copies can be lost and reads are still possible. I assume that by copies can be lost they mean storage clusters can be lost. Automatic recovery here is another big deal.The buffer pool survives mysqld process restart. I wonder if that is only true for planned restart. Regardless, this is a very useful feature for IO-bound workloads when it is important to have a warm cache. Percona used to have a patch for this with InnoDB.Replication is supported in two ways -- via Aurora (at storage level) and MySQL (binlog). My bet is that Aurora replication will be most popular but some people will use MySQL replication to replicas with locally attached storage to save money. They claim much less lag with Aurora and I agree there will be less but I am not sure there will be 400X less. However, they avoid some overhead on commit by not using the binlog and they avoid a lot of complexity by not requiring MySQL replication on the master or slave. I assume that Aurora replication ships deltas rather than page images to be efficient on the network.CostCost comparisons will be interesting. I am very uncertain about my estimates here as I don't have much experience with prices on AWS or for normal sized datacenter deployments limited to a few servers. I estimate a 3 year cost of $568,814 for a high-end Aurora deployment: largest servers, 1 master, 1 replica, backup and storage. It will be interesting to compare this to non-AWS hardware because you need to account for features that Aurora provides and for the extra availability of the Aurora storage solution. I used 3TB and 10k IOPs from storage because that can be provided easily by a high-end PCIe flash device, but that also assumes a very busy server.Reserved db.r3.8xlarge (32 vCPUs, 244GiB RAM) for 2 servers is $115,682 over 3 years50TB of backup at 10 cents/GB/month is $53,100 over 3 years3TB of storage and 10,000 IOPs per server is $400,032 for 2 servers over 3 years. But I am not sure if the storage cost includes IO done to all AZs to maintain the 6 database copies. In that case, the storage cost might be higher.

  • Sys Schema for MySQL 5.6 and MySQL 5.7
    Performance Schema (P_S) has been available since MySQL 5.5, more than 4 years ago. It is still difficult to see production servers with P_S enabled, even with MySQL 5.6 where the feature is enabled by default. There have been several complaints like the overhead, that the fix is a work in progress, and the ease of use. 52 tables to query and 31 configuration variables is enough to scare people.There is a solution for the second problem, the usability. It’s name is “sys schema“. It is a collection of views, functions and procedures to make P_S more user friendly.InstallationIf you are a MySQL Workbench user the installation is pretty easy because sys schema is already included. You just need to install it. Click on “Performance – Performance Reports” and there you will find the “Install Helper” button that will install sys schema.If you don’t use MySQL Workbench you need to download sys_56.sql or sys_57.sql (depends if you use 5.6 or 5.7) from the github repository. Then, just import the sql file as usual:mysql -u root -p < ./sys_56.sqlUsageAfter the import, you will have a new “sys” schema with some very descriptive table names. Let’s see an example. Do you want to know what tables are using most of our InnoDB buffer memory? Easy:mysql> select * from sys.innodb_buffer_stats_by_table; +---------------+--------------------+-----------+-----------+-------+--------------+-----------+-------------+ | object_schema | object_name | allocated | data | pages | pages_hashed | pages_old | rows_cached | +---------------+--------------------+-----------+-----------+-------+--------------+-----------+-------------+ | test | t | 63.61 MiB | 58.06 MiB | 4071 | 4071 | 4071 | 2101222 | | InnoDB System | SYS_FOREIGN | 32.00 KiB | 0 bytes | 2 | 2 | 2 | 0 | | InnoDB System | SYS_TABLES | 32.00 KiB | 1.11 KiB | 2 | 2 | 2 | 10 | | InnoDB System | SYS_COLUMNS | 16.00 KiB | 4.68 KiB | 1 | 1 | 1 | 71 | | InnoDB System | SYS_DATAFILES | 16.00 KiB | 324 bytes | 1 | 1 | 1 | 6 | | InnoDB System | SYS_FIELDS | 16.00 KiB | 722 bytes | 1 | 1 | 1 | 17 | | InnoDB System | SYS_INDEXES | 16.00 KiB | 836 bytes | 1 | 1 | 1 | 12 | | InnoDB System | SYS_TABLESPACES | 16.00 KiB | 318 bytes | 1 | 1 | 1 | 6 | | mysql | innodb_index_stats | 16.00 KiB | 274 bytes | 1 | 1 | 1 | 3 | | mysql | innodb_table_stats | 16.00 KiB | 53 bytes | 1 | 1 | 1 | 1 | +---------------+--------------------+-----------+-----------+-------+--------------+-----------+-------------+Pretty easy and useful, right? You can also get what is the database using more memory in the buffer pool querying innodb_buffer_stats_by_schema.For each table there is another similar ones that it’s name starts with x$. For example, you have user_summary_by_file_io and x$user_summary_by_file_io. The difference is that the first table has a human readable output values while the second one has the real values. Let’s see an example:mysql> select * from sys.user_summary_by_file_io; +------------+-------+------------+ | user | ios | io_latency | +------------+-------+------------+ | root | 19514 | 2.87 s | | background | 5916 | 1.91 s | +------------+-------+------------+ 2 rows in set (0.00 sec) mysql> select * from sys.x$user_summary_by_file_io; +------------+-------+---------------+ | user | ios | io_latency | +------------+-------+---------------+ | root | 19514 | 2871847094292 | | background | 5916 | 1905079715132 | +------------+-------+---------------+For humans, at least for me, it is easier to read seconds rather than picoseconds There are multiple tables with very descriptive names.– io_by_thread_by_latency – schema_unused_indexes – statements_with_temp_tables – statements_with_errors_or_warnings – user_summary_by_statement_type – waits_by_host_by_latency …There are lot more, and they are explained with examples in project’s README file.ConfigurationOn the MySQL side nothing special is needed. Just enable performance_schema:performance_schema="on"sys schema also provides some procedures to enable/disable some features. For example:– ps_setup_enable_background_threads – ps_setup_enable_consumers – ps_setup_enable_instrument and so on…We also have the same procedures with “disable”. After you have made the changes you can save them calling ps_setup_save() and reload it later on if you want calling ps_setup_reload_saved(). If you want to reset the configuration to default values just call ps_setup_reset_to_default().For example, we can check that some consumers are disabled. It is possible to enable them and save the configuration:mysql> CALL sys.ps_setup_show_disabled_consumers(); +--------------------------------+ | disabled_consumers | +--------------------------------+ | events_stages_current | | events_stages_history | | events_stages_history_long | | events_statements_history | | events_statements_history_long | | events_waits_current | | events_waits_history | | events_waits_history_long | +--------------------------------+ mysql> CALL sys.ps_setup_enable_consumers('events'); +---------------------+ | summary | +---------------------+ | Enabled 8 consumers | +---------------------+ mysql> CALL sys.ps_setup_show_disabled_consumers(); Empty set (0.00 sec) mysql> CALL sys.ps_setup_save(TRUE);ConclusionPerformance Schema is very useful when we want to know what is happening inside the database. It is getting more features with each new GA and will probably be the single point of information in near future. Now thanks to sys schema it is also easy to use.The post Sys Schema for MySQL 5.6 and MySQL 5.7 appeared first on MySQL Performance Blog.

  • Logging with MySQL: Error-Logging to Syslog & EventLog
    You’ve already read it in What’s new in 5.7 (So Far) — the MySQL server now has new-and-improved supported for syslog (on unix-like systems) and EventLog (on Windows). In the next few paragraphs, we’ll take a look at what they are, what has changed, and how they can make your life easier. The MySQL server supplies information in two main ways: The client will receive a reply to every statement. If everything goes right, then we’ll see a simple OK for success, or a result set for SELECT, SHOW, etc.; and even a successful statement may be qualified by a set of warnings or notices. If the statement fails for some reason then we’ll receive an error regarding the failure. On the server, we’ll see a variety of logs depending on the server configuration. Queries exceeding a certain execution time may get logged to the slow query log, while in some debug scenarios all queries may be logged to the general query log either as soon as they are received (--log-raw) or after parsing and having security sensitive information such as passwords replaced. Both the slow query log and the general query log may be sent to a file or table. The third major log is the error log. The error log — what and why Like the clients, the error log may receive messages of varying severities. It collects messages that do not have an obvious query, client, or connection that is to blame, messages that need persistence beyond that of a connection or the server’s runtime, and others that have an intended audience of the DBA or system administrator rather than the application developer. Examples are exhaustion of resources on the host machine, certain errors reported by the host operating system, backtraces of crashes, messages about damaged databases and indexes, errors on start-up, failed or refused connections, etc. The error log — where and why Unlike the slow and general query logs, the error log cannot be kept in a table — this sidesteps questions such as how to safely log an error about the table engine malfunctioning while using that same engine for error logging. This also makes the error log persistent beyond the runtime of the server, and makes the log file accessible to specialized log analyser tools. Enter syslog Both Unix and Windows do however already have standardized logging facilities — syslog on Unix and EventLog on Windows. Using those facilities gives us access to a plethora of tools written specifically for them, it lets us log to a different machine, etc. While the MySQL server (mysqld) previously had very basic support for the Windows EventLog, syslogging was implemented by simply writing error messages to a stream (STDOUT/STDERR). Through this stream, whatever started the server (e.g. mysqld_safe) may receive or redirect this information at the OS level (note: if you start mysqld directly these streams will be visible in your terminal window; on Windows you have to use the --console option). The mysqld_safe wrapper script would start the MySQL server and optionally direct this error output to a program that would write it to the Unix syslog. Onwards and upwards While that syslog support solved the immediate problem, there was room for improvement — all MySQL server errors were filed with a syslog severity of error, even if the message said something different. A line could contain one time-stamp from the MySQL server, and another from the syslog facilities. And those were just the cosmetic issues! Native syslogging Having native support for syslog in the MySQL server itself enables us to turn syslogging on or off at runtime, and to query its status. The syslog facility—information about what category of software the message were from—is also no longer fixed to daemon but can be queried and configured at runtime. This should make it easier to adapt the MySQL syslog messages to your syslog environment and enable better message filtering. See the manual page for syslog.conf (shell> man syslog.conf) for more on filtering. The following options have also been added and can be set at start-up as well as viewed and set at runtime via system variables (setting them requires the SUPER privilege): --log_syslog --log_syslog_include_pid --log_syslog_facility --log_syslog-tag mysqld_safe While the mysqld_safe wrapper script has been updated to be aware of the server’s new native syslog support, the options to the script remain unchanged. Where before, mysqld_safe used the program logger to pass the server’s error messages to syslog, the script now selects server options consistent with the options given to the script. Therefore mysqld_safe --syslog --syslog-tag=AZOU would result in mysqld being started with mysqld --log-syslog=1 --log-syslog-facility=daemon --log-syslog-tag=AZOU. It bears noting that the options to mysqld_safe control both the server and the mysqld_safe script itself. In the above example, the MySQL server would log as mysqld-AZOU, whereas the mysqld_safe wrapper script would log as mysqld_safe-AZOU. systemd-journal A variety of linux systems have recently adopted systemd. Its logging facilities offer a sink that is compatible to traditional syslog, making the MySQL server’s native support compatible out of the box. When systemd journaling is used, corresponding tools should be used to query and filter the logs, e.g. the journalctl program to query the logs. In the following example, our running MySQL server has the tag production (and therefore logs as mysqld-production). We could then use journalctl to ask for all log entries using that identifier: journalctl -f SYSLOG_IDENTIFIER=mysqld-production Due to the richness of systemd-journal logging, this is somewhat verbose. That’s why in the following example we ask for the output to be JSON-formatted. We’ll then use the jq tool to filter this JSON stream so that the only the fields we are interested in remain—SYSLOG_IDENTIFIER, SYSLOG_FACILITY, and MESSAGE (see the systemd.journal-fields manual page for others): journalctl -f SYSLOG_IDENTIFIER=mysqld-production -o json | jq '.SYSLOG_IDENTIFIER + " " + .SYSLOG_FACILITY + ": " + .MESSAGE' 2>/dev/null Windows On Windows EventLog is used in lieu of syslog. Like on Unix logging can be enabled, disabled, and queried at runtime. The facility and process ID options, however, are not available on Windows. A tag can be set and queried at runtime, but to create a new tag (start using a tag that does not already exist) the MySQL server needs to be started with sufficient Windows system privileges needed to create an entry in the Windows Registry. Once this entry is created then the elevated system privileges are not required to use the newly created tag. As the entry exists in the Windows registry and therefore outside the MySQL server, it will persist through restarts of the MySQL server and indeed the host machine. Care should therefore be taken not to pollute the registry with a great number of unused tags. All’s well that sends well Finally, after talking so much about the server (and laying the groundwork for future Log Lady reports), I would be amiss not to note that the MySQL client now also supports syslog. I look forward to your feedback on these new features! If you encounter any issues, please let us know by filing a bug or opening a support ticket. Thank you for using MySQL!

  • Multi-source Replication with Galera Cluster for MySQL
    November 20, 2014 By Severalnines Multi-source replication means that one server can have multiple masters from which it replicates. Why multi-source? One good reason is to consolidate databases (e.g. merge your shards) for analytical reporting or as a centralized backup server. MariaDB 10 already has this feature, and MySQL 5.7 will also support it.  It is possible to set up your Galera Cluster as an aggregator of your masters in a multi-source replication setup, we’ll walk you through the steps in this blog. Note that the howto is for Galera Cluster for MySQL (Codership) and Percona XtraDB Cluster. In a separate post, we’ll show you how to configure MariaDB Cluster 10 instead. If you would like to use MySQL Cluster (NDB) as aggregator, then check out this blog.   Galera Cluster as Aggregator/Slave   Galera cluster can operate both as MySQL master and slave. Each Galera node can act as a slave channel accepting replication from a master. The number of slave channels should be equal or less to the number of Galera master nodes in the cluster. So, if you have a three-node Galera cluster, you can have up to three different replication sources connected to it. Note that in MariaDB Galera Cluster 10, you can configure as many sources as you want since each node supports multi-source replication.  To achieve multi-source replication in MySQL 5.6, you cannot have GTID enabled for Galera Cluster. GTID will cause our Galera cluster to work as a single unit (imagine one single slave server), since it globally preserves the MySQL GTID events on the cluster.  So the cluster will not be able to replicate from more than one master. Hence, we will use the “legacy” way to determine the starting binary log file and position. On a side note, enabling GTID is highly recommended if your Galera Cluster acts as a MySQL master, as described in this blog post. We will setup multi-source replication as below: We have 3 standalone MySQL servers (masters), and each master has a separate database: mydb1, mydb2 and mydb3. We would like to consolidate all 3 databases into our Galera cluster.   Setting Up Masters   1. On each standalone MySQL server, configure it as a master by adding a server ID, enabling binary logging with ROW format: # mysql1 my.cnf server-id=101 log-bin=binlog binlog-format=ROW   # mysql2 my.cnf server-id=102 log-bin=binlog binlog-format=ROW   # mysql3 my.cnf server-id=103 log-bin=binlog binlog-format=ROW   read more