August 2024 - discuss - lists.mariadb.org

is blocked because of many connection
by Marc 31 Mar '25

31 Mar '25

I am constantly getting abuse from azure, amazon, digital ocean cloud. With previous mysql versions I never got this message. I assume you have set this to a default. I don't want to have this limit on ip but on ip+database, how can I change this?

6 40

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

05 Dec '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.

3 2

Fulltext index tokenization rules / DOC_ID
by wknauf＠hg-online.de 14 Sep '24

14 Sep '24

Hi all, first question: is there a document that describes the rules how MariaDB builds the fulltext index words? I set "innodb_ft_min_token_size=1" to include also one letter words in the index. But this does not seem to work for words like "D'Artagnan": the "d" letter is not found in "information_schema.INNODB_FT_INDEX_TABLE". It works for "D Artagnan". So I assume that single letters that are followed by a quote are ignored when building the index? You could also post the link to the source code file, but I don't know whether my C knowledge is sufficient ;-) Second question: the doc (https://mariadb.com/kb/en/information-schema-innodb_ft_index_table-table/) states that "information_schema.INNODB_FT_INDEX_TABLE.doc_id" matches to the id column of the original table: "DOC_ID: Document ID of the newly added row, either an appropriate ID column or an internal InnoDB value." But this did not happen for me - the doc_id values do not match my ID column. I tried the datatypes "int" and "bigint". Best regards Wolfgang

4 4

MariaDB ServerFest in Berlin on September 17
by Kristian Nielsen 26 Aug '24

26 Aug '24

The next MariaDB ServerFest will take place in Berlin, Germany. The event is on September 17, 2024, and is generously hosted by MariaDB Foundation sponsor Ionos: https://mariadb.org/fest-2024-berlin/ The event is open to all. I was at the MariaDB ServerFest in Helsinki last Autumn, and I really liked the close interaction with the many interesting participants: big and advanced users, developers, university students, service providers, etc. It is an excellent opportunity to meet many of the core developers, and hopefully a lot of other great people! I will be presenting at the event myself; my talk is titled: "MariaDB Replication – Fantastically Flexible and Fragile". I very much welcome questions during my talks, so feel free to prepare questions for me about anything replication. - Kristian.

2 1

MariaDB server crash status=11/SEGV on version 10.6.19
by zxc072211＠gmail.com 21 Aug '24

21 Aug '24

Hi, First, I apologize if my English isn't perfect. After upgrading my MariaDB server from version 10.6.18 to 10.6.19. I encountered an issue. When I execute a "SELECT ... FROM ( SELECT ... ) x WHERE x.colume1 .." statement, the server returns the error: "ERROR 2013 (HY000): Lost connection to server during query." I checked the `/var/log/messages` and found this message: "mariadb.service: Main process exited, code=killed, status=11/SEGV.". I used core dumping to investigate further and found that the stack frame count reaches #12171. The error at #0 is "... Item::build_clone ... at /usr/src/debug/MariaDB-/src_0/sql/item.h:1928". The previous stack frames keep repeating two frames: #1 Item_func_case_simple::do_build_clone ... at /usr/src/debug/MariaDB-/src_0/sql/item_cmpfunc.h:2448 #2 ... Item::build_clone ... at /usr/src/debug/MariaDB-/src_0/sql/item.h:1928 My OS is Rocky Linux 8.10. The MariaDB server versions where I encountered this issue are 10.6.19 and 10.11.9. The MariaDB server version without issues is 10.6.18. Has anyone else encountered this problem? Thanks in advance for any help.

2 2

External MyISAM partitions
by Jan Křístek 07 Aug '24

07 Aug '24

Hi, We have an old instance of MariaDB 10.3.9/10.3.39, with historical data. Every month I copy an old MyISAM partition (binary files) from the same version of the engine (but a different instance) to a big volume and replace an empty partition in the database with symlinks to the newly copied two files (MYD, MYI - when the engine is stopped). I have been doing it for a year or two, checking each time the data are accessible afterwards. This month it happened, that the data are not accessible anymore, and the database throwing an exception: *Got error 140: "Wrong create options" from storage engine MyISAM.* I tried doing it in a new instance, each time I replace a partition with a link to file elsewhere, the error appeared again. Does anyone have any ideas, why it's showing the error and how to avoid it? I cannot recall changing anything in the database configuration, upgrading any database, or doing any other changes. Thanks for any help you can provide, Jan

