Re: [Maria-discuss] Maria-db refuses to start
If you want protection from your database files being corrupted then you need to implement it. If you do nothing then you'll have no protection. You did nothing and your data got corrupted. There are lots of "best practices" for database administration to deal with this and it appears that you followed none of them. This is nobody's problem but yours - own it. ___ Mailing list: https://launchpad.net/~maria-discuss Post to : maria-discuss@lists.launchpad.net Unsubscribe : https://launchpad.net/~maria-discuss More help : https://help.launchpad.net/ListHelp
Re: [Maria-discuss] Maria-db refuses to start
On Fri, Dec 9, 2022 at 2:43 AM Reindl Harald wrote: > > If you're concerned about database corruption then you need to start off > > by having multiple copies of the data available in an online state if > > you want to recover from corrupt data without doing a backup. > > completly different topic > > > This is > > what ZFS does with RAID - detects which block is corrupt and then uses > > other data blocks, including parity, to rebuild the corrupt block. > > completly different layers > > > MariaDB isn't designed for that. I'm not even sure if there is any > > database that's designed for that, including SQL Server (see below for > > more.) > > the topic was "Some of us run MariaDB on file systems that do their own > block checksumming, and thus run innodb_checksum_algorithm=none" where > you mix two completly independent layers and now we have two morons Virtually all data corruption that occurs happens in the disk layer, not the database internals layer. This is the reality you seem to be struggling to grasp. If address the problem of corruption in the disk layer, the usefulness of additionally checking in a place that is only useful for internals debugging is vanishingly narrow. ___ Mailing list: https://launchpad.net/~maria-discuss Post to : maria-discuss@lists.launchpad.net Unsubscribe : https://launchpad.net/~maria-discuss More help : https://help.launchpad.net/ListHelp
Re: [Maria-discuss] Maria-db refuses to start
On Fri, Dec 9, 2022 at 2:40 AM Reindl Harald wrote: > >>> 2.2) Database doesn't crash because the damage merely corrupts a > >>> single value but the record structure remains sound. > >>> > >>> So it is that 2.2) point where the InnoDB checksum gives you anything > >> > >> moron it don't matter if you find it useful - the whole point was that > >> you pretended the filesystem can do the same with it's checksums which > >> is nonsense > > > > You are conveniently ignoring the fact that in the vast majority of > > cases what InnoDB checksums will catch is silent disk corruption > > rather than database internals corruption. > > i ignore nothing but filesystem corruption is still a different topic > > > So the one narrow edge case you are clinging to as the full > > justification of your abusive behaviour and delusions of grandeur are > > a tiny fraction of a percent of the errors that will cause InnoDB > > checksums to fail - and outside that narrow edge case all of the rest > > of them will be caught and handled better at layers below the database > > itself. > > the topic was and still is "Some of us run MariaDB on file systems that > do their own block checksumming, and thus run > innodb_checksum_algorithm=none" where you mix two completly independent > layers > > > So either you are arguing in bad faith, or you really are extensively > > ignorant of typical failure patterns. > > the topic was and still is "Some of us run MariaDB on file systems that > do their own block checksumming, and thus run > innodb_checksum_algorithm=none" where you mix two completly independent > layers They are different layers, but 99.9%+ of corruption that InnoDB checksums ever detects occur in the storage layer, not in the database internals layer. So in terms of the overall picture of the corruption cause probability landscape which you seem to be struggling to see, you are about 0.1% correct. I'll grant you that. I'll go as far as hazarding a guess that InnoDB checkums were originally added with the main motivation of detecting disk corruption rather than internals debugging. Unfortunately, the code tree back in 3.23.24 (as far as I can tell the release where InnoDB was merged) doesn't seem to contain any annotations on the subject that might shed light on the original motivation. ___ Mailing list: https://launchpad.net/~maria-discuss Post to : maria-discuss@lists.launchpad.net Unsubscribe : https://launchpad.net/~maria-discuss More help : https://help.launchpad.net/ListHelp
Re: [Maria-discuss] Maria-db refuses to start
Am 08.12.22 um 23:53 schrieb martin doc: If you're concerned about database corruption then you need to start off by having multiple copies of the data available in an online state if you want to recover from corrupt data without doing a backup. completly different topic This is what ZFS does with RAID - detects which block is corrupt and then uses other data blocks, including parity, to rebuild the corrupt block. completly different layers MariaDB isn't designed for that. I'm not even sure if there is any database that's designed for that, including SQL Server (see below for more.) the topic was "Some of us run MariaDB on file systems that do their own block checksumming, and thus run innodb_checksum_algorithm=none" where you mix two completly independent layers and now we have two morons ___ Mailing list: https://launchpad.net/~maria-discuss Post to : maria-discuss@lists.launchpad.net Unsubscribe : https://launchpad.net/~maria-discuss More help : https://help.launchpad.net/ListHelp
Re: [Maria-discuss] Maria-db refuses to start
Am 08.12.22 um 23:55 schrieb Gordan Bobic: On Fri, Dec 9, 2022 at 12:31 AM Reindl Harald wrote: 2.2) Database doesn't crash because the damage merely corrupts a single value but the record structure remains sound. So it is that 2.2) point where the InnoDB checksum gives you anything moron it don't matter if you find it useful - the whole point was that you pretended the filesystem can do the same with it's checksums which is nonsense You are conveniently ignoring the fact that in the vast majority of cases what InnoDB checksums will catch is silent disk corruption rather than database internals corruption. i ignore nothing but filesystem corruption is still a different topic So the one narrow edge case you are clinging to as the full justification of your abusive behaviour and delusions of grandeur are a tiny fraction of a percent of the errors that will cause InnoDB checksums to fail - and outside that narrow edge case all of the rest of them will be caught and handled better at layers below the database itself. the topic was and still is "Some of us run MariaDB on file systems that do their own block checksumming, and thus run innodb_checksum_algorithm=none" where you mix two completly independent layers So either you are arguing in bad faith, or you really are extensively ignorant of typical failure patterns. the topic was and still is "Some of us run MariaDB on file systems that do their own block checksumming, and thus run innodb_checksum_algorithm=none" where you mix two completly independent layers ___ Mailing list: https://launchpad.net/~maria-discuss Post to : maria-discuss@lists.launchpad.net Unsubscribe : https://launchpad.net/~maria-discuss More help : https://help.launchpad.net/ListHelp
Re: [Maria-discuss] Maria-db refuses to start
On Fri, Dec 9, 2022 at 12:31 AM Reindl Harald wrote: > > 2.2) Database doesn't crash because the damage merely corrupts a > > single value but the record structure remains sound. > > > > So it is that 2.2) point where the InnoDB checksum gives you anything > > moron it don't matter if you find it useful - the whole point was that > you pretended the filesystem can do the same with it's checksums which > is nonsense You are conveniently ignoring the fact that in the vast majority of cases what InnoDB checksums will catch is silent disk corruption rather than database internals corruption. So the one narrow edge case you are clinging to as the full justification of your abusive behaviour and delusions of grandeur are a tiny fraction of a percent of the errors that will cause InnoDB checksums to fail - and outside that narrow edge case all of the rest of them will be caught and handled better at layers below the database itself. So either you are arguing in bad faith, or you really are extensively ignorant of typical failure patterns. ___ Mailing list: https://launchpad.net/~maria-discuss Post to : maria-discuss@lists.launchpad.net Unsubscribe : https://launchpad.net/~maria-discuss More help : https://help.launchpad.net/ListHelp
Re: [Maria-discuss] Maria-db refuses to start
If you're concerned about database corruption then you need to start off by having multiple copies of the data available in an online state if you want to recover from corrupt data without doing a backup. This is what ZFS does with RAID - detects which block is corrupt and then uses other data blocks, including parity, to rebuild the corrupt block. MariaDB isn't designed for that. I'm not even sure if there is any database that's designed for that, including SQL Server (see below for more.) If you want to protect against silent data corruption now there are some alternatives: 1) implement record level checksums that you calculate and verify. This would require adding a "checksum" field to all of your tables. Maybe hide them with stored procedures. This is the best way for you to detect silent data corruption to your data. It won't fix data corruption. 2) implement application logic to always store data in 2+ databases and write an application to verify that all copies of the data are the same (think of this as being the application of a ZFS scrub.) E.g. Using Microsoft Witness Server's with mirror'd SQL databases: https://learn.microsoft.com/en-us/sql/database-engine/database-mirroring/database-mirroring-witness?view=sql-server-ver16 The above (1) and (2) won't prevent metadata that the database uses to hold your data from being corrupted. That'd require changes to the page table structures used by InnoDB, etc. On top of that, putting checksums in the page tables wouldn't necessarily detect corruption to your data that happens before it gets included in the page's checksum calculation. If you want to detect corruption of data that is returned over a TCP connection to a remote database then you need record level checksums - see (1) above. You might even decide to do both (1) and (2) - add checksums to your tables and develop your application to always store (INSERT) all data in 2 different databases (potentially on different servers) and develop the application to query the other database/server if there's a checksum failure when returning data from the first source. Having multiple databases on different servers also protects you from problems with upgrades, etc, as long as your procedures validate each database is sound before making them "live". You have to take ownership of the risk for only keeping one copy of critical data. You have to take ownership of the risk for not keeping current backups of your database. Data resiliency requires effort. If you don't put in any effort then you won't get much in the way of resiliency from corruption. That btw includes good practice for doing ugprades, shutdowns, etc. MariaDB has as much resiliency to silent data corruption as you put in effort to mitigate it. ___ Mailing list: https://launchpad.net/~maria-discuss Post to : maria-discuss@lists.launchpad.net Unsubscribe : https://launchpad.net/~maria-discuss More help : https://help.launchpad.net/ListHelp
Re: [Maria-discuss] Maria-db refuses to start
Am 08.12.22 um 22:32 schrieb Gordan Bobic: On Thu, Dec 8, 2022 at 10:59 PM Reindl Harald wrote: What is the net benefit of detecting said error? The way I see it, the options are: 1) MariaDB detects and error, crashes out 2) MariaDB doesn't detect an error, ingests garbage, crashes out silent data corruption At what layer? If at anything below, up to and including the file system level, ZFS will detect and correct it for you. MariaDB can at best only detect it for you. So catching it at a lower level wins. The only way an error will creep in without the error checking FS spotting it is: 1) manually corrupting the block by writing garbage over it 2) MariaDB generated a duff block and wrote it out 3) Some other hardware failure corrupted the block in MariaDB memory, just before writing it to the file system If any of the latter set happens, the data is toast anyway. If the former set happens, the data is toast anyway. silent data corruption At what layer? on the database layer itself If at anything below, up to and including the file system level, ZFS will detect and correct it for you are you really that dumb that you don't understand that the filesystem don't matter here? MariaDB can at best only detect it for you. So catching it at a lower level wins. that layer can't do anything about databse internals moron the files are fine from the viewpoint of the filessystem At what layer? the database layer moron If at anything below, up to and including the file system level, ZFS will detect and correct it for you different layer moron moron the files are fine from the viewpoint of the filessystem AGAIN: THE FILESYSTEM CAN'T DO ANYTHING BECAUSE IT'S NOT AFFECTED So your argument is that the page checksum is there to tell you that your data is corrupted because of either: 1) data was corrupted by the database itself, or 2) a superuser overwriting the block on the disk and it's impressive how long it takes until you mororn understand such basics And in that case what exactly will the ckecksum do for you? let you notice you have a problem and need backups What do you gain from it? The error message that the block is corrupted just before the database crashes? know that your data are damaged instead growing silent corruption 2) InnoDB has no checksums. Database steps on the duff block. 2.1) Database crashes during a query. You get the query and tables accessed during a stack trace. You run a check table and it finds a corrupted table. You restore it from backup and without that over time you have no backup without the problem and even if you have one nobody wants a backup from months ago not containg any recent data 2.2) Database doesn't crash because the damage merely corrupts a single value but the record structure remains sound. So it is that 2.2) point where the InnoDB checksum gives you anything moron it don't matter if you find it useful - the whole point was that you pretended the filesystem can do the same with it's checksums which is nonsense ___ Mailing list: https://launchpad.net/~maria-discuss Post to : maria-discuss@lists.launchpad.net Unsubscribe : https://launchpad.net/~maria-discuss More help : https://help.launchpad.net/ListHelp
Re: [Maria-discuss] Maria-db refuses to start
On Thu, Dec 8, 2022 at 10:59 PM Reindl Harald wrote: > > the next reply-all clown boy i am subsribed so you can just respond > to the list You sure whine a lot about inconsequential things. > Am 08.12.22 um 21:13 schrieb Gordan Bobic: > > On Thu, Dec 8, 2022 at 9:42 PM Reindl Harald wrote: > >> > >> Am 08.12.22 um 18:59 schrieb Gordan Bobic: > >>> On Thu, Dec 8, 2022 at 7:28 PM Reindl Harald > >>> wrote: > MariaDB does the same as the filesystem > InnoDB in fact is more ore less a FS on top of a FS > >>> > >>> So why do it at both levels? > >> > >> because the FS layer can't detect MariaDB errors? > > > > What is the net benefit of detecting said error? The way I see it, the > > options are: > > 1) MariaDB detects and error, crashes out > > 2) MariaDB doesn't detect an error, ingests garbage, crashes out > > silent data corruption At what layer? If at anything below, up to and including the file system level, ZFS will detect and correct it for you. MariaDB can at best only detect it for you. So catching it at a lower level wins. > > The only way an error will creep in without the error checking FS > > spotting it is: > > 1) manually corrupting the block by writing garbage over it > > 2) MariaDB generated a duff block and wrote it out > > 3) Some other hardware failure corrupted the block in MariaDB memory, > > just before writing it to the file system > > > > If any of the latter set happens, the data is toast anyway. > > If the former set happens, the data is toast anyway. > > silent data corruption At what layer? If at anything below, up to and including the file system level, ZFS will detect and correct it for you. MariaDB can at best only detect it for you. So catching it at a lower level wins. > > Sure it's nice to get an error that confirms that your data is > > corrupted, but that won't bring it back > silent data corruption > > > Shift it down to a layer where at least a subset of the problemspace > > can be fixed and we have a net gain in at least some cases. > > different world A far better world that you seem have a hard time accepting exists. > >>> And what makes doing it at MariaDB level > >>> in any way better than doing it somewhere else? > >> > >> which magic should do it somewehre else? > > > > If a file system is in control of data mirroring and checksumming > > every 16KB block, then if the data is corrupted on disk, file system > > will detect it on a read and fetch a good copy from an uncorrupted > > mirror. > > moron the files are fine from the viewpoint of the filessystem At what layer? If at anything below, up to and including the file system level, ZFS will detect and correct it for you. MariaDB can at best only detect it for you. So catching it at a lower level wins. I am talking about total cumulative data integrity up to and including what MariaDB reads from disks. What layer in the stack, exactly, are you trying to fight "silent data corruption" you mentioned above? > > Application never knows something went wrong, file system replaces the > > corrupted block on the other disk and everything carries on > > uninterrupted. > > moron the files are fine from the viewpoint of the filessystem > > >> AGAIN: THE FILESYSTEM CAN'T DO ANYTHING BECAUSE IT'S NOT AFFECTED > > > > So your argument is that the page checksum is there to tell you that > > your data is corrupted because of either: > > 1) data was corrupted by the database itself, or > > 2) a superuser overwriting the block on the disk > > and it's impressive how long it takes until you mororn understand such > basics And in that case what exactly will the ckecksum do for you? What do you gain from it? The error message that the block is corrupted just before the database crashes? > > In either case, you are not getting the data back either way the the > > database will stop working. > > yes, but it's a difference if you have silent data corruption detectet > months later when clean backups are gone because retention times > > > So what is the point? I'd rather have the error fixable > > moron your filesystem can't fix that type of error > > that's why "Some of us run MariaDB on file systems that do their own > block checksumming, and thus run innodb_checksum_algorithm=none" was an > idiots response > > a different response would have been "i don't think that i need innodb > checksums and want to disable it" but you moron pretended your > filesystem does the same Let's look at the scenarios here, assuming a block gets corrupted: 1) InnoDB has checksums. 1.1) Database doesn't step on the duff block, error doesn't get detected. Until long after your backup retention expired. 1.2) Data corruption happens in memory before the checksum is calculated. Checksum is based on corrupted data and doesn't help you. 2) InnoDB has no checksums. Database steps on the duff block. 2.1) Database crashes during a query. You get the query and tables accessed during a stack trace. You run a check table and it finds a
Re: [Maria-discuss] Maria-db refuses to start
the next reply-all clown boy i am subsribed so you can just respond to the list Am 08.12.22 um 21:13 schrieb Gordan Bobic: On Thu, Dec 8, 2022 at 9:42 PM Reindl Harald wrote: Am 08.12.22 um 18:59 schrieb Gordan Bobic: On Thu, Dec 8, 2022 at 7:28 PM Reindl Harald wrote: MariaDB does the same as the filesystem InnoDB in fact is more ore less a FS on top of a FS So why do it at both levels? because the FS layer can't detect MariaDB errors? What is the net benefit of detecting said error? The way I see it, the options are: 1) MariaDB detects and error, crashes out 2) MariaDB doesn't detect an error, ingests garbage, crashes out silent data corruption The only way an error will creep in without the error checking FS spotting it is: 1) manually corrupting the block by writing garbage over it 2) MariaDB generated a duff block and wrote it out 3) Some other hardware failure corrupted the block in MariaDB memory, just before writing it to the file system If any of the latter set happens, the data is toast anyway. If the former set happens, the data is toast anyway. silent data corruption Sure it's nice to get an error that confirms that your data is corrupted, but that won't bring it back silent data corruption Shift it down to a layer where at least a subset of the problemspace can be fixed and we have a net gain in at least some cases. different world And what makes doing it at MariaDB level in any way better than doing it somewhere else? which magic should do it somewehre else? If a file system is in control of data mirroring and checksumming every 16KB block, then if the data is corrupted on disk, file system will detect it on a read and fetch a good copy from an uncorrupted mirror. moron the files are fine from the viewpoint of the filessystem Application never knows something went wrong, file system replaces the corrupted block on the other disk and everything carries on uninterrupted. moron the files are fine from the viewpoint of the filessystem AGAIN: THE FILESYSTEM CAN'T DO ANYTHING BECAUSE IT'S NOT AFFECTED So your argument is that the page checksum is there to tell you that your data is corrupted because of either: 1) data was corrupted by the database itself, or 2) a superuser overwriting the block on the disk and it's impressive how long it takes until you mororn understand such basics In either case, you are not getting the data back either way the the database will stop working. yes, but it's a difference if you have silent data corruption detectet months later when clean backups are gone because retention times So what is the point? I'd rather have the error fixable moron your filesystem can't fix that type of error that's why "Some of us run MariaDB on file systems that do their own block checksumming, and thus run innodb_checksum_algorithm=none" was an idiots response a different response would have been "i don't think that i need innodb checksums and want to disable it" but you moron pretended your filesystem does the same than have the knowledge that I have an error I can do nothing about moron your filesystem can't fix that type of error and you won't be aware that you have a problem not matter what FS you are using ___ Mailing list: https://launchpad.net/~maria-discuss Post to : maria-discuss@lists.launchpad.net Unsubscribe : https://launchpad.net/~maria-discuss More help : https://help.launchpad.net/ListHelp
Re: [Maria-discuss] Maria-db refuses to start
On Thu, Dec 8, 2022 at 9:42 PM Reindl Harald wrote: > > > > Am 08.12.22 um 18:59 schrieb Gordan Bobic: > > On Thu, Dec 8, 2022 at 7:28 PM Reindl Harald wrote: > >> MariaDB does the same as the filesystem > >> InnoDB in fact is more ore less a FS on top of a FS > > > > So why do it at both levels? > > because the FS layer can't detect MariaDB errors? What is the net benefit of detecting said error? The way I see it, the options are: 1) MariaDB detects and error, crashes out 2) MariaDB doesn't detect an error, ingests garbage, crashes out The only way an error will creep in without the error checking FS spotting it is: 1) manually corrupting the block by writing garbage over it 2) MariaDB generated a duff block and wrote it out 3) Some other hardware failure corrupted the block in MariaDB memory, just before writing it to the file system If any of the latter set happens, the data is toast anyway. If the former set happens, the data is toast anyway. Sure it's nice to get an error that confirms that your data is corrupted, but that won't bring it back. Shift it down to a layer where at least a subset of the problemspace can be fixed and we have a net gain in at least some cases. > > And what makes doing it at MariaDB level > > in any way better than doing it somewhere else? > > which magic should do it somewehre else? If a file system is in control of data mirroring and checksumming every 16KB block, then if the data is corrupted on disk, file system will detect it on a read and fetch a good copy from an uncorrupted mirror. Application never knows something went wrong, file system replaces the corrupted block on the other disk and everything carries on uninterrupted. > >> "Some of us run MariaDB on file systems that do their own block > >> checksumming, and thus run innodb_checksum_algorithm=none" makes you > >> looking like a fool - period > >> > >> are you dumb or why don't you understand that the filesystem is a > >> completly different layer and has no clue about the data itself? > > > > Are you too dumb to understand that if a block is corrupted at InnoDB > > level MariaDB can't do anyting to fix it, but if a block is corrupted > > at lower level, ZFS can fix it from redundantly stored data and > > MariaDB never gets to ingest a corrupted block in the first place? > > it can at least fail early instead work with corrupted data > > > If you disagree, please describe a scenario in which an InnoDB page > > checksum does anything useful if the file system it is on has built in > > block checksumming and data redundancy. > INNDOB CHECKSUMS DETECT DATA CORRUPTION WITHIN MARIADB NOT CAUSED BY ANY > FILESYSTEM ISSUE AT ALL > > the filesystem can't do that with it's block checksumming and data > redundancy because there is *nothing wrong* for the view of the FS layer > > one is for consistency of the database > one is for consistency of the underlying filesystem > > two worlds and i simply don't get why people not understanding such > basics work in the IT but to top that talking nonsense on mailing-lists > > AGAIN: THE FILESYSTEM CAN'T DO ANYTHING BECAUSE IT'S NOT AFFECTED So your argument is that the page checksum is there to tell you that your data is corrupted because of either: 1) data was corrupted by the database itself, or 2) a superuser overwriting the block on the disk In either case, you are not getting the data back either way the the database will stop working. So what is the point? I'd rather have the error fixable than have the knowledge that I have an error I can do nothing about. ___ Mailing list: https://launchpad.net/~maria-discuss Post to : maria-discuss@lists.launchpad.net Unsubscribe : https://launchpad.net/~maria-discuss More help : https://help.launchpad.net/ListHelp
Re: [Maria-discuss] Maria-db refuses to start
Am 08.12.22 um 18:59 schrieb Gordan Bobic: On Thu, Dec 8, 2022 at 7:28 PM Reindl Harald wrote: MariaDB does the same as the filesystem InnoDB in fact is more ore less a FS on top of a FS So why do it at both levels? because the FS layer can't detect MariaDB errors? And what makes doing it at MariaDB level in any way better than doing it somewhere else? which magic should do it somewehre else? "Some of us run MariaDB on file systems that do their own block checksumming, and thus run innodb_checksum_algorithm=none" makes you looking like a fool - period are you dumb or why don't you understand that the filesystem is a completly different layer and has no clue about the data itself? Are you too dumb to understand that if a block is corrupted at InnoDB level MariaDB can't do anyting to fix it, but if a block is corrupted at lower level, ZFS can fix it from redundantly stored data and MariaDB never gets to ingest a corrupted block in the first place? it can at least fail early instead work with corrupted data If you disagree, please describe a scenario in which an InnoDB page checksum does anything useful if the file system it is on has built in block checksumming and data redundancy. INNDOB CHECKSUMS DETECT DATA CORRUPTION WITHIN MARIADB NOT CAUSED BY ANY FILESYSTEM ISSUE AT ALL the filesystem can't do that with it's block checksumming and data redundancy because there is *nothing wrong* for the view of the FS layer one is for consistency of the database one is for consistency of the underlying filesystem two worlds and i simply don't get why people not understanding such basics work in the IT but to top that talking nonsense on mailing-lists AGAIN: THE FILESYSTEM CAN'T DO ANYTHING BECAUSE IT'S NOT AFFECTED ___ Mailing list: https://launchpad.net/~maria-discuss Post to : maria-discuss@lists.launchpad.net Unsubscribe : https://launchpad.net/~maria-discuss More help : https://help.launchpad.net/ListHelp
Re: [Maria-discuss] Maria-db refuses to start
Op 08-12-2022 om 18:59 schreef Gordan Bobic: On Thu, Dec 8, 2022 at 7:28 PM Reindl Harald wrote: MariaDB Server 10.4 introduced a new file format innodb_checksum_algorithm=full_crc32, and MariaDB Server 10.5 made it the default. Any files that were created when that setting is active are guaranteed to write any unused bytes as zeroes. It also fixes a peculiar design decision that some bytes of the page are not covered by any checksum, and that a page is considered valid if any of the non-full_crc32 checksums happen to produce a match. This includes the magic 0xdeadbeef for innodb_checksum_algorithm=none. Maybe we should consider eventually deprecating write support for the non-full_crc32 format, to force a fresh start. Please don't. Some of us run MariaDB on file systems that do their own block checksumming, and thus run innodb_checksum_algorithm=none that's nonsense - when mariadb writes wrong data in it's files no filesystem can magically fix that MariaDB can't fix it either. And if that is what happened, there is no benefit to duplicating the effort. MariaDB does the same as the filesystem InnoDB in fact is more ore less a FS on top of a FS So why do it at both levels? And what makes doing it at MariaDB level in any way better than doing it somewhere else? you need to understand what innodb checksums are and then it's logical that the file-system layer is a completly different world https://dba.stackexchange.com/questions/171708/what-is-an-innodb-page-checksum You need to understand that properly thought out and sensibly written file systems (which is, granted, pretty rare, I know of a total of 1) implicitly prevent torn pages from being possible. So the checksum and the doublewrite are completely redundant in such cases, and can be safely disabled. "Some of us run MariaDB on file systems that do their own block checksumming, and thus run innodb_checksum_algorithm=none" makes you looking like a fool - period are you dumb or why don't you understand that the filesystem is a completly different layer and has no clue about the data itself? Are you too dumb to understand that if a block is corrupted at InnoDB level MariaDB can't do anyting to fix it, but if a block is corrupted at lower level, ZFS can fix it from redundantly stored data and MariaDB never gets to ingest a corrupted block in the first place? If you disagree, please describe a scenario in which an InnoDB page checksum does anything useful if the file system it is on has built in block checksumming and data redundancy. ___ Mailing list: https://launchpad.net/~maria-discuss Post to : maria-discuss@lists.launchpad.net Unsubscribe : https://launchpad.net/~maria-discuss More help : https://help.launchpad.net/ListHelp I don't understand much of this discussion, but take it it's not meant for me... I take it it does not change anything for the steps I described in my last mail. to get a functioning database again.. regards, Jogchum ___ Mailing list: https://launchpad.net/~maria-discuss Post to : maria-discuss@lists.launchpad.net Unsubscribe : https://launchpad.net/~maria-discuss More help : https://help.launchpad.net/ListHelp
Re: [Maria-discuss] Maria-db refuses to start
On Thu, Dec 8, 2022 at 7:28 PM Reindl Harald wrote: > MariaDB Server 10.4 introduced a new file format > innodb_checksum_algorithm=full_crc32, and MariaDB Server 10.5 made it > the default. Any files that were created when that setting is active > are guaranteed to write any unused bytes as zeroes. It also fixes a > peculiar design decision that some bytes of the page are not covered > by any checksum, and that a page is considered valid if any of the > non-full_crc32 checksums happen to produce a match. This includes the > magic 0xdeadbeef for innodb_checksum_algorithm=none. > > Maybe we should consider eventually deprecating write support for the > non-full_crc32 format, to force a fresh start. > >>> > >>> Please don't. Some of us run MariaDB on file systems that do their own > >>> block checksumming, and thus run innodb_checksum_algorithm=none > >> > >> that's nonsense - when mariadb writes wrong data in it's files no > >> filesystem can magically fix that > > > > MariaDB can't fix it either. And if that is what happened, there is no > > benefit to duplicating the effort. > > MariaDB does the same as the filesystem > InnoDB in fact is more ore less a FS on top of a FS So why do it at both levels? And what makes doing it at MariaDB level in any way better than doing it somewhere else? > >> you need to understand what innodb checksums are and then it's logical > >> that the file-system layer is a completly different world > >> > >> https://dba.stackexchange.com/questions/171708/what-is-an-innodb-page-checksum > > > > You need to understand that properly thought out and sensibly written > > file systems (which is, granted, pretty rare, I know of a total of 1) > > implicitly prevent torn pages from being possible. > > So the checksum and the doublewrite are completely redundant in such > > cases, and can be safely disabled. > > "Some of us run MariaDB on file systems that do their own block > checksumming, and thus run innodb_checksum_algorithm=none" makes you > looking like a fool - period > > are you dumb or why don't you understand that the filesystem is a > completly different layer and has no clue about the data itself? Are you too dumb to understand that if a block is corrupted at InnoDB level MariaDB can't do anyting to fix it, but if a block is corrupted at lower level, ZFS can fix it from redundantly stored data and MariaDB never gets to ingest a corrupted block in the first place? If you disagree, please describe a scenario in which an InnoDB page checksum does anything useful if the file system it is on has built in block checksumming and data redundancy. ___ Mailing list: https://launchpad.net/~maria-discuss Post to : maria-discuss@lists.launchpad.net Unsubscribe : https://launchpad.net/~maria-discuss More help : https://help.launchpad.net/ListHelp
Re: [Maria-discuss] Maria-db refuses to start
Am 08.12.22 um 18:08 schrieb Gordan Bobic: On Thu, Dec 8, 2022 at 7:02 PM Reindl Harald wrote: MariaDB Server 10.4 introduced a new file format innodb_checksum_algorithm=full_crc32, and MariaDB Server 10.5 made it the default. Any files that were created when that setting is active are guaranteed to write any unused bytes as zeroes. It also fixes a peculiar design decision that some bytes of the page are not covered by any checksum, and that a page is considered valid if any of the non-full_crc32 checksums happen to produce a match. This includes the magic 0xdeadbeef for innodb_checksum_algorithm=none. Maybe we should consider eventually deprecating write support for the non-full_crc32 format, to force a fresh start. Please don't. Some of us run MariaDB on file systems that do their own block checksumming, and thus run innodb_checksum_algorithm=none that's nonsense - when mariadb writes wrong data in it's files no filesystem can magically fix that MariaDB can't fix it either. And if that is what happened, there is no benefit to duplicating the effort. MariaDB does the same as the filesystem InnoDB in fact is more ore less a FS on top of a FS you need to understand what innodb checksums are and then it's logical that the file-system layer is a completly different world https://dba.stackexchange.com/questions/171708/what-is-an-innodb-page-checksum You need to understand that properly thought out and sensibly written file systems (which is, granted, pretty rare, I know of a total of 1) implicitly prevent torn pages from being possible. So the checksum and the doublewrite are completely redundant in such cases, and can be safely disabled. are you dumb or why don't you understand that the filesystem is a completly different layer and has no clue about the data itself? "Some of us run MariaDB on file systems that do their own block checksumming, and thus run innodb_checksum_algorithm=none" makes you looking like a fool - period ___ Mailing list: https://launchpad.net/~maria-discuss Post to : maria-discuss@lists.launchpad.net Unsubscribe : https://launchpad.net/~maria-discuss More help : https://help.launchpad.net/ListHelp
Re: [Maria-discuss] Maria-db refuses to start
On Thu, Dec 8, 2022 at 7:02 PM Reindl Harald wrote: > >> MariaDB Server 10.4 introduced a new file format > >> innodb_checksum_algorithm=full_crc32, and MariaDB Server 10.5 made it > >> the default. Any files that were created when that setting is active > >> are guaranteed to write any unused bytes as zeroes. It also fixes a > >> peculiar design decision that some bytes of the page are not covered > >> by any checksum, and that a page is considered valid if any of the > >> non-full_crc32 checksums happen to produce a match. This includes the > >> magic 0xdeadbeef for innodb_checksum_algorithm=none. > >> > >> Maybe we should consider eventually deprecating write support for the > >> non-full_crc32 format, to force a fresh start. > > > > Please don't. Some of us run MariaDB on file systems that do their own > > block checksumming, and thus run innodb_checksum_algorithm=none > > that's nonsense - when mariadb writes wrong data in it's files no > filesystem can magically fix that MariaDB can't fix it either. And if that is what happened, there is no benefit to duplicating the effort. > you need to understand what innodb checksums are and then it's logical > that the file-system layer is a completly different world > > https://dba.stackexchange.com/questions/171708/what-is-an-innodb-page-checksum You need to understand that properly thought out and sensibly written file systems (which is, granted, pretty rare, I know of a total of 1) implicitly prevent torn pages from being possible. So the checksum and the doublewrite are completely redundant in such cases, and can be safely disabled. ___ Mailing list: https://launchpad.net/~maria-discuss Post to : maria-discuss@lists.launchpad.net Unsubscribe : https://launchpad.net/~maria-discuss More help : https://help.launchpad.net/ListHelp
Re: [Maria-discuss] Maria-db refuses to start
On Thu, Dec 8, 2022 at 6:59 PM Reindl Harald wrote: > > > > Am 08.12.22 um 17:51 schrieb Gordan Bobic: > > On Thu, Dec 8, 2022 at 6:43 PM Reindl Harald wrote: > > > >> and when you are at it get rid of "ib_logfile0" and "ib_logfile1" which > >> hold data even in file-per-table mode you can't cleanup from crap caused > >> by a crash 13 years ago > > > > How can that happen when every once in a while upgrades require a full > > clean shutdown with innodb_fast_shutdown=0 so that the ib_logfile* > > have to be rebuild due to an on-disk format change? > > in my whole life from MySQL 5.0 (the frist time i built mysql with > innodb support at all) to MariaDB 10.3 i didn't do anything then > upgrade, restart service and be done I don't have an explanation for that, short of pure luck, in the fact that the log was naturally empty because everything had been flushed to disk at the point you upgraded. You should play the lottery more often if your luck is that good. Mine certainly isn't. > > More to the point, if that is a concern, why can you not shut down > > cleanly with innodb_fast_shutdown=0, rm the files, and let MariaDB > > re-create them completely clean and empty? > > don't ask me why that shit can't be removed automatically over 13 years > - the reference to './dbmail/#sql2-704-271.ibd' lives somewhere in the > "global tablespace" which shouldn't exist at all I have seen phantom InnoDB tables like that before, but never ones that coiuldn't be cleared with a simple "drop table". Does it show up in innodb_sys_tables or innodb_sys_tablespaces? ___ Mailing list: https://launchpad.net/~maria-discuss Post to : maria-discuss@lists.launchpad.net Unsubscribe : https://launchpad.net/~maria-discuss More help : https://help.launchpad.net/ListHelp
Re: [Maria-discuss] Maria-db refuses to start
Am 08.12.22 um 17:47 schrieb Gordan Bobic: On Thu, Dec 8, 2022 at 6:25 PM Marko Mäkelä wrote: MariaDB Server 10.4 introduced a new file format innodb_checksum_algorithm=full_crc32, and MariaDB Server 10.5 made it the default. Any files that were created when that setting is active are guaranteed to write any unused bytes as zeroes. It also fixes a peculiar design decision that some bytes of the page are not covered by any checksum, and that a page is considered valid if any of the non-full_crc32 checksums happen to produce a match. This includes the magic 0xdeadbeef for innodb_checksum_algorithm=none. Maybe we should consider eventually deprecating write support for the non-full_crc32 format, to force a fresh start. Please don't. Some of us run MariaDB on file systems that do their own block checksumming, and thus run innodb_checksum_algorithm=none that's nonsense - when mariadb writes wrong data in it's files no filesystem can magically fix that you need to understand what innodb checksums are and then it's logical that the file-system layer is a completly different world https://dba.stackexchange.com/questions/171708/what-is-an-innodb-page-checksum and/or have databases many terabytes in size. With terabyte size databases, doing a mysqldump+restore is realistically _never_ going to happen. that's is the real problem - and hence i expect from software in 2022 that it's able to read it's old data and create new initialized data-files at runtime ___ Mailing list: https://launchpad.net/~maria-discuss Post to : maria-discuss@lists.launchpad.net Unsubscribe : https://launchpad.net/~maria-discuss More help : https://help.launchpad.net/ListHelp
Re: [Maria-discuss] Maria-db refuses to start
Am 08.12.22 um 17:51 schrieb Gordan Bobic:
On Thu, Dec 8, 2022 at 6:43 PM Reindl Harald wrote:
and when you are at it get rid of "ib_logfile0" and "ib_logfile1" which
hold data even in file-per-table mode you can't cleanup from crap caused
by a crash 13 years ago
How can that happen when every once in a while upgrades require a full
clean shutdown with innodb_fast_shutdown=0 so that the ib_logfile*
have to be rebuild due to an on-disk format change?
in my whole life from MySQL 5.0 (the frist time i built mysql with
innodb support at all) to MariaDB 10.3 i didn't do anything then
upgrade, restart service and be done
More to the point, if that is a concern, why can you not shut down
cleanly with innodb_fast_shutdown=0, rm the files, and let MariaDB
re-create them completely clean and empty?
don't ask me why that shit can't be removed automatically over 13 years
- the reference to './dbmail/#sql2-704-271.ibd' lives somewhere in the
"global tablespace" which shouldn't exist at all
# mysqld to syslog and skip known erroes from crash 2009
if $programname == 'mysqld' then {
:msg, contains, "[ERROR] InnoDB: Cannot open datafile for read-only:
'./dbmail/#sql2-704-271.ibd'" stop
:msg, contains, "[ERROR] InnoDB: Could not find a valid tablespace
file for ``dbmail`.`#sql2-704-271``" stop
:msg, contains, "[ERROR] InnoDB: If you are installing InnoDB,
remember that you must create directories yourself, InnoDB does not
create them" stop
:msg, contains, "[ERROR] InnoDB: Operating system error number 2 in a
file operation" stop
:msg, contains, "[ERROR] InnoDB: The error means the system cannot
find the path specified" stop
:programname, isequal, "mysqld"
-/Volumes/dune/www-servers/_logs/mysql_error.log
:programname, isequal, "mysqld" stop
}
___
Mailing list: https://launchpad.net/~maria-discuss
Post to : maria-discuss@lists.launchpad.net
Unsubscribe : https://launchpad.net/~maria-discuss
More help : https://help.launchpad.net/ListHelp
Re: [Maria-discuss] Maria-db refuses to start
On Thu, Dec 8, 2022 at 6:43 PM Reindl Harald wrote: > and when you are at it get rid of "ib_logfile0" and "ib_logfile1" which > hold data even in file-per-table mode you can't cleanup from crap caused > by a crash 13 years ago How can that happen when every once in a while upgrades require a full clean shutdown with innodb_fast_shutdown=0 so that the ib_logfile* have to be rebuild due to an on-disk format change? More to the point, if that is a concern, why can you not shut down cleanly with innodb_fast_shutdown=0, rm the files, and let MariaDB re-create them completely clean and empty? ___ Mailing list: https://launchpad.net/~maria-discuss Post to : maria-discuss@lists.launchpad.net Unsubscribe : https://launchpad.net/~maria-discuss More help : https://help.launchpad.net/ListHelp
Re: [Maria-discuss] Maria-db refuses to start
On Thu, Dec 8, 2022 at 6:25 PM Marko Mäkelä wrote: > MariaDB Server 10.4 introduced a new file format > innodb_checksum_algorithm=full_crc32, and MariaDB Server 10.5 made it > the default. Any files that were created when that setting is active > are guaranteed to write any unused bytes as zeroes. It also fixes a > peculiar design decision that some bytes of the page are not covered > by any checksum, and that a page is considered valid if any of the > non-full_crc32 checksums happen to produce a match. This includes the > magic 0xdeadbeef for innodb_checksum_algorithm=none. > > Maybe we should consider eventually deprecating write support for the > non-full_crc32 format, to force a fresh start. Please don't. Some of us run MariaDB on file systems that do their own block checksumming, and thus run innodb_checksum_algorithm=none, and/or have databases many terabytes in size. With terabyte size databases, doing a mysqldump+restore is realistically _never_ going to happen. ___ Mailing list: https://launchpad.net/~maria-discuss Post to : maria-discuss@lists.launchpad.net Unsubscribe : https://launchpad.net/~maria-discuss More help : https://help.launchpad.net/ListHelp
Re: [Maria-discuss] Maria-db refuses to start
Am 08.12.22 um 17:22 schrieb Marko Mäkelä: On Thu, Dec 8, 2022 at 5:41 PM Reindl Harald wrote: I think you mean mysql, not postgresql... no, i mean postgresql, that piece of crap breaking for years after dist-upgrades because you need to do dump+restore at every version change - real fun because you need to remember about the dump *before* The other side of the coin is a questionable InnoDB "optimization" that was finally fixed in MySQL 5.1.48 (in 2010) due to an external bug report. Heikki Tuuri firmly believed that zeroing out pages when they are initialized burns too many CPU cycles, so it is better to just write whatever garbage to any unused bytes in data pages. He actually forbade me to fix it back in 2004 or 2005, and forbade me to spend any time to prove what kind of bad things could happen. (Back then, even the FIL_PAGE_TYPE was written uninitialized to anything other than B-tree index pages. So, if the page type field said FIL_PAGE_INDEX, you could not say if it actually was an index page.) WTF - but that don't change anything - you just can't dump+restore multi GB large databases in production environments and i expect from a new software version that it simply can read it's older data I have tried to keep the implications in mind, but there has been at least one serious bug regarding this: https://jira.mariadb.org/browse/MDEV-27800 "cool" the only server where i care about InnoDB at all dates back to 2009 If a database with InnoDB had been originally initialized before MySQL 5.1.48 and you kept upgrading the binary files, you could have a similar ticking time-bomb in some other data structure, which might be forgotten when a future minor change to the data file format is made. This would not be caught in normal upgrade tests, which would initialize a database using a previous server version (say, 10.2) and then upgrade to 10.3. To catch something like this, you would have to initialize and populate the database in MySQL 5.1.47 or earlier, with a suitable usage pattern that actually causes some unused to contain suitably unlucky garbage bytes. (On a freshly initialized database they could easily be 0.) p - when you can read the data for a dump you could re-create the innodb-files like due "alter/optimize table" online and when you are at it get rid of "ib_logfile0" and "ib_logfile1" which hold data even in file-per-table mode you can't cleanup from crap caused by a crash 13 years ago MariaDB Server 10.4 introduced a new file format innodb_checksum_algorithm=full_crc32, and MariaDB Server 10.5 made it the default. Any files that were created when that setting is active are guaranteed to write any unused bytes as zeroes. It also fixes a peculiar design decision that some bytes of the page are not covered by any checksum, and that a page is considered valid if any of the non-full_crc32 checksums happen to produce a match. This includes the magic 0xdeadbeef for innodb_checksum_algorithm=none. and what happens over the long with data that has no checksums at all because it was possible to completly disable them in the past? Maybe we should consider eventually deprecating write support for the non-full_crc32 format, to force a fresh start. p - when you can read the data for a dump you could re-create the innodb-files like due "alter/optimize table" online and when you are at it get rid of "ib_logfile0" and "ib_logfile1" which hold data even in file-per-table mode you can't cleanup from crap caused by a crash 13 years ago ___ Mailing list: https://launchpad.net/~maria-discuss Post to : maria-discuss@lists.launchpad.net Unsubscribe : https://launchpad.net/~maria-discuss More help : https://help.launchpad.net/ListHelp
Re: [Maria-discuss] Maria-db refuses to start
On Thu, Dec 8, 2022 at 5:41 PM Reindl Harald wrote: > > > > I think you mean mysql, not postgresql... > > no, i mean postgresql, that piece of crap breaking for years after > dist-upgrades because you need to do dump+restore at every version > change - real fun because you need to remember about the dump *before* The other side of the coin is a questionable InnoDB "optimization" that was finally fixed in MySQL 5.1.48 (in 2010) due to an external bug report. Heikki Tuuri firmly believed that zeroing out pages when they are initialized burns too many CPU cycles, so it is better to just write whatever garbage to any unused bytes in data pages. He actually forbade me to fix it back in 2004 or 2005, and forbade me to spend any time to prove what kind of bad things could happen. (Back then, even the FIL_PAGE_TYPE was written uninitialized to anything other than B-tree index pages. So, if the page type field said FIL_PAGE_INDEX, you could not say if it actually was an index page.) I have tried to keep the implications in mind, but there has been at least one serious bug regarding this: https://jira.mariadb.org/browse/MDEV-27800 If a database with InnoDB had been originally initialized before MySQL 5.1.48 and you kept upgrading the binary files, you could have a similar ticking time-bomb in some other data structure, which might be forgotten when a future minor change to the data file format is made. This would not be caught in normal upgrade tests, which would initialize a database using a previous server version (say, 10.2) and then upgrade to 10.3. To catch something like this, you would have to initialize and populate the database in MySQL 5.1.47 or earlier, with a suitable usage pattern that actually causes some unused to contain suitably unlucky garbage bytes. (On a freshly initialized database they could easily be 0.) MariaDB Server 10.4 introduced a new file format innodb_checksum_algorithm=full_crc32, and MariaDB Server 10.5 made it the default. Any files that were created when that setting is active are guaranteed to write any unused bytes as zeroes. It also fixes a peculiar design decision that some bytes of the page are not covered by any checksum, and that a page is considered valid if any of the non-full_crc32 checksums happen to produce a match. This includes the magic 0xdeadbeef for innodb_checksum_algorithm=none. Maybe we should consider eventually deprecating write support for the non-full_crc32 format, to force a fresh start. Note: We still spend effort to allow in-place binary upgrades. My last example of that was https://jira.mariadb.org/browse/MDEV-29694, removing one of the innovative InnoDB features: the change buffer a.k.a. insert buffer, because it has been the source of many hard-to-debug index corruption bugs. With best regards, Marko -- Marko Mäkelä, Lead Developer InnoDB MariaDB Corporation ___ Mailing list: https://launchpad.net/~maria-discuss Post to : maria-discuss@lists.launchpad.net Unsubscribe : https://launchpad.net/~maria-discuss More help : https://help.launchpad.net/ListHelp
Re: [Maria-discuss] Maria-db refuses to start
Am 08.12.22 um 16:29 schrieb Jogchum Reitsma: Hi Reindl, Op 08-12-2022 om 08:31 schreef Reindl Harald: FIRST: can you stop using "rewrite-all" on mailing-lists? when the useless offlist-copy is faster the dupes-filter on our server is supressing the list-copy and you break my reply-list button in thunderbird OK, I'm sorry for that. But on some other mailing lists people ask explicitly to use reply all, so it's not always easy to do it the right way. But as you can see this goes only to the list. I agree with you that this thread should com to an end, so I followed your advice, and dumped all my own tables, one by one, in .sql files. Checked them, are OK. I think you mean mysql, not postgresql... no, i mean postgresql, that piece of crap breaking for years after dist-upgrades because you need to do dump+restore at every version change - real fun because you need to remember about the dump *before* I could dump table mysql as user root. The tables information_schema and performance_schema I could not dump. I suppose that is no problem? performance_schema is not really a table If indeed that is no problem, I think the following steps are necessary: - give ctrl-\ to the command running the 10.7.7 dbserver to gracefully stop it - umount the --bind mount to my database files - rename the directory where my database files are stored, - create a new, empty datadir in my home directory ( I know that is not standard; we discussed it in this thread before.but I have several reasons to want it there. After all, it has worked fine this way for some 20 years Of course I always can mount --bind it to a more standard place, if that is necessary or preferable) - delete the file structures created by untarring /usr/local/mariadb-10.6.10-linux-systemd-x86_64.tar.gz and /usr/local/mariadb-10.7.7-linux-systemd-x86_64.tar.gz - uninstall the mariadb package from the OS - remove /run/mysql (holds the lock file) - move /var/log/mysql to a place in my home system Have I forgotten something? man locate man updatedb there souldn't be any mysql/mariadb stuff on the machine except your backups and files provided by client libraries which are pretty sure deps of other packages After that, re-install the package from my OS. I would think the install process creates an empty database, which I can populate with the dumps just created. i guess yes, otherwise https://dev.mysql.com/doc/mysql-installation-excerpt/8.0/en/data-directory-initialization.html ___ Mailing list: https://launchpad.net/~maria-discuss Post to : maria-discuss@lists.launchpad.net Unsubscribe : https://launchpad.net/~maria-discuss More help : https://help.launchpad.net/ListHelp
Re: [Maria-discuss] Maria-db refuses to start
Hi Reindl, Op 08-12-2022 om 08:31 schreef Reindl Harald: FIRST: can you stop using "rewrite-all" on mailing-lists? when the useless offlist-copy is faster the dupes-filter on our server is supressing the list-copy and you break my reply-list button in thunderbird OK, I'm sorry for that. But on some other mailing lists people ask explicitly to use reply all, so it's not always easy to do it the right way. But as you can see this goes only to the list. I agree with you that this thread should com to an end, so I followed your advice, and dumped all my own tables, one by one, in .sql files. Checked them, are OK. I think you mean mysql, not postgresql... I could dump table mysql as user root. The tables information_schema and performance_schema I could not dump. I suppose that is no problem? If indeed that is no problem, I think the following steps are necessary: - give ctrl-\ to the command running the 10.7.7 dbserver to gracefully stop it - umount the --bind mount to my database files - rename the directory where my database files are stored, - create a new, empty datadir in my home directory ( I know that is not standard; we discussed it in this thread before.but I have several reasons to want it there. After all, it has worked fine this way for some 20 years Of course I always can mount --bind it to a more standard place, if that is necessary or preferable) - delete the file structures created by untarring /usr/local/mariadb-10.6.10-linux-systemd-x86_64.tar.gz and /usr/local/mariadb-10.7.7-linux-systemd-x86_64.tar.gz - uninstall the mariadb package from the OS - remove /run/mysql (holds the lock file) - move /var/log/mysql to a place in my home system Have I forgotten something? After that, re-install the package from my OS. I would think the install process creates an empty database, which I can populate with the dumps just created. Thanks for all your replies, and sorry for the misunderstandings that made it so hard to help me. Of course that's never been my intention, I hope you can understand that. that way this thread could come to an end Hopefully it does... regards Jogchum ___ Mailing list: https://launchpad.net/~maria-discuss Post to : maria-discuss@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@lists.launchpad.net Unsubscribe : https://launchpad.net/~maria-discuss More help : https://help.launchpad.net/ListHelp
Re: [Maria-discuss] Statistics are not being updated?
Hi Colin, This was due to a combination of a Docker container failure and a failure in the alert system. Many thanks for pointing it out. It should now be fixed. Kind Regards Andrew On 07/12/2022 19:14, Colin Charles wrote: Hi, Any reason statistics stopped being updated in October? https://mariadb.org/statistics/ Would be great if this got fixed, thanks cheers, -c -- Colin Charles, http://bytebot.net/blog/ twitter: @bytebot | skype: colincharles "First they ignore you, then they laugh at you, then they fight you, then you win." -- Mohandas Gandhi ___ Mailing list: https://launchpad.net/~maria-discuss Post to : maria-discuss@lists.launchpad.net Unsubscribe : https://launchpad.net/~maria-discuss More help : https://help.launchpad.net/ListHelp -- Andrew (LinuxJedi) Hutchings Chief Contributions Officer MariaDB Foundation ___ Mailing list: https://launchpad.net/~maria-discuss Post to : maria-discuss@lists.launchpad.net Unsubscribe : https://launchpad.net/~maria-discuss More help : https://help.launchpad.net/ListHelp
