- discuss - lists.mariadb.org

[Maria-discuss] New Question: Could not increase number of max_open_files to more than 1024 (request: 1835)
by AskMonty KB 17 Sep '14

17 Sep '14

Hello, A new question has been asked in "MariaDB community" by glennbaker1: -------------------------------- Hello I'm new to mariadb and currently establishing openstack. I'm investigating an issue and I'm hoping the community can help me resolve the following error. I have increased the limits.conf and restarted mariadb however it doesn't appear to have resolved the problem as suggested in various posts I have read. Error from log 40917 15:40:19 [Warning] option 'open_files_limit': unsigned value 18446744073709551615 adjusted to 4294967295 140917 15:40:19 [Warning] Could not increase number of max_open_files to more than 1024 (request: 1835) Results of clustercheck [root@servername~]# clustercheck HTTP/1.1 200 OK Content-Type: text/plain Connection: close Content-Length: 32 Galera cluster node is synced. Limits.conf cat /etc/security/limits.conf * soft nproc 65536 * hard nproc 65536 * soft nofile 1048576 * hard nofile 1048576 * soft stack 10240 [root@lservername ~]# pcs cluster status Cluster Status: Last updated: Wed Sep 17 16:08:35 2014 Last change: Wed Sep 17 16:08:14 2014 via crm_attribute on lshkvm40a Stack: corosync Current DC: servername (3) - partition with quorum Version: 1.1.10-32.el7_0-368c726 3 Nodes configured 85 Resources configured PCSD Status: 10.25.167.207: Online 10.25.167.209: Online 10.25.167.211: Online mariadb.log 140917 15:40:19 mysqld_safe Starting mysqld daemon with databases from /var/lib/mysql 140917 15:40:19 mysqld_safe WSREP: Running position recovery with --log_error='/var/lib/mysql/wsrep_recovery.MVaILy' --pid-file='/var/lib/mysql/lshkvm40a-recover.pid' 140917 15:40:19 [Warning] option 'open_files_limit': unsigned value 18446744073709551615 adjusted to 4294967295 140917 15:40:19 [Warning] option 'open_files_limit': unsigned value 18446744073709551615 adjusted to 4294967295 140917 15:40:19 [Warning] Could not increase number of max_open_files to more than 1024 (request: 1835) /usr/libexec/mysqld: Query cache is disabled (resize or similar command in progress); repeat this command later 140917 15:40:21 mysqld_safe WSREP: Recovered position 87e05b4e-3437-11e4-b636-9b7b2bb055fc:1282018 140917 15:40:21 [Warning] option 'open_files_limit': unsigned value 18446744073709551615 adjusted to 4294967295 140917 15:40:21 [Warning] option 'open_files_limit': unsigned value 18446744073709551615 adjusted to 4294967295 140917 15:40:21 [Note] WSREP: wsrep_start_position var submitted: '87e05b4e-3437-11e4-b636-9b7b2bb055fc:1282018' 140917 15:40:21 [Warning] Could not increase number of max_open_files to more than 1024 (request: 1835) /usr/libexec/mysqld: Query cache is disabled (resize or similar command in progress); repeat this command later 140917 15:40:21 [Note] WSREP: Read nil XID from storage engines, skipping position init 140917 15:40:21 [Note] WSREP: wsrep_load(): loading provider library '/usr/lib64/galera/libgalera_smm.so' 140917 15:40:21 [Note] WSREP: wsrep_load(): Galera 3.5(rXXXX) by Codership Oy <info(a)codership.com> loaded successfully. 140917 15:40:21 [Note] WSREP: CRC-32C: using hardware acceleration. Thanks for your time and assistance. -------------------------------- To view or answer this question please visit: http://mariadb.com/kb/en/could-not-increase-number-of-max_open_files-to-mor…

2 1

[Maria-discuss] .ibd files remaining after DROP TABLE
by Andrew Braithwaite 17 Sep '14

17 Sep '14

