- discuss - lists.mariadb.org

[Maria-discuss] Debian revision should not contain codename
by William Edwards 19 May '22

19 May '22

Hi, I'm attempting to upgrade a machine with MariaDB 10.6 from Buster to Bullseye using the official MariaDB repo. I was surprised to see that apt wanted to downgrade a few packages: ``` $ apt upgrade --without-new-pkgs The following packages will be DOWNGRADED: libmariadb-dev libmariadb-dev-compat libmariadb3 mysql-common ``` I was confused at first, as the priority of the candidate is higher, and the epoch is unchanged, and the upstream version is unchanged: ``` $ apt policy mysql-common mysql-common: Installed: 1:10.6.7+maria~buster Candidate: 1:10.6.7+maria~bullseye Version table: *** 1:10.6.7+maria~buster 100 100 /var/lib/dpkg/status 1:10.6.7+maria~bullseye 1000 1000 http://ams2.mirrors.digitalocean.com/mariadb/repo/10.6/debian bullseye/main amd64 Packages 1000 http://ams2.mirrors.digitalocean.com/mariadb/repo/10.6/debian bullseye/main arm64 Packages 1000 http://ams2.mirrors.digitalocean.com/mariadb/repo/10.6/debian bullseye/main ppc64el Packages 1:10.6.5+maria~bullseye 1000 1000 http://ams2.mirrors.digitalocean.com/mariadb/repo/10.6/debian bullseye/main amd64 Packages 1000 http://ams2.mirrors.digitalocean.com/mariadb/repo/10.6/debian bullseye/main arm64 Packages 1000 http://ams2.mirrors.digitalocean.com/mariadb/repo/10.6/debian bullseye/main ppc64el Packages 1:10.6.4+maria~bullseye 1000 1000 http://ams2.mirrors.digitalocean.com/mariadb/repo/10.6/debian bullseye/main amd64 Packages 1000 http://ams2.mirrors.digitalocean.com/mariadb/repo/10.6/debian bullseye/main arm64 Packages 1000 http://ams2.mirrors.digitalocean.com/mariadb/repo/10.6/debian bullseye/main ppc64el Packages 5.8+1.0.7 500 500 http://debmirror.tuxis.nl/debian bullseye/main amd64 Packages $ apt policy libmariadb3 libmariadb3: Installed: 1:10.6.7+maria~buster Candidate: 1:10.6.7+maria~bullseye Version table: *** 1:10.6.7+maria~buster 100 100 /var/lib/dpkg/status 1:10.6.7+maria~bullseye 1000 1000 http://ams2.mirrors.digitalocean.com/mariadb/repo/10.6/debian bullseye/main amd64 Packages 1:10.6.5+maria~bullseye 1000 1000 http://ams2.mirrors.digitalocean.com/mariadb/repo/10.6/debian bullseye/main amd64 Packages 1:10.6.4+maria~bullseye 1000 1000 http://ams2.mirrors.digitalocean.com/mariadb/repo/10.6/debian bullseye/main amd64 Packages 1:10.5.15-0+deb11u1 500 500 http://debmirror.tuxis.nl/debian bullseye/main amd64 Packages $ apt policy libmariadb-dev-compat libmariadb-dev-compat: Installed: 1:10.6.7+maria~buster Candidate: 1:10.6.7+maria~bullseye Version table: *** 1:10.6.7+maria~buster 100 100 /var/lib/dpkg/status 1:10.6.7+maria~bullseye 1000 1000 http://ams2.mirrors.digitalocean.com/mariadb/repo/10.6/debian bullseye/main amd64 Packages 1:10.6.5+maria~bullseye 1000 1000 http://ams2.mirrors.digitalocean.com/mariadb/repo/10.6/debian bullseye/main amd64 Packages 1:10.6.4+maria~bullseye 1000 1000 http://ams2.mirrors.digitalocean.com/mariadb/repo/10.6/debian bullseye/main amd64 Packages 1:10.5.15-0+deb11u1 500 500 http://debmirror.tuxis.nl/debian bullseye/main amd64 Packages $ apt policy libmariadb-dev libmariadb-dev: Installed: 1:10.6.7+maria~buster Candidate: 1:10.6.7+maria~bullseye Version table: *** 1:10.6.7+maria~buster 100 100 /var/lib/dpkg/status 1:10.6.7+maria~bullseye 1000 1000 http://ams2.mirrors.digitalocean.com/mariadb/repo/10.6/debian bullseye/main amd64 Packages 1:10.6.5+maria~bullseye 1000 1000 http://ams2.mirrors.digitalocean.com/mariadb/repo/10.6/debian bullseye/main amd64 Packages 1:10.6.4+maria~bullseye 1000 1000 http://ams2.mirrors.digitalocean.com/mariadb/repo/10.6/debian bullseye/main amd64 Packages 1:10.5.15-0+deb11u1 500 500 http://debmirror.tuxis.nl/debian bullseye/main amd64 Packages ``` A simulation also reported that apt would 'downgrade' to the same versions: ``` $ apt upgrade --without-new-pkgs -s Inst libmariadb-dev [1:10.6.7+maria~buster] (1:10.6.7+maria~bullseye MariaDB:ams2.mirrors.digitalocean.com [amd64]) [] Inst libmariadb-dev-compat [1:10.6.7+maria~buster] (1:10.6.7+maria~bullseye MariaDB:ams2.mirrors.digitalocean.com [amd64]) [] Inst libmariadb3 [1:10.6.7+maria~buster] (1:10.6.7+maria~bullseye MariaDB:ams2.mirrors.digitalocean.com [amd64]) Inst mysql-common [1:10.6.7+maria~buster] (1:10.6.7+maria~bullseye MariaDB:ams2.mirrors.digitalocean.com [all]) ``` Some folks on IRC pointed me to the fact that the Debian revision has been updated from `maria~buster` to `maria~bullseye`. The following documentation at https://www.debian.org/doc/debian-policy/ch-controlfields.html#special-vers… says: > The lexical comparison is a comparison of ASCII values modified so that > all the letters sort earlier than all the non-letters and so that a > tilde sorts before anything, even the end of a part. 'bul' comes before 'bus', so the package for Bullseye is perceived as older, despite it being the same effective upstream version... According to https://www.debian.org/doc/debian-policy/ch-controlfields.html#special-vers…, the Debian revision should NOT contain the Debian release codename. This problem will re-appear with Bookworm. Could the package maintainer(s) attend to this? -- With kind regards, William Edwards

