April 2020 - discuss - lists.mariadb.org

[Maria-discuss] Galera 23.2.7 mariadb 5.5.33a msvc 1600 binaries available
by Yann Nayn 18 Nov '24

18 Nov '24

Binaries have been uploaded for both x86 and amd64 platforms. due to github file size limitations , the directories have been uploaded unarchived. for Win33 binaries , please checkout https://github.com/YannNayn/galera-mariadb-win32.git and for Win64(amd64) binaries (being uploaded/pushed): https://github.com/YannNayn/galera-mariadb-win64.git they are not recommended for a production environment. in the my.cnf file: _________ wsrep_provider=galera_smm.dll wsrep_sst_method=msqldump # percona xtrabackup will be tested soon _________ libevent and openssl(the provided binaries use respectively 2.1.3-alpha and 1.1.0-dev versions ) will be added next on github some limitations are stated on openssl website copied here for convenience: ____________ from http://www.openssl.org/ ____________ This software package uses strong cryptography, so even if it is created, maintained and distributed from liberal countries in Europe (where it is legal to do this), it falls under certain export/import and/or use restrictions in some other parts of the world. PLEASE REMEMBER THAT EXPORT/IMPORT AND/OR USE OF STRONG CRYPTOGRAPHY SOFTWARE, PROVIDING CRYPTOGRAPHY HOOKS OR EVEN JUST COMMUNICATING TECHNICAL DETAILS ABOUT CRYPTOGRAPHY SOFTWARE IS ILLEGAL IN SOME PARTS OF THE WORLD. SO, WHEN YOU IMPORT THIS PACKAGE TO YOUR COUNTRY, RE-DISTRIBUTE IT FROM THERE OR EVEN JUST EMAIL TECHNICAL SUGGESTIONS OR EVEN SOURCE PATCHES TO THE AUTHOR OR OTHER PEOPLE YOU ARE STRONGLY ADVISED TO PAY CLOSE ATTENTION TO ANY EXPORT/IMPORT AND/OR USE LAWS WHICH APPLY TO YOU. THE AUTHORS OF OPENSSL ARE NOT LIABLE FOR ANY VIOLATIONS YOU MAKE HERE. SO BE CAREFUL, IT IS YOUR RESPONSIBILITY. ________________________________________________ msvc 1600 redistributables SP1 need to be installed/available on the target machine: vcredist_x86.exe : http://www.microsoft.com/en-us/download/details.aspx?id=8328 vcredist_x64.exe : http://www.microsoft.com/en-us/download/details.aspx?id=13523 MSys binaries are provided and msqld.bat should then be used instead of mysqld.exe (e.g. mysld.bat --console --wsrep_cluster_address=gcomm:// ) in order to have a working sh shell(cygwin has been proved to do it as well) Please note that oqgraph is disabled (boost trunk is used , that is 1.55) Comments and suggestions are welcome.

2 1

[Maria-discuss] Single-threaded DDL limitation still present in Galera?
by Artem Russakovskii 13 Aug '20

13 Aug '20

Hi, On this page https://mariadb.com/kb/en/mariadb-galera-cluster-known-limitations/, a user in 2017 pointed out the following: 3 years, 3 months ago Björn Schneider <https://mariadb.com/kb/user/id/4916> Schema changes of large tables in Galera <https://mariadb.com/kb/en/mariadb-galera-cluster-known-limitations/#comment…> You should be warned that every DDL statement executed on a Galera cluster will per default BLOCK the complete cluster (not only the table, or even just the database the table resides in)! This is the default "Total Order Isolation" (TOI) mode. The DDL statements can't be killed - once issued, it will run until completed or an error occurs. Issuing e.g. a column-altering DDL statement on a large table will take the complete cluster out of commission until every node has completed the migration. Only some operations (e.g. changing DEFAULT values) are always short-timed and won't interefere with the cluster's opperations. Long-running, cluster-blocking DDL are of course a no-go on a productive system. To resolve this issue, there are several resulutions; Percona, for example, provides a script to "online" migrate a table (pt-online-schema-change), or you can use the "Rolling Schema Upgrade" (RSU) for data-compatible changes. More about that in the Galera documentation. In my opionion, this behaviour should definitely added as "observation" to this page - it's definitely not something you'd expect coming from a "normal" MariaDB/MySQL system. We're considering moving to a cluster environment from a 1 master - 3 slave configuration that has proven inflexible, but such a severe limitation seems unusable in production. Is this still the case in 2020? What is the reasoning behind such an architectural decision, if so? Thank you. Sincerely, Artem -- Founder, Android Police <http://www.androidpolice.com>, APK Mirror <http://www.apkmirror.com/>, Illogical Robot LLC beerpla.net | @ArtemR <http://twitter.com/ArtemR>