Hi, After dropping tables on my MariaDB 10.0.13 database server, the .frm files are removed but the .ibd files remain behind. Has anyone seen this before? Thanks.... Andrew mysqld Ver 10.0.13-MariaDB-1~trusty for debian-linux-gnu on x86_64 ( mariadb.org binary distribution) DISTRIB_ID=Ubuntu DISTRIB_RELEASE=14.04 DISTRIB_CODENAME=trusty DISTRIB_DESCRIPTION="Ubuntu 14.04.1 LTS" NAME="Ubuntu" VERSION="14.04.1 LTS, Trusty Tahr" ID=ubuntu ID_LIKE=debian PRETTY_NAME="Ubuntu 14.04.1 LTS" VERSION_ID="14.04" HOME_URL="http://www.ubuntu.com/" SUPPORT_URL="http://help.ubuntu.com/" BUG_REPORT_URL="http://bugs.launchpad.net/ubuntu/"

1 0

Re: [Maria-discuss] Need input on crashes on 3rd mariaDB server
by Jeroen Andriessen 17 Sep '14

17 Sep '14

Dear Jan, Thank you in advance for any time you invest in our issue. We were wondering if you had a chance to see our questions in response to your suggestions about enabling logging to further research our intermittent server crash issue? Best, Jeroen Andriessen On 27 Aug 2014, at 15:56 pm, Jeroen Andriessen <jeroen(a)lemonbit.com> wrote: > Hi Jan, > > Thank you for answering, sorry for getting back to you so late with this answer. We are a little hesitant to post full unedited error_logs to the newsgroup, because of user information sensitivity. > > Right now the problem hasn’t manifested itself for about a month. When you suggest enabling logging, I assume you are referring to the General Query Log? Or did you mean something else? As I understand it, enabling this log, with this great an interval between occurrences might mean a significant prolonged performance lag, due to the great amount of logging that wil occur. Do you think that is advisable? We wouldn’t want to run this logging for such an extended period of time. > > Thank you for your advice, > > Jeroen > > On 30 Jul 2014, at 16:53 pm, Jan Lindström <jan.lindstrom(a)skysql.com> wrote: > >> Hi, >> >> First thing is trying to identify which SQL-clause is causing this error and assertion. Could you provide us MariaDB configuration and full unedited error long from all the nodes. Furthermore, could you enable logging at least temporally adding log = log_file_name to your configuration and when/if problem repreoduces, provide the log files ? >> >> R: Jan >> >> >> On Wed, Jul 30, 2014 at 5:21 PM, Jeroen Andriessen <jeroen(a)lemonbit.com> wrote: >> Hi all, >> >> We’re currently using a system with three clustered maria-db masters. We are experiencing occasional (once every three weeks or so) crashes of one of the server, namely our third server, which we use as a dedicated donor for the other two. The crashes point to a BF-BF X lock conflict in the same table. I was wondering how to proceed with identifying and localising the problem and counteracting it. We have already tried to rebuild the database in question from an earlier mysql dump, to no effect. >> >> Any input is welcome, thanks. >> >> —— >> >> BF-BF X lock conflict >> RECORD LOCKS space id 36361 page no 10 n bits 264 index `***REDACTED***` of table `***REDACTED***`.`***REDACTED***` trx id D860A49 lock_mode X locks rec but not gap >> 140724 6:10:53 [ERROR] mysqld got signal 6 ; >> This could be because you hit a bug. It is also possible that this binary >> or one of the libraries it was linked against is corrupt, improperly built, >> or misconfigured. This error can also be caused by malfunctioning hardware. >> >> To report this bug, see http://kb.askmonty.org/en/reporting-bugs >> >> We will try our best to scrape up some info that will hopefully help >> diagnose the problem, but since we have already crashed, >> something is definitely wrong and this may fail. >> >> Server version: 5.5.38-MariaDB-wsrep-log >> key_buffer_size=134217728 >> read_buffer_size=131072 >> max_used_connections=7 >> max_threads=1002 >> thread_count=20 >> It is possible that mysqld could use up to >> key_buffer_size + (read_buffer_size + sort_buffer_size)*max_threads = 2329723 K bytes of memory >> Hope that's ok; if not, decrease some variables in the equation. >> >> Thread pointer: 0x0x7f57b3412000 >> Attempting backtrace. You can use the following information to find out >> where mysqld died. If you see no messages after this, something went >> terribly wrong... >> stack_bottom = 0x7f5c1a16b940 thread_stack 0x48000 >> (my_addr_resolve failure: fork) >> /usr/sbin/mysqld(my_print_stacktrace+0x2b) [0xa95bab] >> /usr/sbin/mysqld(handle_fatal_signal+0x398) [0x6ebc58] >> /lib64/libpthread.so.0() [0x34e7e0f710] >> /lib64/libc.so.6(gsignal+0x35) [0x34e7632925] >> /lib64/libc.so.6(abort+0x175) [0x34e7634105] >> /usr/sbin/mysqld() [0x50e940] >> /usr/sbin/mysqld() [0x92c0ff] >> /usr/sbin/mysqld() [0x931799] >> /usr/sbin/mysqld() [0x932566] >> /usr/sbin/mysqld() [0x968a65] >> /usr/sbin/mysqld() [0x85fe3b] >> /usr/sbin/mysqld() [0x863ada] >> /usr/sbin/mysqld() [0x8642de] >> /usr/sbin/mysqld() [0x84e571] >> /usr/sbin/mysqld() [0x8337b2] >> /usr/sbin/mysqld(handler::ha_delete_row(unsigned char const*)+0xb0) [0x6f3640] >> /usr/sbin/mysqld(Delete_rows_log_event::do_exec_row(Relay_log_info const*)+0x10d) [0x7a41dd] >> /usr/sbin/mysqld(Rows_log_event::do_apply_event(Relay_log_info const*)+0x26a) [0x798e2a] >> /usr/sbin/mysqld(wsrep_apply_cb(void*, void const*, unsigned long, unsigned int, wsrep_trx_meta const*)+0x598) [0x69f988] >> /usr/lib64/galera/libgalera_smm.so(galera::TrxHandle::apply(void*, wsrep_cb_status (*)(void*, void const*, unsigned long, unsigned int, wsrep_trx_meta const*), wsrep_trx_meta const&) const+0xb1) [0x7f5c197462c1] >> /usr/lib64/galera/libgalera_smm.so(+0x1aaf95) [0x7f5c1977df95] >> /usr/lib64/galera/libgalera_smm.so(galera::ReplicatorSMM::apply_trx(void*, galera::TrxHandle*)+0x283) [0x7f5c1977ee03] >> /usr/lib64/galera/libgalera_smm.so(galera::ReplicatorSMM::process_trx(void*, galera::TrxHandle*)+0x45) [0x7f5c1977f6f5] >> /usr/lib64/galera/libgalera_smm.so(galera::GcsActionSource::dispatch(void*, gcs_action const&, bool&)+0x2c9) [0x7f5c1975c349] >> /usr/lib64/galera/libgalera_smm.so(galera::GcsActionSource::process(void*, bool&)+0x63) [0x7f5c1975c823] >> /usr/lib64/galera/libgalera_smm.so(galera::ReplicatorSMM::async_recv(void*)+0x93) [0x7f5c1977b3f3] >> /usr/lib64/galera/libgalera_smm.so(galera_recv+0x23) [0x7f5c19790743] >> /usr/sbin/mysqld() [0x6a037f] >> /usr/sbin/mysqld(start_wsrep_THD+0x365) [0x527415] >> /lib64/libpthread.so.0() [0x34e7e079d1] >> /lib64/libc.so.6(clone+0x6d) [0x34e76e8b5d] >> >> Trying to get some variables. >> Some pointers may be invalid and cause the dump to abort. >> Query (0x0): is an invalid pointer >> Connection ID (thread ID): 17 >> Status: NOT_KILLED >> >> Optimizer switch: index_merge=on,index_merge_union=on,index_merge_sort_union=on,index_merge_intersection=on,index_merge_sort_intersection=off,engine_condition_pushdown=off,index_condition_pushdown=on,derived_merge=on,derived_with_keys=on,firstmatch=on,loosescan=on,materialization=on,in_to_exists=on,semijoin=on,partial_match_rowid_merge=on,partial_match_table_scan=on,subquery_cache=on,mrr=off,mrr_cost_based=off,mrr_sort_keys=off,outer_join_with_cache=on,semijoin_with_cache=on,join_cache_incremental=on,join_cache_hashed=on,join_cache_bka=on,optimize_join_buffer_size=off,table_elimination=on,extended_keys=off >> >> The manual page at http://dev.mysql.com/doc/mysql/en/crashing.html contains >> information that should help you find out what is causing the crash. >> 140724 06:10:53 mysqld_safe Number of processes running now: 0 >> 140724 06:10:53 mysqld_safe WSREP: not restarting wsrep node automatically >> 140724 06:10:53 mysqld_safe mysqld from pid file /var/lib/mysql/***hostnameredacted***.pid ended >> _______________________________________________ >> Mailing list: https://launchpad.net/~maria-discuss >> Post to : maria-discuss(a)lists.launchpad.net >> Unsubscribe : https://launchpad.net/~maria-discuss >> More help : https://help.launchpad.net/ListHelp >> >> >> >> -- >> -- >> >> Jan Lindström, Principal Engineer >> SkySQL - The MariaDB Company >> >> >> >> skype: jan_p_lindstrom >> >> www.skysql.com >> >> >> >