2 2

Re: [Maria-discuss] MariaDB latest source tarballs missing
by Sergei Golubchik 19 May '22

19 May '22

Hi, Shreenidhi, On May 19, Shreenidhi Shedi wrote: > > I am from VMware Photon OS engineering team. > > We are trying to fix few CVEs that are being reported in 10.2.x & > 10.3.x versions of MariaDB. > > There is release note for v10.2.44 but I cannot find the source > tarball in downloads page or in github tags of maria db server. You cannot find it, because it wasn't released yet. > https://mariadb.com/kb/en/mariadb-10244-release-notes/ This page says, on the very top, in a red box: Note: This page describes features in the source repository for MariaDB 10.2. There are currently no official packages or binaries available for download which contain the features. If you want to try out any of the new features described here you will need to get and compile the code yourself. > Can you guys please help me out here? Where can I get the latest > released source tarballs? https://mariadb.org/download/ > Also, when can we expect a fix for this? If at all this is not > released, when can we expect next release of MariaDB server versions? Any day now. Regards, Sergei VP of MariaDB Server Engineering and security(a)mariadb.org

1 0

[Maria-discuss] Galera: jump through major versions at once
by William Edwards 19 May '22

19 May '22

Hi, Does Galera support rolling upgrades between multiple major versions? I will be upgrading my Galera cluster from MariaDB 10.3.34 to 10.6.x. It'd save a lot of time to jump straight from 10.3 to 10.6 instead of upgrading 10.3 -> 10.4 -> 10.5 -> 10.6. The documentation at https://mariadb.com/kb/en/upgrading-from-mariadb-103-to-mariadb-104-with-ga… implies that the MariaDB version is irrelevant, and only the Galera version matters. > Next, make sure that the Galera version numbers are compatible. > > If you are upgrading from the most recent MariaDB 10.3 release to > MariaDB 10.4, then the versions will > be compatible. MariaDB 10.3 uses Galera 3 (i.e. Galera wsrep provider > versions 25.3.x), and MariaDB > 10.4 uses Galera 4 (i.e. Galera wsrep provider versions 26.4.x). This > means that upgrading to MariaDB > 10.4 also upgrades the system to Galera 4. However, Galera 3 and Galera > 4 should be compatible for the > purposes of a rolling upgrade, as long as you are using Galera 26.4.2 > or later. -- With kind regards, William Edwards

2 3