2 3

[Maria-discuss] why stdout? -> [Note] /usr/libexec/mysqld (mysqld 10.0.20-MariaDB) starting as process 115096
by Reindl Harald 05 Jul '20

05 Jul '20

Aug 6 12:24:24 testserver mysqld: 150806 12:24:24 [Note] /usr/libexec/mysqld (mysqld 10.0.20-MariaDB) starting as process 115096 ... why is this now stdout instead mysql logs? on systemd based distributions that spits now to the global syslog and finally on machines restarting 2 instances every hour for backup reasons it annoys until 10.0.19 or 10.0.20 that was not this way

5 13

[Maria-discuss] backup from any cluster member can't be restarted and restored
by Jeff Dyke 27 May '20

27 May '20

This has biting me for a bit, and i have tried a litany of things. Here is the issue: VPC 1: (prod) Mariadb 10.4.12 - galera in a 3 node cluster, cluster functioning perfectly VPC 2: (staging) Mariadb 10.4.12 galera in a 3 node cluster also running smoothly. -- backup script (clipped for only the essentials) -- set -e DIR="/home/jeff/restore" rm -rf $DIR mkdir $DIR AUTH='--defaults-extra-file=/root/db.cnf -u root' sudo mysql ${AUTH} -e "SET GLOBAL wsrep_desync = ON;" sudo mysql ${AUTH} -e "SET GLOBAL wsrep_on = OFF"; sudo mariabackup ${AUTH} --backup --binlog-info=ON --target-dir="${DIR}" 2>&1 | grep -vE "Copying|done|log scanned" sudo mysql ${AUTH} -e "SET GLOBAL wsrep_on = ON;" sudo mysql ${AUTH} -e "SET GLOBAL wsrep_desync = OFF"; -- end script -- -- restore process -- sudo service mariadb stop (or kill -9 PID only when the server won't start) sudo rm -rf /var/lib/mysl/* sudo mariabackup --prepare --target-dir=restore sudo mariabackup --copy-back --target-dir=restore sudo chown -R mysql:mysql /var/lib/mysql/* sudo service mariadb start -- end restore -- I can run this on any of the script and backup process on any of the *staging* nodes and restore them to a freshly built server within that VPC. I can also take the backup from *staging* and load in into a newly build machine on the *prod* VPC. What i can not do is run the script on any of the prod members and restore it to a newly built server, regardless of location. (really the locations don't matter at all) The following is the log from a failing restore from a proddb backup and restore: 2020-04-15 22:11:10 0 [Note] InnoDB: Using Linux native AIO 2020-04-15 22:11:10 0 [Note] InnoDB: Mutexes and rw_locks use GCC atomic builtins 2020-04-15 22:11:10 0 [Note] InnoDB: Uses event mutexes 2020-04-15 22:11:10 0 [Note] InnoDB: Compressed tables use zlib 1.2.11 2020-04-15 22:11:10 0 [Note] InnoDB: Number of pools: 1 2020-04-15 22:11:10 0 [Note] InnoDB: Using SSE2 crc32 instructions 2020-04-15 22:11:10 0 [Note] mysqld: O_TMPFILE is not supported on /tmp (disabling future attempts) 2020-04-15 22:11:10 0 [Note] InnoDB: Initializing buffer pool, total size = 2G, instances = 8, chunk size = 128M 2020-04-15 22:11:10 0 [Note] InnoDB: Completed initialization of buffer pool 2020-04-15 22:11:10 0 [Note] InnoDB: If the mysqld execution user is authorized, page cleaner thread priority can be changed. See the man page of setpriority(). 2020-04-15 22:11:10 0 [Note] InnoDB: Setting log file ./ib_logfile101 size to 50331648 bytes 2020-04-15 22:11:10 0 [Note] InnoDB: Setting log file ./ib_logfile1 size to 50331648 bytes 2020-04-15 22:11:10 0 [Note] InnoDB: Renaming log file ./ib_logfile101 to ./ib_logfile0 2020-04-15 22:11:10 0 [Note] InnoDB: New log files created, LSN=42006460184 2020-04-15 22:11:10 0 [Note] InnoDB: 128 out of 128 rollback segments are active. 2020-04-15 22:11:10 0 [Note] InnoDB: Creating shared tablespace for temporary tables 2020-04-15 22:11:10 0 [Note] InnoDB: Setting file './ibtmp1' size to 12 MB. Physically writing the file full; Please wait ... 2020-04-15 22:11:10 0 [Note] InnoDB: File './ibtmp1' size is now 12 MB. 2020-04-15 22:11:10 0 [Note] InnoDB: Waiting for purge to start 2020-04-15 22:11:10 0 [Note] InnoDB: 10.4.12 started; log sequence number 42006460428; transaction id 23858673 2020-04-15 22:11:10 0 [Note] InnoDB: Loading buffer pool(s) from /var/lib/mysql/ib_buffer_pool 2020-04-15 22:11:10 0 [Note] Plugin 'FEEDBACK' is disabled. 2020-04-15 22:11:11 0 [Note] InnoDB: Buffer pool(s) load completed at 200415 22:11:11 -- hangs here for about an hour before timing out -- Logfile from a successful start 2020-04-15 23:13:15 0 [Note] InnoDB: Using Linux native AIO 2020-04-15 23:13:15 0 [Note] InnoDB: Mutexes and rw_locks use GCC atomic builtins 2020-04-15 23:13:15 0 [Note] InnoDB: Uses event mutexes 2020-04-15 23:13:15 0 [Note] InnoDB: Compressed tables use zlib 1.2.11 2020-04-15 23:13:15 0 [Note] InnoDB: Number of pools: 1 2020-04-15 23:13:15 0 [Note] InnoDB: Using SSE2 crc32 instructions 2020-04-15 23:13:15 0 [Note] mysqld: O_TMPFILE is not supported on /tmp (disabling future attempts) 2020-04-15 23:13:15 0 [Note] InnoDB: Initializing buffer pool, total size = 2G, instances = 8, chunk size = 128M 2020-04-15 23:13:16 0 [Note] InnoDB: Completed initialization of buffer pool 2020-04-15 23:13:16 0 [Note] InnoDB: If the mysqld execution user is authorized, page cleaner thread priority can be changed. See the man page of setpriority(). 2020-04-15 23:13:16 0 [Note] InnoDB: Setting log file ./ib_logfile101 size to 50331648 bytes 2020-04-15 23:13:16 0 [Note] InnoDB: Setting log file ./ib_logfile1 size to 50331648 bytes 2020-04-15 23:13:16 0 [Note] InnoDB: Renaming log file ./ib_logfile101 to ./ib_logfile0 2020-04-15 23:13:16 0 [Note] InnoDB: New log files created, LSN=43323668550 2020-04-15 23:13:16 0 [Note] InnoDB: 128 out of 128 rollback segments are active. 2020-04-15 23:13:16 0 [Note] InnoDB: Creating shared tablespace for temporary tables 2020-04-15 23:13:16 0 [Note] InnoDB: Setting file './ibtmp1' size to 12 MB. Physically writing the file full; Please wait ... 2020-04-15 23:13:16 0 [Note] InnoDB: File './ibtmp1' size is now 12 MB. 2020-04-15 23:13:16 0 [Note] InnoDB: Waiting for purge to start 2020-04-15 23:13:16 0 [Note] InnoDB: 10.4.12 started; log sequence number 43323669004; transaction id 22422468 2020-04-15 23:13:16 0 [Note] InnoDB: Loading buffer pool(s) from /var/lib/mysql/ib_buffer_pool 2020-04-15 23:13:16 0 [Note] Plugin 'FEEDBACK' is disabled. 2020-04-15 23:13:16 0 [Note] Server socket created on IP: '0.0.0.0'. 2020-04-15 23:13:16 0 [Note] Reading of all Master_info entries succeeded 2020-04-15 23:13:16 0 [Note] Added new Master_info '' to hash table 2020-04-15 23:13:16 0 [Note] /usr/sbin/mysqld: ready for connections. Version: '10.4.12-MariaDB-1:10.4.12+maria~bionic' socket: '/var/run/mysqld/mysqld.sock' port: 3306 mariadb.org binary distribution 2020-04-15 23:13:22 0 [Note] InnoDB: Buffer pool(s) load completed at 200415 23:13:22 ------------------------ The main difference between the two is that: - the server socket is logged - master_info is logged - and it binds to the port/socket Before they *both* end with 2020-04-15 23:13:22 0 [Note] InnoDB: Buffer pool(s) load completed at 200415 23:13:22 -- Other Notes -- - Config files are the same except for ips, both on newly built servers as the cluster as they are managed through salt. I ran a diff -r against prod vs staging and only saw There has to be some corruption in the mariabackup output, but still reported OK. Since i can put a staging backup on a prod server, but i can not put a prod backup on a staging server. If you've gotten this far, thank you. If you have any ideas on what i could try, i'd be grateful. aria_chk and all other table checks return correctly. I'm not sure what makes a server write out the master_info, so possibly that is a pointer. I'm happy to answer any questions, i've tried way to many things to post here as i didn't want to write until i had enough of dumb stuff figured out. I could rebuild the prod cluster but am really looking to understand this. I don't really want to build my own with debug info on b/c why would they be different between the two vpcs.