1 0

[Maria-discuss] connection limit, connection drops
by Jonas Genannt 16 Sep '14

16 Sep '14

Hello, I'm using MariaDB 5.5.33a on Debian Wheezy. I have problems with connections from our PHP Application to MariaDB. Then there is high traffic the concurrent connections goes up to 1700 - 2200. If we have 1700 - 2200 concurrent connections we have sporadic connection drops like: "Can't connect to mysql ....." I have bumped the max_connection to 10000 and set some sysctl variables: echo 55536 > cat /proc/sys/net/core/somaxconn echo 10000 > /proc/sys/net/core/netdev_max_backlog echo "1024 65535" > /proc/sys/net/ipv4/ip_local_port_range echo "15"> /proc/sys/net/ipv4/tcp_fin_timeout I have also bumped up the open files for the MySQL user. The Mysql user of our application has no user connection limit in mysql.user. The error is still present, does anybody has a idea about it? Thanks! Jonas

2 3

[Maria-discuss] Galera cluster as slave: Duplicate entry errors
by Otto Berger 08 Sep '14

08 Sep '14

Hi all, i'm new to this list :) My setup: MySQL Server 5.5.37 -> Replication -> Galera 10 Cluster (currently 2 nodes) The old MySQL Master is receiving inserts to a table with a auto_increment field (primary key). The Galera Cluster is configured as classic slave to the master. From time to time i'm getting duplicate entry issues on the galera cluster: 140905 12:06:15 [ERROR] Slave SQL: Error 'Duplicate entry '16383' for key 'PRIMARY'' on query. ... 140905 12:06:15 [Warning] Slave: Duplicate entry '16383' for key 'PRIMARY' Error_code: 1062 I cannot see the problem where there could came from... My thought was if the insert (auto_increment) succeeds on the master then is must also succeed on the galera side... someone with an idea on it? BR Otto