[Maria-discuss] FLUSH TABLES ... FOR EXPORT SLOW
by mariadb＠Biblestuph.com 18 May '22

18 May '22

I've recently updated from 10.3.14 => 10.6.7, and am running into an issue where FLUSH TABLES ... FOR EXPORT is sometimes very slow on large tables. One particular table that it seems to happen on often is over 20G. It doesn't hang, per se; it will complete eventually, but can take an hour or more. 2022-05-17 0:14:06 105636 [Note] InnoDB: Sync to disk of `MyDB`.`t1` started. 2022-05-17 0:14:06 105636 [Note] InnoDB: Writing table metadata to './MyDB/t1.cfg' 2022-05-17 0:14:06 105636 [Note] InnoDB: Table `MyDB`.`t1` flushed to disk 2022-05-17 0:14:06 105636 [Note] InnoDB: Sync to disk of `MyDB`.`t2` started. 2022-05-17 1:49:53 105636 [Note] InnoDB: Writing table metadata to './MyDB/t2.cfg' 2022-05-17 1:49:53 105636 [Note] InnoDB: Table `MyDB`.`t2` flushed to disk in the above the obfuscated table name t2 took about 1.5 hours to complete. In the previous version (10.3.14), these were always nearly instantaneous, even for the largest tables. At the time I'm executing the FLUSH TABLES the slave is stopped on the DB and there are no other users logged in to the DB (other than myself). I know from the docs that FLUSH TABLES has seen changes since my previous version, but I'm not clear as to what the process is waiting for (or how to avoid it). Shutting down the server first (I have innodb_fast_shutdown = 0) seems to prevent it; and the shutdown generally only takes 5-10 minutes or so. But I'd rather not shutdown if I don't have to (and I'm not 100% convinced that I won't someday see the issue in that scenario, as well). I've also tried this sequence thinking it might help: ---> STOP SLAVE Wed May 18 10:30:13 2022 ---> SLAVE STOPPED Wed May 18 10:30:13 2022 ---> FLUSH LOCAL TABLES WITH READ LOCK Wed May 18 10:30:14 2022 ---> UNLOCK TABLES Wed May 18 10:30:15 2022 ---> SET GLOBAL innodb_purge_rseg_truncate_frequency = 1 Wed May 18 10:30:15 2022 ---> SET GLOBAL innodb_max_purge_lag_wait = 0 Wed May 18 10:30:15 2022 ---> FLUSH TABLES ... FOR EXPORT Wed May 18 10:30:15 2022 but the FLUSH TABLES FOR EXPORT still waits on that large table. Is there a way to make this happen quicker without requiring the DB to be shutdown first? Or am I missing something else in the process? Thanks, Dan

1 0

[Maria-discuss] A federation bug was identified.
by 최혁규 11 May '22

11 May '22