3 10

[Maria-discuss] Nosql language with plugins
by Roberto Spadim 11 May '20

11 May '20

Could be possible use the query rewrite plugin to execute no sql commands? Something like disable sql parser and execute some specific protocol, returning standard sql datasets as result? -- Roberto Spadim SPAEmpresarial - Software ERP/Scada Eng. Automação e Controle, Eng. Financeira

3 4

[Maria-discuss] OSX fix need on MariaDB-10.5
by Daniel Black 09 May '20

09 May '20

Mac lovers (who can use C/C++ and a debugger), As your MariaDB developers are hard at work getting 10.5 ready for you, unfortunately a bug has slipped into the 10.5 branch making it unusable on OSX (at least that's what it looks like on the CI infrastructure). The bug report is here: https://jira.mariadb.org/browse/MDEV-22173 As the time of developers is a little short as is the availability of OSX hardware, I'm hoping some of you are able to spend a few hours tackling this task to understand it better, and if possible, create patch. Steps: 1. build environment https://mariadb.com/kb/en/Build_Environment_Setup_for_Mac/ 2. clone the source git clone --branch 10.5 https://github.com/MariaDB/server.git mariadb-server cd mariadb-server git submodule update --recursive --init 3. build instructions https://mariadb.com/kb/en/generic-build-instructions/ (you don't need to install) 4. test (from build directory) mysql-test/mysql-test-run main.select might be useful here: --debugger=NAME or --gdb client-debugger=NAME or client-gdb To collaborative share your findings and to ask for further help MariaDB's community chat stream has been created for you. https://mariadb.zulipchat.com/#narrow/stream/118759-general/topic/Get.20OSX… To paraphrase J.F.Kennedy ask not what your database server community can do for you — ask what you can do for your database server community. Keep the community spirit going, Daniel Black -- Sent as a community member who noticed OSX failures and that everyone is busy

2 3

[Maria-discuss] Redisql
by Roberto Spadim 20 Apr '20

20 Apr '20

Hi folks There’s a module, redisql That allow redis server execute sqlite like queries Could be possible a engine with this tool? It’s looks very interesting to pub sub (stream) data from mysql to redis streamers https://github.com/RedBeardLab/rediSQL -- Roberto Spadim SPAEmpresarial - Software ERP/Scada Eng. Automação e Controle, Eng. Financeira

2 1

Re: [Maria-discuss] backup from any cluster member can't be restarted and restored
by Jeff Dyke 18 Apr '20

18 Apr '20

Thanks Justin, Sorry Karl. That was indeed a typo in the email. One thing i didn't mention is that both of these clusters were updated to 10.4.12 about a month apart. They have identical versions of mariadb(mysqld) and mariabackup on both servers. I tried it also with --extended-validation with no warnings or errors. The way its been leading, my leading two ideas are that there is some corrupted data that can't be read by mariabackup, or it gets corrupted with saving local. mariabackup and mariadb-server has been uninstalled and re-installed a couple of times. On Sat, Apr 18, 2020 at 12:45 PM Justin Swanhart <greenlion(a)gmail.com> wrote: > His point was it is it is misspelled so you aren't deleting anything which > could be a problem. > > On Sat, Apr 18, 2020, 12:25 PM Jeff Dyke <jeff.dyke(a)gmail.com> wrote: > >> Thanks Karl, that is just there so everything under mysql is deleted and >> not the directory itself as mariabackup needs the datadir clean. And i'm >> using the same "script" on both VPCs. >> >> Appreciate the read! >> >> On Sat, Apr 18, 2020 at 6:01 AM Karl Erik Levik <karl.levik(a)gmail.com> >> wrote: >> >>> Hi Jeff, >>> >>> Probably not helpful, but I dunno if this is a typo just in your email >>> or also in the script? >>> >>> > sudo rm -rf /var/lib/mysl/* >>> >>> Cheers, >>> Karl >>> >>> On Thu, 16 Apr 2020 at 00:47, Jeff Dyke <jeff.dyke(a)gmail.com> wrote: >>> >>>> This has biting me for a bit, and i have tried a litany of things. >>>> Here is the issue: >>>> VPC 1: (prod) >>>> Mariadb 10.4.12 - galera in a 3 node cluster, cluster functioning >>>> perfectly >>>> >>>> VPC 2: (staging) >>>> Mariadb 10.4.12 galera in a 3 node cluster also running smoothly. >>>> >>>> -- backup script (clipped for only the essentials) -- >>>> set -e >>>> DIR="/home/jeff/restore" >>>> rm -rf $DIR >>>> mkdir $DIR >>>> AUTH='--defaults-extra-file=/root/db.cnf -u root' >>>> sudo mysql ${AUTH} -e "SET GLOBAL wsrep_desync = ON;" >>>> sudo mysql ${AUTH} -e "SET GLOBAL wsrep_on = OFF"; >>>> sudo mariabackup ${AUTH} --backup --binlog-info=ON >>>> --target-dir="${DIR}" 2>&1 | grep -vE "Copying|done|log scanned" >>>> sudo mysql ${AUTH} -e "SET GLOBAL wsrep_on = ON;" >>>> sudo mysql ${AUTH} -e "SET GLOBAL wsrep_desync = OFF"; >>>> >>>> -- end script -- >>>> >>>> -- restore process -- >>>> sudo service mariadb stop (or kill -9 PID only when the server won't >>>> start) >>>> sudo rm -rf /var/lib/mysl/* >>>> sudo mariabackup --prepare --target-dir=restore >>>> sudo mariabackup --copy-back --target-dir=restore >>>> sudo chown -R mysql:mysql /var/lib/mysql/* >>>> sudo service mariadb start >>>> -- end restore -- >>>> >>>> I can run this on any of the script and backup process on any of the >>>> *staging* nodes and restore them to a freshly built server within that >>>> VPC. I can also take the backup from *staging* and load in into a >>>> newly build machine on the *prod* VPC. >>>> >>>> What i can not do is run the script on any of the prod members and >>>> restore it to a newly built server, regardless of location. (really the >>>> locations don't matter at all) >>>> >>>> The following is the log from a failing restore from a proddb backup >>>> and restore: >>>> 2020-04-15 22:11:10 0 [Note] InnoDB: Using Linux native AIO >>>> 2020-04-15 22:11:10 0 [Note] InnoDB: Mutexes and rw_locks use GCC >>>> atomic builtins >>>> 2020-04-15 22:11:10 0 [Note] InnoDB: Uses event mutexes >>>> 2020-04-15 22:11:10 0 [Note] InnoDB: Compressed tables use zlib 1.2.11 >>>> 2020-04-15 22:11:10 0 [Note] InnoDB: Number of pools: 1 >>>> 2020-04-15 22:11:10 0 [Note] InnoDB: Using SSE2 crc32 instructions >>>> 2020-04-15 22:11:10 0 [Note] mysqld: O_TMPFILE is not supported on /tmp >>>> (disabling future attempts) >>>> 2020-04-15 22:11:10 0 [Note] InnoDB: Initializing buffer pool, total >>>> size = 2G, instances = 8, chunk size = 128M >>>> 2020-04-15 22:11:10 0 [Note] InnoDB: Completed initialization of buffer >>>> pool >>>> 2020-04-15 22:11:10 0 [Note] InnoDB: If the mysqld execution user is >>>> authorized, page cleaner thread priority can be changed. See the man page >>>> of setpriority(). >>>> 2020-04-15 22:11:10 0 [Note] InnoDB: Setting log file ./ib_logfile101 >>>> size to 50331648 bytes >>>> 2020-04-15 22:11:10 0 [Note] InnoDB: Setting log file ./ib_logfile1 >>>> size to 50331648 bytes >>>> 2020-04-15 22:11:10 0 [Note] InnoDB: Renaming log file ./ib_logfile101 >>>> to ./ib_logfile0 >>>> 2020-04-15 22:11:10 0 [Note] InnoDB: New log files created, >>>> LSN=42006460184 >>>> 2020-04-15 22:11:10 0 [Note] InnoDB: 128 out of 128 rollback segments >>>> are active. >>>> 2020-04-15 22:11:10 0 [Note] InnoDB: Creating shared tablespace for >>>> temporary tables >>>> 2020-04-15 22:11:10 0 [Note] InnoDB: Setting file './ibtmp1' size to 12 >>>> MB. Physically writing the file full; Please wait ... >>>> 2020-04-15 22:11:10 0 [Note] InnoDB: File './ibtmp1' size is now 12 MB. >>>> 2020-04-15 22:11:10 0 [Note] InnoDB: Waiting for purge to start >>>> 2020-04-15 22:11:10 0 [Note] InnoDB: 10.4.12 started; log sequence >>>> number 42006460428; transaction id 23858673 >>>> 2020-04-15 22:11:10 0 [Note] InnoDB: Loading buffer pool(s) from >>>> /var/lib/mysql/ib_buffer_pool >>>> 2020-04-15 22:11:10 0 [Note] Plugin 'FEEDBACK' is disabled. >>>> 2020-04-15 22:11:11 0 [Note] InnoDB: Buffer pool(s) load completed at >>>> 200415 22:11:11 >>>> -- hangs here for about an hour before timing out -- >>>> >>>> >>>> Logfile from a successful start >>>> >>>> 2020-04-15 23:13:15 0 [Note] InnoDB: Using Linux native AIO >>>> 2020-04-15 23:13:15 0 [Note] InnoDB: Mutexes and rw_locks use GCC >>>> atomic builtins >>>> 2020-04-15 23:13:15 0 [Note] InnoDB: Uses event mutexes >>>> 2020-04-15 23:13:15 0 [Note] InnoDB: Compressed tables use zlib 1.2.11 >>>> 2020-04-15 23:13:15 0 [Note] InnoDB: Number of pools: 1 >>>> 2020-04-15 23:13:15 0 [Note] InnoDB: Using SSE2 crc32 instructions >>>> 2020-04-15 23:13:15 0 [Note] mysqld: O_TMPFILE is not supported on /tmp >>>> (disabling future attempts) >>>> 2020-04-15 23:13:15 0 [Note] InnoDB: Initializing buffer pool, total >>>> size = 2G, instances = 8, chunk size = 128M >>>> 2020-04-15 23:13:16 0 [Note] InnoDB: Completed initialization of buffer >>>> pool >>>> 2020-04-15 23:13:16 0 [Note] InnoDB: If the mysqld execution user is >>>> authorized, page cleaner thread priority can be changed. See the man page >>>> of setpriority(). >>>> 2020-04-15 23:13:16 0 [Note] InnoDB: Setting log file ./ib_logfile101 >>>> size to 50331648 bytes >>>> 2020-04-15 23:13:16 0 [Note] InnoDB: Setting log file ./ib_logfile1 >>>> size to 50331648 bytes >>>> 2020-04-15 23:13:16 0 [Note] InnoDB: Renaming log file ./ib_logfile101 >>>> to ./ib_logfile0 >>>> 2020-04-15 23:13:16 0 [Note] InnoDB: New log files created, >>>> LSN=43323668550 >>>> 2020-04-15 23:13:16 0 [Note] InnoDB: 128 out of 128 rollback segments >>>> are active. >>>> 2020-04-15 23:13:16 0 [Note] InnoDB: Creating shared tablespace for >>>> temporary tables >>>> 2020-04-15 23:13:16 0 [Note] InnoDB: Setting file './ibtmp1' size to 12 >>>> MB. Physically writing the file full; Please wait ... >>>> 2020-04-15 23:13:16 0 [Note] InnoDB: File './ibtmp1' size is now 12 MB. >>>> 2020-04-15 23:13:16 0 [Note] InnoDB: Waiting for purge to start >>>> 2020-04-15 23:13:16 0 [Note] InnoDB: 10.4.12 started; log sequence >>>> number 43323669004; transaction id 22422468 >>>> 2020-04-15 23:13:16 0 [Note] InnoDB: Loading buffer pool(s) from >>>> /var/lib/mysql/ib_buffer_pool >>>> 2020-04-15 23:13:16 0 [Note] Plugin 'FEEDBACK' is disabled. >>>> 2020-04-15 23:13:16 0 [Note] Server socket created on IP: '0.0.0.0'. >>>> 2020-04-15 23:13:16 0 [Note] Reading of all Master_info entries >>>> succeeded >>>> 2020-04-15 23:13:16 0 [Note] Added new Master_info '' to hash table >>>> 2020-04-15 23:13:16 0 [Note] /usr/sbin/mysqld: ready for connections. >>>> Version: '10.4.12-MariaDB-1:10.4.12+maria~bionic' socket: >>>> '/var/run/mysqld/mysqld.sock' port: 3306 mariadb.org binary >>>> distribution >>>> 2020-04-15 23:13:22 0 [Note] InnoDB: Buffer pool(s) load completed at >>>> 200415 23:13:22 >>>> >>>> ------------------------ >>>> The main difference between the two is that: >>>> - the server socket is logged >>>> - master_info is logged >>>> - and it binds to the port/socket >>>> >>>> Before they *both* end with >>>> 2020-04-15 23:13:22 0 [Note] InnoDB: Buffer pool(s) load completed at >>>> 200415 23:13:22 >>>> >>>> -- Other Notes -- >>>> - Config files are the same except for ips, both on newly built servers >>>> as the cluster as they are managed through salt. I ran a diff -r against >>>> prod vs staging and only saw >>>> >>>> There has to be some corruption in the mariabackup output, but still >>>> reported OK. Since i can put a staging backup on a prod server, but i can >>>> not put a prod backup on a staging server. >>>> >>>> If you've gotten this far, thank you. If you have any ideas on what i >>>> could try, i'd be grateful. aria_chk and all other table checks return >>>> correctly. I'm not sure what makes a server write out the master_info, so >>>> possibly that is a pointer. >>>> >>>> I'm happy to answer any questions, i've tried way to many things to >>>> post here as i didn't want to write until i had enough of dumb stuff >>>> figured out. I could rebuild the prod cluster but am really looking to >>>> understand this. I don't really want to build my own with debug info on >>>> b/c why would they be different between the two vpcs. >>>> >>>> >>>> _______________________________________________ >>>> 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 >>>> >>> _______________________________________________ >>> 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 >>> >> _______________________________________________ >> 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

[Maria-discuss] How to make Maxscale change master?
by Rodrigo Severo - Fábrica 17 Apr '20

17 Apr '20

Hi, How can I make Maxscale change from it's current master to another one when it's current master stops? Here Maxscale gets stuck at: 28271 2020-04-15 11:54:32 error : Monitor was unable to connect to server S1 : 'Can't connect to MySQL server on 'S1' (115)' 28272 2020-04-15 11:54:32 warning: [mariadbmon] 'S2' is a better master candidate than the current master 'S1'. Master will change when 'S1' is no longer a valid master. and nevers changes to S2. Regards, Rodrigo Severo

1 0

[Maria-discuss] Maxscale not changing to other viable masters
by Rodrigo Severo - Fábrica 15 Apr '20

15 Apr '20

Hi, I'm not sure this is the right mailing list to talk about MaxScale. Please let me know if there is a better place. My problem is that MaxScale is not using another server as MaxScale's master when the previous master get inaccessible. More details: I'm running MaxScale 2.4.5 and my MariaDB servers are a mixture of 10.3.21 and 10.3.22. I have three MariaDB servers with a star topology replication GTID based setup: each server is a slave of the other 2. Let's call them S1, S2, and S3. When starting the whole cluster MaxScale chooses S1 as it's master (the one where MaxScale will send the change data INSERT/UPDATE/DELETE) as S1 is the first one listed in MaxScale's config. When I stop S1 I expect MaxScale to choose another server as it's new master but instead I get: 28271 2020-04-15 11:54:32 error : Monitor was unable to connect to server S1 : 'Can't connect to MySQL server on 'S1' (115)' 28272 2020-04-15 11:54:32 warning: [mariadbmon] 'S2' is a better master candidate than the current master 'S1'. Master will change when 'S1' is no longer a valid master. but S2 is never promoted to MaxScale's master, even after ((monitor_interval + backend_connect_timeout) * failcount) seconds as mentioned in https://mariadb.com/kb/en/mariadb-maxscale-24-mariadb-monitor/#failcount As I have default values for monitor_interval, backend_connect_timeout and failcount - 2s, 3s, 5 retries respectively - I would expect that in 25 seconds I would have a new master selected but, unfortunately, MaxScale gets stuck in the above situation until I restart the S1 server, when S1 resumes it's hole as MaxScale's master. I wonder if my problem is related to item 2 in https://mariadb.com/kb/en/mariadb-maxscale-24-mariadb-monitor/#master-selec… which reads: 2. It has been down for more than failcount monitor passes and has no running slaves. Running slaves behind a downed relay count. Does the fact that the slaves of S1 (S2 and S3) are running make MaxScale consider S1 still valid despite not being accessible at all? More important: how can I make MaxScale change it's chosen master in a star topology replication when the current MaxScale master stops? Regards, Rodrigo Severo

1 1