3 3

[Maria-discuss] optimization
by Roberto Spadim 04 Sep '14

04 Sep '14

guys, i have some queries like this: SELECT doc_hash_key FROM mov_documentos WHERE doc_hash_key LIKE "j;1;$;294007/3nfe-1%" UNION SELECT doc_hash_key FROM mov_documentos WHERE doc_hash_key LIKE "j;1;%;294007/3nfe-1%" UNION SELECT doc_hash_key FROM mov_documentos WHERE doc_hash_key LIKE "j;1;%;%294007/3nfe-1%" UNION SELECT doc_hash_key FROM mov_documentos WHERE doc_hash_key LIKE "%;%;$;%294007/3nfe-1%" UNION SELECT doc_hash_key FROM mov_documentos WHERE doc_hash_key LIKE "%;%;%;294007/3nfe-1%" UNION SELECT doc_hash_key FROM mov_documentos WHERE doc_hash_key LIKE "%;%;%;%294007/3nfe-1%" LIMIT 1 it's a search about a document number, but the problem is.... the first query at first line (with % at end of the query) return really fast, but executing others queries are very slow, the question is could we optimize this kind of query, since limit=1 row? the explain of this query: idselect_typetabletypepossible_keyskeykey_lenrefrowsExtra1PRIMARY mov_documentosrangePRIMARYPRIMARY771Using where; Using index2UNION mov_documentosrangePRIMARYPRIMARY77625612Using where; Using index3UNION mov_documentosrangePRIMARYPRIMARY77625612Using where; Using index4UNION mov_documentosindexPRIMARY771798490Using where; Using index5UNION mov_documentosindexPRIMARY771798490Using where; Using index6UNION mov_documentosindexPRIMARY771798490Using where; Using indexUNION RESULT <union1,2,3,4,5,6>ALL -- Roberto Spadim