A federation bug was identified. I have confirmed that the select where query does not work in the multi index field of some federated tables. A field in the table is used as a multi index. My server version : 10.8.2-MariaDB However, there is no problem with the server used in the previous version. The previous version is Server version: 10.5.10-MariaDB. The tested method was compared by creating a federated table on two servers with different versions. 1. 10.5.10 - MariaDB -> All queries are normally searched. 2. 10.8.2 - MariaDB -> Symptoms were confirmed in some multi index types. --> The table field datatype is (int, datetime) This is the table I created and the select query. Table Created CREATE TABLE `fd_partner_detail` ( `partner_id` varchar(100) CHARACTER SET utf8mb3 NOT NULL DEFAULT '' COMMENT '파트너ID', `business_name` varchar(45) CHARACTER SET utf8mb3 NOT NULL DEFAULT '' COMMENT '사업자상호명', `business_no` varchar(45) CHARACTER SET utf8mb3 NOT NULL DEFAULT '' COMMENT '사업자번호', `online_marketing_business_no` varchar(45) NOT NULL DEFAULT '' COMMENT '통신판매업 신고번호', `representative` varchar(45) CHARACTER SET utf8mb3 NOT NULL DEFAULT '' COMMENT '대표자명', `business_category` char(50) CHARACTER SET utf8mb3 NOT NULL DEFAULT '' COMMENT '종목', `business_status` char(50) CHARACTER SET utf8mb3 NOT NULL DEFAULT '' COMMENT '업종형태', `contact` varchar(45) CHARACTER SET utf8mb3 NOT NULL DEFAULT '' COMMENT '연락처', `courier_code` varchar(45) NOT NULL DEFAULT '0' COMMENT '택배사코드', `postal_code` varchar(45) DEFAULT NULL COMMENT '우편번호', `address` varchar(45) DEFAULT NULL COMMENT '주소(도로명)', `address_detail` varchar(45) DEFAULT NULL COMMENT '상세주소', `officer` varchar(45) CHARACTER SET utf8mb3 NOT NULL DEFAULT '' COMMENT '대표담당자명', `officer_contact` varchar(45) CHARACTER SET utf8mb3 NOT NULL DEFAULT '' COMMENT '대표담당자연락처', `officer_email` varchar(45) CHARACTER SET utf8mb3 NOT NULL DEFAULT '' COMMENT '대표담당자이메일', `order_officer` varchar(45) CHARACTER SET utf8mb3 DEFAULT '' COMMENT '발주담당자명', `order_officer_contact` varchar(45) CHARACTER SET utf8mb3 DEFAULT '' COMMENT '발주담당자연락처', `order_officer_email` varchar(45) CHARACTER SET utf8mb3 DEFAULT '' COMMENT '발주담당자이메일', `calculate_order_officer` varchar(45) CHARACTER SET utf8mb3 DEFAULT '' COMMENT '정산담당자명', `calculate_officer_contact` varchar(45) CHARACTER SET utf8mb3 DEFAULT '' COMMENT '정산담당자연락처', `calculate_officer_email` varchar(45) CHARACTER SET utf8mb3 DEFAULT '' COMMENT '정산담당자이메일', `cs_order_officer` varchar(45) CHARACTER SET utf8mb3 DEFAULT '' COMMENT 'CS담당자명', `cs_officer_contact` varchar(45) CHARACTER SET utf8mb3 DEFAULT '' COMMENT 'CS담당자연락처', `cs_officer_email` varchar(45) CHARACTER SET utf8mb3 DEFAULT '' COMMENT 'CS담당자이메일', `product_name` varchar(100) CHARACTER SET utf8mb3 NOT NULL DEFAULT '' COMMENT '대표상품명', `product_url` varchar(255) CHARACTER SET utf8mb3 NOT NULL DEFAULT '' COMMENT '대표상품URL', `product_type` int(1) NOT NULL DEFAULT 0 COMMENT '대표상품제조구분 (1: 제조, 2:벤더)', `add_product_name_1` varchar(100) CHARACTER SET utf8mb3 DEFAULT '' COMMENT '선택상품명1', `add_product_url_1` varchar(255) CHARACTER SET utf8mb3 DEFAULT '' COMMENT '선택상품URL1', `add_product_type_1` int(1) DEFAULT 0 COMMENT '선택상품제조구분1', `add_product_name_2` varchar(100) CHARACTER SET utf8mb3 DEFAULT '' COMMENT '선택상품명2', `add_product_url_2` varchar(255) CHARACTER SET utf8mb3 DEFAULT '' COMMENT '선택상품URL2', `add_product_type_2` int(1) DEFAULT 0 COMMENT '선택상품제조구분2', `calculate_bank_code` varchar(45) NOT NULL DEFAULT '' COMMENT '정산은행코드', `calculate_bank_no` varchar(45) NOT NULL DEFAULT '' COMMENT '정산계좌번호', `calculate_bank_name` varchar(45) NOT NULL DEFAULT '' COMMENT '정산예금주명', `file_bankbook` varchar(255) DEFAULT '' COMMENT '통장사본', `original_bankbook` varchar(255) DEFAULT '' COMMENT '통장사본원본명', `file_business_license` varchar(255) DEFAULT '' COMMENT '사업자등록증', `original_business_license` varchar(255) DEFAULT '' COMMENT '사업자등록증원본명', `file_document` varchar(255) DEFAULT '' COMMENT '기타서류', `original_document` varchar(255) DEFAULT '' COMMENT '기타서류원본명', `is_terms_service` int(1) NOT NULL DEFAULT 0 COMMENT '쇼핑몰이용약관동의여부', `is_privacy_consent` int(1) NOT NULL DEFAULT 0 COMMENT '개인정보처리방침동의여부', `join_status` int(1) NOT NULL DEFAULT 1 COMMENT '가입승인상태(1: 입점대기, 2: 입점반려, 3:입점승인, 4:입점불가)', `return_cause` text CHARACTER SET utf8mb3 DEFAULT NULL COMMENT '가입반려사유', `calculate_type` int(1) NOT NULL DEFAULT 1 COMMENT '정산주기유형(1:15일, 2:30일)', `dormant_change_date` datetime DEFAULT NULL COMMENT '휴면전환일', `dormant_cancel_date` datetime DEFAULT NULL COMMENT '휴면해제일', `join_date` datetime DEFAULT NULL COMMENT '가입승인일', `is_withdraw` int(1) NOT NULL DEFAULT 0 COMMENT '탈퇴회원여부', `introduce` text DEFAULT NULL COMMENT '회사소개', `memo` varchar(255) DEFAULT '' COMMENT '관리자 메모', `corporation_code` varchar(45) CHARACTER SET utf8mb3 NOT NULL COMMENT '회사코드', `marketplace_code` varchar(45) CHARACTER SET utf8mb3 NOT NULL COMMENT '쇼핑몰코드', `is_abolished` int(1) NOT NULL DEFAULT 0 COMMENT '삭제여부', `is_popup` int(1) DEFAULT 0 COMMENT '입점 승인', `application_code` varchar(45) CHARACTER SET utf8mb3 DEFAULT NULL COMMENT '어플리케이션코드', `created_by` varchar(45) CHARACTER SET utf8mb3 DEFAULT NULL COMMENT '생성자', `created_date` datetime DEFAULT NULL COMMENT '생성일', `modified_by` varchar(45) CHARACTER SET utf8mb3 DEFAULT NULL COMMENT '수정자', `modified_date` datetime DEFAULT NULL COMMENT '수정일', `abolished_by` varchar(45) CHARACTER SET utf8mb3 DEFAULT NULL COMMENT '삭제자', `abolished_date` datetime DEFAULT NULL COMMENT '삭제일', PRIMARY KEY (`partner_id`), KEY `IDX_R_1` (`is_abolished`), KEY `IDX_R_2` (`created_date`), KEY `IDX_U_1` (`courier_code`), KEY `IDX_U_2` (`postal_code`), KEY `IDX_U_3` (`calculate_bank_code`) ) ENGINE=FEDERATED DEFAULT CHARSET=utf8mb4 ROW_FORMAT=DYNAMIC COMMENT='파트너상세정보' CONNECTION='fdc_partner_bh/fo_partner_detail' Table Select Query SELECT business_no, representative, business_name, contact, partner_id ,is_abolished FROM fd_partner_detail WHERE created_date = '1'; Select Query Result business_no representative business_name contact partner_id is_abolished ----------- -------------- ------------- ------- ---------- -------------- I want to know if what I checked is a bug.