4 7

Query Performance Drops 10.3 -> 10.5 - Query Optimizer Refusing Index
by Michael Caplan 02 Aug '24

02 Aug '24

HI there, Looking for some advice. A common query "structure" that performed well in 10.3 is showing a significant performance decrease in 10.5.24. The root cause seems to be 10.5's refusal to use a key. The table in question is has a "key => value" like structure: CREATE TABLE `cases_meta` ( `id` int(10) unsigned NOT NULL AUTO_INCREMENT, `case_id` int(10) unsigned NOT NULL, `key` varchar(50) NOT NULL, `value` mediumtext DEFAULT NULL, PRIMARY KEY (`id`), KEY `key` (`key`), KEY `fk_caes_meta_1` (`case_id`), CONSTRAINT `fk_caes_meta_1` FOREIGN KEY (`case_id`) REFERENCES `cases` (`id`) ON DELETE CASCADE ON UPDATE CASCADE ) ENGINE=InnoDB DEFAULT CHARSET=utf8 COLLATE=utf8_general_ci The query in question simply is looking for a `key` with a specific value: SELECT * FROM cases_meta AS cm WHERE cm.`key` = 'PAN_NUMBER' AND cm.`value` = '153566' In this example, the table has 2.8 million records. In 10.5, it skips the `key` key, and grinds through 2.8 million records: ANALYZE: { "query_block": { "select_id": 1, "r_loops": 1, "r_total_time_ms": 2743.92693, "table": { "table_name": "cm", "access_type": "ALL", "possible_keys": ["key"], "r_loops": 1, "rows": 1004130, "r_rows": 2820048, "r_table_time_ms": 2548.916341, "r_other_time_ms": 195.0068087, "filtered": 30.31918144, "r_filtered": 0, "attached_condition": "ddx_lab_801615.cm.`key` = 'PAN_NUMBER' and ddx_lab_801615.cm.`value` = '153566'" } } } In 10.3, it uses the `key` key, and reads through a radically smaller subset of tables to fetch the result: ANALYZE: { "query_block": { "select_id": 1, "r_loops": 1, "r_total_time_ms": 357.84, "table": { "table_name": "cm", "access_type": "ref", "possible_keys": ["key"], "key": "key", "key_length": "152", "used_key_parts": ["key"], "ref": ["const"], "r_loops": 1, "rows": 304484, "r_rows": 155123, "r_total_time_ms": 340.94, "filtered": 100, "r_filtered": 0, "index_condition": "ddx_lab_801615.cm.`key` = 'PAN_NUMBER'", "attached_condition": "ddx_lab_801615.cm.`value` = '153566'" } } } I'm not sure why 10.5 is taking this substandard approach. Adding a USE INDEX (`key`) seems to have no effect in 10.5 either, it just skips the index. Any ideas? Thanks, Mike Confidentiality Notice: The information contained in this electronic message and any attachments to this message are intended only for the individual(s) addressed in the message and may contain proprietary and confidential information. If you are not the intended recipient, you should not disseminate, distribute, or copy this e-mail. Please notify the sender and destroy this message. WARNING: Computer viruses can be transmitted via email. The recipient should scan this email before opening it. The company accepts no liability for any damage caused by any virus transmitted by this email. Confidentiality Notice: The information contained in this electronic message and any attachments to this message are intended only for the individual(s) addressed in the message and may contain proprietary and confidential information. If you are not the intended recipient, you should not disseminate, distribute, or copy this e-mail. Please notify the sender and destroy this message. WARNING: Computer viruses can be transmitted via email. The recipient should scan this email before opening it. The company accepts no liability for any damage caused by any virus transmitted by this email.

2 3