3 6

[Maria-discuss] Excluding plugins when building MariaDB 10.1
by Kolbe Kegel 04 Sep '14

04 Sep '14

Hi! I'm trying to build MariaDB 10.1 on OS X. cmake ../server/ -DBUILD_CONFIG=mysql_release -DWITH_SSL=system -DCMAKE_CXX_FLAGS:STRING='-stdlib=libstdc++' -DPLUGIN_TOKUDB=NO -DPLUGIN_OQGRAPH=NO -DWITH_EMBEDDED_SERVER:BOOL=OFF -DWITH_WSREP=OFF The build is failing on tokudb code even though I am trying to avoid building the TokuDB plugin. What gives? Linking CXX shared library libft.dylib Undefined symbols for architecture x86_64: "std::__1::__vector_base_common<true>::__throw_length_error() const", referenced from: toku::dmt<klpair_struct, klpair_struct*, toku::klpair_dmtwriter>::verify() const in bndata.cc.o "std::__1::__vector_base_common<true>::__throw_out_of_range() const", referenced from: toku::dmt<klpair_struct, klpair_struct*, toku::klpair_dmtwriter>::verify() const in bndata.cc.o toku::dmt<klpair_struct, klpair_struct*, toku::klpair_dmtwriter>::verify_internal(toku::dmt_internal::subtree const&, std::__1::vector<bool, std::__1::allocator<bool> >*) const in bndata.cc.o ld: symbol(s) not found for architecture x86_64 clang: error: linker command failed with exit code 1 (use -v to see invocation) make[2]: *** [storage/tokudb/ft-index/ft/libft.dylib] Error 1 make[1]: *** [storage/tokudb/ft-index/ft/CMakeFiles/ft.dir/all] Error 2 make: *** [all] Error 2 Kolbe -- Kolbe Kegel, Principal Support Engineer SkySQL, The MariaDB Company | http://www.skysql.com

3 4

[Maria-discuss] MariaDB Galera Cluster 10.0.13 now available
by Daniel Bartholomew 03 Sep '14

03 Sep '14