2 1

[Maria-discuss] mariabackup is slow (log scanned up to)
by John Pace 29 Apr '22

29 Apr '22

Hi, I am using mariabackup to backup a database. On day 1 a full backup with mariabackup --backup --user=Backup --password=my-password --target-dir=path-to-full and on day 2-7 a incremental backup with mariabackup --backup --user=Backup --password=my-password --target-dir=path-to-inc --incremental-basedir=path-to-full Then follows again a new backup for day 1 and so on. The database can be used while the backup is running. A web application for Apache Tomcat uses the database. This worked very well for a couple of weeks, the backup was finished within 20 minutes. But recently I noticed that the incremental backup took much longer than before. I checked the output of mariabackup and it was spammed several hours with lines like these [00] 2022-04-20 00:48:00 >> log scanned up to (1747989580536) [00] 2022-04-20 00:48:01 >> log scanned up to (1747989580536) [00] 2022-04-20 00:48:02 >> log scanned up to (1747989580536) 2022-04-20 0:48:03 0 [Note] InnoDB: Read redo log up to LSN=1747989580800 [00] 2022-04-20 00:48:03 >> log scanned up to (1747989580536) [00] 2022-04-20 00:48:04 >> log scanned up to (1747989580536) [00] 2022-04-20 00:48:05 >> log scanned up to (1747989580536) [00] 2022-04-20 00:48:06 >> log scanned up to (1747989580536) Yesterday the incremental backup took 7 hours so I wonder if there is something wrong. MariaDB shows no error in the log: 2022-03-15 8:35:48 0 [Note] InnoDB: Using Linux native AIO 2022-03-15 8:35:48 0 [Note] InnoDB: Uses event mutexes 2022-03-15 8:35:48 0 [Note] InnoDB: Compressed tables use zlib 1.2.11 2022-03-15 8:35:48 0 [Note] InnoDB: Number of pools: 1 2022-03-15 8:35:48 0 [Note] InnoDB: Using crc32 + pclmulqdq instructions 2022-03-15 8:35:48 0 [Note] InnoDB: Initializing buffer pool, total size = 134217728, chunk size = 134217728 2022-03-15 8:35:48 0 [Note] InnoDB: Completed initialization of buffer pool 2022-03-15 8:35:48 0 [Note] InnoDB: If the mysqld execution user is authorized, page cleaner thread priority can be changed. See the man page of setpriority(). 2022-03-15 8:35:49 0 [Note] InnoDB: 128 rollback segments are active. 2022-03-15 8:35:49 0 [Note] InnoDB: Creating shared tablespace for temporary tables 2022-03-15 8:35:49 0 [Note] InnoDB: Setting file './ibtmp1' size to 12 MB. Physically writing the file full; Please wait ... 2022-03-15 8:35:49 0 [Note] InnoDB: File './ibtmp1' size is now 12 MB. 2022-03-15 8:35:49 0 [Note] InnoDB: 10.5.8 started; log sequence number 1741176510061; transaction id 38228169 2022-03-15 8:35:49 0 [Note] Plugin 'FEEDBACK' is disabled. 2022-03-15 8:35:49 0 [Note] InnoDB: Loading buffer pool(s) from /path-to-database/ib_buffer_pool 2022-03-15 8:35:49 0 [Note] Server socket created on IP: '::'. 2022-03-15 8:35:50 0 [Note] InnoDB: Buffer pool(s) load completed at 220315 8:35:50 2022-03-15 8:35:50 0 [Note] /path-to-mariadb/bin/mariadbd: ready for connections. Version: '10.5.8-MariaDB' socket: '/tmp/mysql.sock' port: 3306 MariaDB Server PS: Sorry for my test-post. ------------------------------------------------------------------------------------------------- FreeMail powered by mail.de - MEHR SICHERHEIT, SERIOSITÄT UND KOMFORT

1 0

[Maria-discuss] test
by John Pace 29 Apr '22

29 Apr '22

------------------------------------------------------------------------------------------------- FreeMail powered by mail.de - MEHR SICHERHEIT, SERIOSITÄT UND KOMFORT

1 0

[Maria-discuss] Understanding SQL queries
by João Paulo Almeida 14 Apr '22

14 Apr '22

Dear MariaDB Users, We are currently carrying out some research on the understanding and usability of different relational schemas (as part of a Ph.D. student's thesis work). We would like to invite you to contribute to this research by answering a small number of questions on SQL query interpretation. Participation is via an anonymous form and there are only 7 questions, so it should not take more than 10 minutes of your time: https://forms.gle/EA2jYGf4CTmLfEiaA We thank you in advance and would appreciate it if you could also share this research with colleagues who also have a background on SQL. thank you, João Paulo A. Almeida Federal University of Espírito Santo

2 1

[Maria-discuss] mysql 5.5 client vs mariadb 10 server
by Oliver 22 Mar '22

22 Mar '22

Hi, I'm sorry for the question if it is clear that it isn't possible. I'm trying connect from a mysql 5.5.56 client against a mariadb 10 server and I'm having the next error: ERROR 2003 (HY000): Can't connect to MySQL server on 'server' (10061) Subnet source is allowed in mariadb server and grant is given for 'root'@'source_server', it is allowed both IP and hostname. So not sure if it is config problem or compatibility problem. Someone knows please? Thanks beforehand. P.D.: I can connect using dbeaver from my computer client using mysql binaries (but not sure what mysql client version uses dbeaver). Cheers...

4 5

[Maria-discuss] History Length: Purge-able vs. Not Purge-able metrics
by mariadb＠Biblestuph.com 10 Mar '22

10 Mar '22

Greetings, I know I can get the current undo log history length via: > show status like '%history%'; +----------------------------+-------+ | Variable_name | Value | +----------------------------+-------+ | Innodb_history_list_length | 854 | +----------------------------+-------+ but my understanding is that at any given point in time that number represents both the records that can be purged because they are no longer needed by any current transactions (and the purge threads for whatever reason haven't gotten to them yet), as well as those that cannot be purged yet because there are current transactions running that may still need them. So the question is, is there any way to know the difference between those two? I.E., how many are waiting to be purged and how many cannot yet be purged? And a related question. Will the undo log size (the physical size of the file) grow even when there are many entries in the history that can be purged first? Or are those unneeded records purged first and that space reused before the undo log is made larger? Or perhaps I'm mis-understanding the process? TIA, Dan

1 0