The MariaDB project is pleased to announce the immediate availability of MariaDB Galera Cluster 10.0.13 This is a Stable (GA) release. See the Release Notes and Changelog for details. - - Links - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - MariaDB Galera Cluster 10.0.13 - Release Notes: https://mariadb.com/kb/en/mariadb-galera-cluster-10013-release-notes - Changelog: https://mariadb.com/kb/en/mariadb-galera-cluster-10013-changelog - Downloads: https://downloads.mariadb.org/mariadb-galera/10.0.13 About MariaDB Galera Cluster: - https://mariadb.com/kb/en/what-is-mariadb-galera-cluster/ APT and YUM Repository Configuration Generator: - https://downloads.mariadb.org/mariadb/repositories/ - - MariaDB Webinars - - - - - - - - - - - - - - - - - - - - - - - - - There are several upcoming MariaDB-focused webinars and many previously held ones available to watch on an on-demand basis at: - https://mariadb.com/news-events/webinars - - MariaDB Books - - - - - - - - - - - - - - - - - - - - - - - - - - Building a Web Application with PHP and MariaDB: A Reference Guide is the latest MariaDB book in Packt's growing MariaDB book series. It guides you through all the steps to get your app up and running. - http://bit.ly/1qrqMQx The recently published MariaDB Cookbook contains nearly 100 recipes covering a variety of features in MariaDB 5.5 and 10.0. - http://bit.ly/WZs2Pd Another book, Getting Started with MariaDB is a how-to guide for beginners to help them get up to speed quickly with MariaDB. No prior database experience required. - http://bit.ly/MMElbQ - - User Feedback plugin - - - - - - - - - - - - - - - - - - - - - - - MariaDB includes a User Feedback plugin. This plugin is disabled by default. If enabled, it submits basic, completely anonymous MariaDB usage information. This information is used by the developers to track trends in MariaDB usage to better guide development efforts. If you would like to help make MariaDB better, please add "feedback=ON" to your my.cnf or my.ini file! See http://mariadb.com/kb/en/user-feedback-plugin for more information. - - Quality - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - The project always strives for quality, but in reality, nothing is perfect. Please take time to report any issues you encounter at: - http://mariadb.org/jira - - Support MariaDB - - - - - - - - - - - - - - - - - - - - - - - - - - If you would like to contribute to the MariaDB Foundation, please see the "contributing" and "donations" pages. We also have merchandise available in a cafepress store. All proceeds go to support the MariaDB Foundation. - https://mariadb.com/kb/en/contributing - https://mariadb.org/en/donate/ - http://www.cafepress.com/mariadb We hope you enjoy MariaDB! -- MariaDB Website - http://mariadb.org Twitter - http://twitter.com/mariadb Google+ - http://google.com/+mariadb Facebook - http://fb.com/MariaDB.dbms Knowledge Base - http://mariadb.com/kb

1 0

Re: [Maria-discuss] MariaDB Galera Cluster 10.0.13
by Cloud Foundry Services 29 Aug '14

29 Aug '14

Hello, Is MariaDB Galera Cluster 10.0.13 on track for release today? https://mariadb.atlassian.net/browse/MDEV/fixforversion/16800/ Thank you, On Mon, Aug 25, 2014 at 1:40 PM, Nirbhay Choubey <nirbhay(a)skysql.com> wrote: > Hi Shannon, > > On Mon, Aug 25, 2014 at 4:26 PM, Cloud Foundry Services < > cf-services-eng(a)pivotal.io> wrote: > >> Hi Nirbhay, >> >> We're looking forward to these fixes: >> >> https://mariadb.atlassian.net/browse/MDEV-5786 - We were previously >> running mysql_upgrade on every node and getting errors due to replication. >> We now disable replication while mysql_upgrade is running but this makes us >> vulnerable to writes while replication is disabled. We could prevent writes >> while replication is disabled, but we expect this fix will allow us to >> revert our automation around disabling replication. >> >> https://mariadb.atlassian.net/browse/MDEV-6492 - Our understanding is >> that until we receive this fix, nodes can receive writes that may not be >> replicated while in donor mode for an rsync SST. We expect this fix to >> prevent writes while in donor mode for rsync SST. >> >> We are also crossing our fingers that 10.0.13 resolves this issue (link >> is to codership forum, just posted the same question to maria-discuss a few >> minutes ago): >> https://groups.google.com/forum/#!topic/codership-team/OSnQ1FLloBI. We >> haven't filed a bug for it yet; were hoping to get a sanity check first. >> > > > Fix for both the above issues have been queued for MariaDB Galera Server > 10.0.13, and should quite likely fix the issues that you are facing. > > Thanks! > > - Nirbhay > > > >> Thank you, >> Shannon >> >> Cloud Foundry Service, Pivotal >> >> On Mon, Aug 25, 2014 at 1:05 PM, Nirbhay Choubey <nirbhay(a)skysql.com> >> wrote: >> >>> Hi, >>> >>> On Mon, Aug 25, 2014 at 3:45 PM, Cloud Foundry Services < >>> cf-services-eng(a)pivotal.io> wrote: >>> >>>> Hello, >>>> >>>> Any word on the release of MariaDB Galera Cluster 10.0.13? >>>> >>> >>> It should be out in a couple of days. >>> >>> >>>> We've been seeing issues with replication that we really hope this >>>> release will fix. >>>> >>> >>> What are the issues like? Could you describe them? Or report a bug? >>> >>> mariadb.org/jira >>> >>> Best, >>> Nirbhay >>> >>> >>>> Thank you, >>>> Shannon >>>> >>>> Cloud Foundry Services, Pivotal >>>> >>>> _______________________________________________ >>>> Mailing list: https://launchpad.net/~maria-discuss >>>> Post to : maria-discuss(a)lists.launchpad.net >>>> Unsubscribe : https://launchpad.net/~maria-discuss >>>> More help : https://help.launchpad.net/ListHelp >>>> >>>> >>> >> >

1 0

Re: [Maria-discuss] MariaDB Galera Cluster 10.0.13
by Cloud Foundry Services 25 Aug '14

25 Aug '14

Hi Nirbhay, We're looking forward to these fixes: https://mariadb.atlassian.net/browse/MDEV-5786 - We were previously running mysql_upgrade on every node and getting errors due to replication. We now disable replication while mysql_upgrade is running but this makes us vulnerable to writes while replication is disabled. We could prevent writes while replication is disabled, but we expect this fix will allow us to revert our automation around disabling replication. https://mariadb.atlassian.net/browse/MDEV-6492 - Our understanding is that until we receive this fix, nodes can receive writes that may not be replicated while in donor mode for an rsync SST. We expect this fix to prevent writes while in donor mode for rsync SST. We are also crossing our fingers that 10.0.13 resolves this issue (link is to codership forum, just posted the same question to maria-discuss a few minutes ago): https://groups.google.com/forum/#!topic/codership-team/OSnQ1FLloBI. We haven't filed a bug for it yet; were hoping to get a sanity check first. Thank you, Shannon Cloud Foundry Service, Pivotal On Mon, Aug 25, 2014 at 1:05 PM, Nirbhay Choubey <nirbhay(a)skysql.com> wrote: > Hi, > > On Mon, Aug 25, 2014 at 3:45 PM, Cloud Foundry Services < > cf-services-eng(a)pivotal.io> wrote: > >> Hello, >> >> Any word on the release of MariaDB Galera Cluster 10.0.13? >> > > It should be out in a couple of days. > > >> We've been seeing issues with replication that we really hope this >> release will fix. >> > > What are the issues like? Could you describe them? Or report a bug? > > mariadb.org/jira > > Best, > Nirbhay > > >> Thank you, >> Shannon >> >> Cloud Foundry Services, Pivotal >> >> _______________________________________________ >> Mailing list: https://launchpad.net/~maria-discuss >> Post to : maria-discuss(a)lists.launchpad.net >> Unsubscribe : https://launchpad.net/~maria-discuss >> More help : https://help.launchpad.net/ListHelp >> >> >

1 0