Re: [Maria-discuss] Maria-db refuses to start

[Reindl Harald]

Am 10.12.22 um 03:42 schrieb martin doc:
 "Some of us run MariaDB on file systems that do their own block 

checksumming, and thus run innodb_checksum_algorithm=none" unchallenged

Your choice. Your risks


wow

it took long until you understood what i was talking about

your offlist pissing contest 4 minutes before this mail was the time you 
realized that you where a monkey fighting against me while you meant 
this guy?


that happens when one isn't smart enough to understand who said what and 
replying unaksed in the middle of a thread


___
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

[Reindl Harald]

Am 09.12.22 um 09:00 schrieb Marko Mäkelä:
Regarding the dbmail/#sql2-704-271.ibd in your other message, in MariaDB 
10.5 or later you should be able to drop the table even if a .frm file 
does not exist, with

DROP TABLE dbmail.`#mysql50##sql2-704-271`;


currently on 10.3 because i don't agree the json nosense in the system 
table.


If you are using an older version, you could try to copy the .frm file 
of another InnoDB table to that name


i did that 13 years ago to get rid of that error message, a few years 
ago 10.1 or 10.2 decided to crash at startup with that non-mathcing file



and then remove the file.


i think you mean "remove the table" - no, "table don't" exist but on the 
other hand i wasn't able to guess `#mysql50##sql2-704-271` as name and 
"show tables" don't list anything


hence when you don#t list it in "show tables" just remove it from global 
tablespace or get rid of that useless global tablewspace at all in 
"files-per-table" mode


DDL operations should be crash-safe and most of them are atomic starting 
with MariaDB 10.6.


13 years too late :-)

___
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

[Reindl Harald]

Am 09.12.22 um 08:10 schrieb martin doc:
If you want protection from your database files being corrupted then you 
need to implement it.


tell me something new - but what has this to do woth the topic?

If you do nothing then you'll have no protection. You did nothing and 
your data got corrupted.


tell me something new - but what has this to do woth the topic?

There are lots of "best practices" for database administration to deal 
with this and it appears that you followed none of them.


because i don't disable innodb checksums?
how much fog is in your head?


This is nobody's problem but yours - own it.


are you drunken or on drugs?

no other explaination of the brainfuck above as reaction not let "Some 
of us run MariaDB on file systems that

do their own block checksumming, and thus run
innodb_checksum_algorithm=none" unchallenged

is this a second account from the same idiot or are you two unique fools 
- what about marry each other and leave the world in peace?




___
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

[Reindl Harald]

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

[Reindl Harald]

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

[Reindl Harald]

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

[Reindl Harald]

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

[Reindl Harald]

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

[Reindl Harald]

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

[Reindl Harald]

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

[Reindl Harald]

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

[Reindl Harald]

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

[Reindl Harald]

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

[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


Am 08.12.22 um 08:13 schrieb Jogchum Reitsma:

Op 07-12-2022 om 23:14 schreef Reindl Harald:

if it's a different one maybe permissions are a problem (again)
Well, as a normal user. But as I stated, there is no problem with *this* 
command: this works, and I get a functioning db-system.


why are you making it so hard to help you - is it THE DAMNED SAME USER 
the service would run as - in case "as normal user" means your ordianry 
login user it's not the same the systemd-service would run as


After that, I tried to start the version that comes with the OS 
(OpenSuse Thumbleweed) trough systemctl start mariadb, without success.


so the problem is still not really solved?

if that's the case for the sake of god dump your data as soon as you 
get the server running, 

As I said, I can get the server running, only not through systemd


no - you mixing a manually started completly diffrent binary versus a 
systemd-started with another binary running under a different user with 
pretty likely different versions


common sense says: too much differences at one time

remove all nonsense and mysql-data from the system, start from scratch 
and import the dumps as it's normal for postgresql


that way this thread could come to an end

___
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

[Reindl Harald]

Am 07.12.22 um 16:53 schrieb Jogchum Reitsma:

Op 07-12-2022 om 12:15 schreef Reindl Harald:



Am 07.12.22 um 10:27 schrieb Jogchum Reitsma:

Sorry, my bad: of course I should have started mysqld, not mysql.


besides that you should notice when you try to start a non-existing 
service what is really bad: you randomly mix "mysqld", "mysql" and 
"mariadb" as service name in your posts


in the worst case they are really existing but doing different things

Starting 10.7.7 works, and indeed recreates ib_logfile0. All my 
databases are there, no corruption AFAICS.


Shut it down with kill -15, and the logfile reports a normal shutdown


you shouldn't use "kill" at all fro shutdown when you start something 
as systemd-unit


I  started the he 10.7.7 version not through systemd, but by issuing 
/usr/local/mariadb-10.7.7-linux-systemd-x86_64/bin/mysqld in the 
terminal, as advised earlier in this conversation.


as which user?

if it's a different one maybe permissions are a problem (again)

"Sorry, my bad: of course I should have started mysqld, not mysql" 
should have been obvious - i mean a sevrer is a background process 
versus an interactive sql shell


This way I managed to 
get a working db-server, and access to my data.


I stopped that by SIGQUIT, and this gives a correct shutdown.


15 is SIGTERM, lucky you didn't find the number for SIGQUIT

After that, I tried to start the version that comes with the OS 
(OpenSuse Thumbleweed) trough systemctl start mariadb, without success.


so the problem is still not really solved?

if that's the case for the sake of god dump your data as soon as you get 
the server running, remove all nonsense and mysql-data from the system, 
start from scratch and import the dumps as it's normal for postgresql


my mysql-data dirs date back to 2002 and where used on MacOS, Linux and 
Widows over the past years, so strange when mysql/mariadb acts that 
strange, but so be it



Hope this clarifies the steps taken


that whole thread is a mess

___
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

[Reindl Harald]

Am 07.12.22 um 10:27 schrieb Jogchum Reitsma:

Sorry, my bad: of course I should have started mysqld, not mysql.


besides that you should notice when you try to start a non-existing 
service what is really bad: you randomly mix "mysqld", "mysql" and 
"mariadb" as service name in your posts


in the worst case they are really existing but doing different things

Starting 10.7.7 works, and indeed recreates ib_logfile0. All my 
databases are there, no corruption AFAICS.


Shut it down with kill -15, and the logfile reports a normal shutdown


you shouldn't use "kill" at all fro shutdown when you start something as 
systemd-unit


___
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

[Reindl Harald]

PLEASE don't use "reply-all" on mailing-lists, you break "reply-list" 
for capable users!


Am 10.11.22 um 20:36 schrieb Jogchum Reitsma:

Op 10-11-2022 om 13:39 schreef Reindl Harald:
for the sake of god open "/usr/lib/systemd/system/mariadb.service" and 
remove or comment out the "ExecStartPre" until your problems are solved


"ExecStartPre=/usr/libexec/mysql/mysql-systemd-helper upgrade 
(code=exited, status=1/FAILURE)" is some distribution sepcific nonsense
I have no idea what these "install" and "upgrade " ExecStartPre do, but 
I commented them  out, did a systemctl daemon-reload, and issued 
systemctl start mariadb.service again.


Again with no luck:

systemctl status mariadb.service
×mariadb.service - MariaDB database server
 Loaded: loaded (/usr/lib/systemd/system/mariadb.service; disabled; 
preset: disabled)

    Drop-In: /etc/systemd/system/mariadb.service.d
 └─override.conf
 Active: failed(Result: exit-code) since Thu 2022-11-10 20:22:35 
CET; 17s ago

   Docs: man:mysqld(8)
https://mariadb.com/kb/en/library/systemd/
    Process: 35754 ExecStart=/usr/libexec/mysql/mysql-systemd-helper 
start (code=exited, status=1/FAILURE)

   Main PID: 35754 (code=exited, status=1/FAILURE)
 Status: "MariaDB server is down"


"ExecStart=/usr/libexec/mysql/mysql-systemd-helper" is still some 
distribution crap


throw away that crap by create a unit in 
"/etc/systemd/system/mariadb.service" which will completly override the 
distro stuff


* there is no need for helpers
* there is no need for mysqld_safe and other nonsense
* systemd can babysit services for years
* that below is my mysqld/mriadb unit for years

"Type=notify" should work unless some moron compiled the binary, 
"Type=simple" would need helper scripts if services are ordered after 
the database


"After=network-up.service" should be replaced by whatever your 
distribution is using to start the network, as for most of the critical 
stuff i simply refuse to use the distribution nonsense and replaced 
newtork/iptables/ipset by my own services


"AmbientCapabilities=CAP_IPC_LOCK CAP_SYS_NICE" as well as "User=mysql" 
and "Group=mysql" are they key that the service can be started from the 
first second as the intended user (port 3306 don't need super user 
privileges) and all that crap around with all it's indirection makes 
debugging impossible and introduces security holes (there was a CVE in 
context mysqld_safe a few years ago)


minimize the crap used to start services to what is *really* needed

---

[Unit]
Description=MariaDB Database
After=network-up.service
Before=crond.service
ConditionPathExists=/etc/my.cnf

[Service]
Type=notify
KillMode=process
KillSignal=SIGTERM
SendSIGKILL=no

User=mysql
Group=mysql

ExecStart=/usr/libexec/mysqld --defaults-file=/etc/my.cnf 
--pid-file=/dev/null

Environment="LANG=C.UTF-8"
Restart=always
RestartSec=1
TimeoutSec=300
LimitNOFILE=infinity
LimitMEMLOCK=infinity
OOMScoreAdjust=-1000
TasksMax=2048

AmbientCapabilities=CAP_IPC_LOCK CAP_SYS_NICE
CapabilityBoundingSet=CAP_IPC_LOCK CAP_SYS_NICE
LockPersonality=yes
MemoryDenyWriteExecute=yes
NoNewPrivileges=yes
PrivateDevices=yes
PrivateTmp=yes
ProtectClock=yes
ProtectControlGroups=yes
ProtectHome=yes
ProtectHostname=yes
ProtectKernelLogs=yes
ProtectKernelModules=yes
ProtectKernelTunables=yes
RestrictAddressFamilies=AF_UNIX AF_LOCAL AF_INET AF_INET6
RestrictNamespaces=yes
RestrictSUIDSGID=yes
SystemCallArchitectures=native
UMask=077

[Install]
WantedBy=multi-user.target

___
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

[Reindl Harald]

Am 10.11.22 um 12:06 schrieb Jogchum Reitsma:

Op 08-11-2022 om 22:54 schreef Daniel Black:

On Wed, Nov 9, 2022 at 12:01 AM Jogchum Reitsma
  wrote:

<...>
The directory /var/run/mysql doesn't exist


2022-11-08 13:37:33 0 [ERROR] Do you already have another server running on 
socket: /var/run/mysql/mysql.sock ?

This guess of an error should be fixed.


Well, in the meantime I have a running database, thanks to all the help 
I get here.


But I'm not quite out of trouble yet.

The last problem with starting 
/usr/local/mariadb-10.6.10-linux-systemd-x86_64/bin/mariadbd was solved 
by chmod 777 /var/run/mysql; this was needed because I start mariadb as 
a plain user for the moment. chmod on /var/log/msql gave me logging >

Once again I'm at a loss here - what causes mysqld not to start?

Any further help dearly appreciated


either "in the meantime I have a running database" or "what causes 
mysqld not to start" are possible and when it comes to "chmod on 
/var/log/msql gave me logging" show them


for the sake of god open "/usr/lib/systemd/system/mariadb.service" and 
remove or comment out the "ExecStartPre" until your problems are solved


"ExecStartPre=/usr/libexec/mysql/mysql-systemd-helper upgrade 
(code=exited, status=1/FAILURE)" is some distribution sepcific nonsense


in the real world it's enoug to ExecStart mysqld as user:ggroup mysql 
and skip all that nonsense including mysql_safe




___
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

[Maria-discuss] mariadb-10.3.37 strips "collate" from "show create table"

[Reindl Harald]

mariadb-10.3.36 versus mariadb-10.3.37

in the past every field contained "collate latin1_german1_ci" and after 
this point-update collation is only part of the output if it's different 
then the tables default collation


surely, i can update everything to mariadb-10.3.37 and rewrite all this 
tests in the hope the next point-update don't restore the old behavior


but it's really a bad style

-
CALLER: '/autotests/custom/phpincludes_mysql.php:306':
-
--- old_9bb3995c3244abfff522da086526e88b5a8a81f1e7cf672d8343f20d.txt 
2022-11-10 01:03:12.35303 +0100
+++ new_53033703b16454931e7c7f62ef923229ca8183aff6f6fa017cdb44bd.txt 
2022-11-10 01:03:12.35303 +0100

@@ -1,14 +1,14 @@
 create table `test_table` (`test_id` mediumint(7) unsigned not null 
auto_increment,

-`char_char` char(200) collate latin1_german1_ci default null,
+`char_char` char(200) default null,
 `char_date` date default null,
 `char_datetime` datetime default null,
-`char_longtext` longtext collate latin1_german1_ci default null,
-`char_mediumtext` mediumtext collate latin1_german1_ci default null,
-`char_text` text collate latin1_german1_ci default null,
+`char_longtext` longtext default null,
+`char_mediumtext` mediumtext default null,
+`char_text` text default null,
 `char_time` time default null,
 `char_timestamp` datetime default null,
-`char_tinytext` tinytext collate latin1_german1_ci default null,
-`char_varchar` varchar(200) collate latin1_german1_ci default null,
+`char_tinytext` tinytext default null,
+`char_varchar` varchar(200) default null,
 `number_bigint` bigint(200) unsigned default null,
 `number_double` double unsigned default null,
 `number_float` double unsigned default null,

___
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

[Reindl Harald]

Am 13.10.22 um 15:29 schrieb Jogchum Reitsma:

Op 13-10-2022 om 15:10 schreef Reindl Harald:
There I have plenty of room in a raid6 configuration, where the 
default location is much smaller, and populated by the infamous 
(well, with me at least) btrfs filesystem.


you can put the data in /home/mysql, make a bind-mount from 
/var/lib/mysql to /home/mysql and change the config to use /var/lib/mysql


OK, so, to be quite sure, the command then is

mount --bind  /var/lib/mysql

yes, the only difference to any other mount is type "bind"

my /etc/fstab for /home while "/mnt/data/home" is the phyiscal location 
on a 4 TB RAID


/mnt/data/home /home  none  bind

i don't create bind mounts manually because you can mount, unmount and 
comment out them in fstab like every other mountpoint and i perfer them 
to survive reboots



___
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

[Reindl Harald]

Am 13.10.22 um 14:54 schrieb Jogchum Reitsma:
frankly why don#t you move the datadir out of your suerhome and change 
the path to the datadir in the config?
25 years ago I decided that the data is only useful to me, so why place 
it anywhere else than in my home directory? After all, that's where all 
my personal files reside, so why treat this data otherwise?


but database files are not normal user files and can't be backuped while 
the service is running in a safe way like your personal document files


so it makes little sense to handle different beasts identical

There I have plenty of room in a raid6 configuration, where the default 
location is much smaller, and populated by the infamous (well, with me 
at least) btrfs filesystem.


you can put the data in /home/mysql, make a bind-mount from 
/var/lib/mysql to /home/mysql and change the config to use /var/lib/mysql


voila, ProtectHome no longer hits because from the viewpoint of systemd 
and mariadb the datadir isn't below /home


https://unix.stackexchange.com/questions/198590/what-is-a-bind-mount

___
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

[Reindl Harald]

Am 13.10.22 um 14:16 schrieb Jogchum Reitsma:

Op 13-10-2022 om 01:46 schreef Daniel Black:

On Thu, Oct 13, 2022 at 12:27 AM Jogchum Reitsma
  wrote:


Anyone an idea why /home/jogchum/mysql_recover/linux-mkay.lower-test
can't be created and how to solve that?

In systemd ProtectHome=read-only is the default.

systemctl edit mariadb.service and add:
[Service]
ProtectHome=false

>

When I read /usr/lib/systemd/system/mariadb.service it contains

# Prevent accessing /home, /root and /run/user
ProtectHome=true

I know hardly anything about systemd, so not user waht I should do here?
in the open "/etc/systemd/system/mariadb.service.d/override.conf" add 
what was told above


[Service]
ProtectHome=false

and "Prevent accessing /home, /root and /run/user" as comment in system 
services should tell you something


frankly why don#t you move the datadir out of your suerhome and change 
the path to the datadir in the config?


___
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

[Reindl Harald]

Am 13.10.22 um 13:55 schrieb Jogchum Reitsma:

Op 13-10-2022 om 12:59 schreef Reindl Harald:


All files and dir's under /home/jogchum/mysql_recover have mysql:mysql 
as owner:group


and your userhome is 755 
which is the default, when opensuse creates a new user. So, if I 
understand you right,  that's wrong in your opinion?


plain wrong but i don#t even know the default of my Fedora machines 
given that the last time i saw an os-installer was in 2011 thanks to 
RAID and backups


as well as systemd namespaces and SELinux allowing nosense like 
storing the databasedir in a userhome?


Why is that nonsense? After all, it's not a company database we're 
talking about, just


and how does that justify doing something different than anybody else 
out there?


- some addresses of friends and family, mainly used for sending 
Christmas cards,

- some metadata about video's I recorded,
- some data about the yield of our solar panels.

Nothing secret in that.


i wonder if the friends see that this relaxed too, in europe there is 
more undestanding of privacy and data security as in the USA...


just don't do that - and be it only because it's dumb set your 
userhome to chmod 755 which means any 644 file can be read by anyone


As said, I did not chmod it to 755, it's the opensuse default (and maybe 
other distro's too, dunno). And anyone in my family is allowed to read 
anything on our systems.


More important, you don't say anything about how I could start the 
database?


dunno but this part of the logs is looking bad - on a updated machine 
that mustnt't have started at all and indicates for me the damage was 
that large that your installation looked like a fresh one


okt 02 21:26:55 linux-mkay mysql-systemd-helper[45372]: Creating MySQL 
privilege database...
okt 02 21:27:17 linux-mkay mysql-systemd-helper[45384]: Two 
all-privilege accounts were created.
okt 02 21:27:17 linux-mkay mysql-systemd-helper[45384]: One is 
root@localhost, it has no password, but you need to
okt 02 21:27:17 linux-mkay mysql-systemd-helper[45384]: be system 'root' 
user to connect. Use, for example, sudo mysql
okt 02 21:27:17 linux-mkay mysql-systemd-helper[45384]: The second is 
mysql@localhost, it has no password either, but
okt 02 21:27:17 linux-mkay mysql-systemd-helper[45384]: you need to be 
the system 'mysql' user to connect.


___
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

[Reindl Harald]

Am 13.10.22 um 12:14 schrieb Jogchum Reitsma:

Op 12-10-2022 om 16:48 schreef Sergei Golubchik:

Hi, Jogchum,

Anyone an idea why /home/jogchum/mysql_recover/linux-mkay.lower-test
can't be created and how to solve that?

permission problem, perhaps?
All files and dir's under /home/jogchum/mysql_recover have mysql:mysql 
as owner:group


and your userhome is 755 as well as systemd namespaces and SELinux 
allowing nosense like storing the databasedir in a userhome?


just don't do that - and be it only because it's dumb set your userhome 
to chmod 755 which means any 644 file can be read by anyone


___
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] mysql_upgrade fails

[Reindl Harald]

Am 21.07.22 um 13:01 schrieb Hartmut Holzgraefe:

On 21.07.22 10:37, Reindl Harald wrote:

10.2.x to 10.2.y and mysql_upgrade crashing


can you point me at a related bug report for that?


i can't find it in the archives and it was one of my replies to a point 
update release anouncement


* rpmbuild from sources
* upgrade
* as everytime run "mysql_upgrade"
* mysql_upgrade itself didn't work / crashed

yeah, it was fixed at the next point release but it tells a lot about 
how well it's tested at all


___
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] mysql_upgrade fails

[Reindl Harald]

Am 21.07.22 um 10:54 schrieb Majed Zouhairy:
so what is the solution? what Imeant by 10.4, is that the new version of 
zabbix does not support mariadb below 10.5


and how does that change the upgrade path?

10.2 -> 10.3 -> mysql_upgrade
10.3 -> 10.4 -> mysql_upgrade
10.4 -> 10.5 -> mysql_upgrade

how does that lead to 10.6 instead, well 10.5?

"i just upgraded zabbix and it doesn't support version 10.4" normally 
you *first* look at the requirements



must i report a bug report somewhere else?

*From:* Maria-discuss 
 on 
behalf of Reindl Harald 

*Sent:* Thursday, July 21, 2022 11:37 AM
*To:* maria-discuss@lists.launchpad.net 
*Subject:* Re: [Maria-discuss] mysql_upgrade fails


Am 21.07.22 um 07:48 schrieb Majed Zouhairy:
i just upgraded zabbix and it doesn't support version 10.4 so that's 
why.. and it failed the upgrade prior to version 10.3


irrelevant - i would make a major upgrade followed by mysql_upgrade one
by one no matter what "it doesn't support version 10.4" means

when it comes to "mysql_upgrade" i don't trust what developers say given
that it even crashed hard after bugfix point-updates in the past (which
now stops with the message "There is no need to run mysql_upgrade again")

10.2.x to 10.2.y and mysql_upgrade crashing but now developers pretend
they even *really test* jumps from 10.2 to 10.6 - are you guys kidding me?

*From:* Maria-discuss 
 on 
behalf of Reindl Harald 

*Sent:* Wednesday, July 20, 2022 1:39 PM
*To:* maria-discuss@lists.launchpad.net 
*Subject:* Re: [Maria-discuss] mysql_upgrade fails


Am 20.07.22 um 09:34 schrieb Majed Zouhairy:
on centos 8, upgrade form mraidb 10.3 to 10.6 fails 


it's not that smart to skip major versions

why for the sake of god do you not upgrade 10.3 -> 10.4 -> 10.5 -> 10.6
like everybody else?


___
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] mysql_upgrade fails

[Reindl Harald]

Am 21.07.22 um 07:48 schrieb Majed Zouhairy:
i just upgraded zabbix and it doesn't support version 10.4 so that's 
why.. and it failed the upgrade prior to version 10.3


irrelevant - i would make a major upgrade followed by mysql_upgrade one 
by one no matter what "it doesn't support version 10.4" means


when it comes to "mysql_upgrade" i don't trust what developers say given 
that it even crashed hard after bugfix point-updates in the past (which 
now stops with the message "There is no need to run mysql_upgrade again")


10.2.x to 10.2.y and mysql_upgrade crashing but now developers pretend 
they even *really test* jumps from 10.2 to 10.6 - are you guys kidding me?


*From:* Maria-discuss 
 on 
behalf of Reindl Harald 

*Sent:* Wednesday, July 20, 2022 1:39 PM
*To:* maria-discuss@lists.launchpad.net 
*Subject:* Re: [Maria-discuss] mysql_upgrade fails


Am 20.07.22 um 09:34 schrieb Majed Zouhairy:
on centos 8, upgrade form mraidb 10.3 to 10.6 fails 


it's not that smart to skip major versions

why for the sake of god do you not upgrade 10.3 -> 10.4 -> 10.5 -> 10.6
like everybody else?


___
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] mysql_upgrade fails

[Reindl Harald]

Am 20.07.22 um 09:34 schrieb Majed Zouhairy:
on centos 8, upgrade form mraidb 10.3 to 10.6 fails 


it's not that smart to skip major versions

why for the sake of god do you not upgrade 10.3 -> 10.4 -> 10.5 -> 10.6 
like everybody else?


___
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

[Maria-discuss] Fwd: [MariaDB Announce] MariaDB 10.8.1 RC and MariaDB 10.7.2, 10.6.6, 10.5.14, 10.4.23, 10.3.33 and 10.2.42 now available

[Reindl Harald]

https://downloads.mariadb.org/mariadb/10.3.33/

points to a form with 10.6 preselected because a redirect to 
https://mariadb.org/download/?t=mariadb=mariadb=10.6.5=Linux=x86_64=tar_gz=systemd=nextlayer


and in that useless form 10.3.32 is the newest you can select when 
trying to download sources


is there a reason why such nonsense on download pages is developed other 
than "some people need to be busy"?


when you change to 10.3 and have selcted "source" before the form goes 
back to Linux with systemd as selection


head - table - match

 Weitergeleitete Nachricht 
Betreff: [MariaDB Announce] MariaDB 10.8.1 RC and MariaDB 10.7.2, 
10.6.6, 10.5.14, 10.4.23, 10.3.33 and 10.2.42 now available


MariaDB 10.3.33
   - Release Notes: https://mariadb.com/kb/en/mdb-10333-rn/
   - Changelog: https://mariadb.com/kb/en/mdb-10333-cl/
   - Downloads: https://downloads.mariadb.org/mariadb/10.3.33/

___
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] Issues with Upgrading from MariaDB 10.2.22 to 10.5.12

[Reindl Harald]

Am 25.08.21 um 16:53 schrieb Michael Caplan:

Thanks Gordan,

Maybe I'm misrepresenting / misunderstanding the info found here: 
https://mariadb.com/kb/en/upgrading-between-major-mariadb-versions/ But 
it seems a straight shot upgrade is a-okay


but common sense should tell you it's a bad idea

you maximize all unexpexted problems by summary them at the same point 
of time and virtually nobody did the same jump as you are doing at that 
point of time



On 2021-08-25 11:45 a.m., Gordan Bobic wrote:
I don't think skipping releases in an upgrade is supported. So you 
need to upgrade
10.2 to 10.3 to 10.4 to 10.5, with any additional caveats for specific 
version upgrades (e.g. InnoDB log format change during 10.2).


On Wed, 25 Aug 2021, 15:00 Michael Caplan, > wrote:


Hi there.

I'm going through an upgrade process I have done before with earlier
versions of mariaDB and Mysql, but running into an issue. My goal
is to
create a new slave including upgrade process from MariaDB 10.2.22
(serverOld) to 10.5.12 on a new server (serverNew)

(as inspired by the brighter mind at

https://www.stephenrlang.com/2016/08/setting-up-mysql-master-slave-replication-with-rsync/



)

  1. rsync /var/lib/mysql from serverOld to serverNew
  2. On serverOld:  FLUSH TABLES WITH READ LOCK;  SHOW MASTER STATUS;
  3. rerun rsync from serverOld to serverNew
  4. Release read lock from serverOld
  5. Start mariadb on serverNew
  6. run mysql_upgrade on serverNew
  7. Celebrate and have a nap


In actual practice step #5 failed numerous times before what I
think is
now an okay serverNew


# Innodb settings between serverOld and serverNew

#serverOld
innodb-flush-method    = O_DIRECT
innodb-log-files-in-group  = 2
innodb-log-file-size   = 48M
innodb-flush-log-at-trx-commit = 2
innodb-file-per-table  = 1
innodb-buffer-pool-size    = 128M

#serverNew
innodb-flush-method    = O_DIRECT
innodb-log-file-size   = 48M
innodb-flush-log-at-trx-commit = 2
innodb-file-per-table  = 1
innodb-buffer-pool-size    = 128M


The only difference is innodb-log-files-in-group setting is
removed in
serverNew, as it has been depricated and removed in 10.5



# Upgrade after crash?

When attempting to start serverNew, it would fail with the
following error:

[ERROR] InnoDB: Upgrade after a crash is not supported. The redo
log was
created with MariaDB 10.2.22.
[ERROR] InnoDB: Plugin initialization aborted with error Generic error

the log file on serverOld showed no evidence of crashing. None the
less, I restarted serverOld, and reran the process above. Still
the same
issue step #5.


# Remove ib_logfile* files

I then tried forcing the recreation of the redo logs by removing them
and then starting up serverNew.  This resulted in the following scary
errors:

[ERROR] InnoDB: Page [page id: space=0, page number=1984] log
sequence
number 285722576186 is in the future! Current system log sequence
number
259573448177.
[ERROR] InnoDB: Your database may be corrupt or you may have
copied the
InnoDB tablespace but not the InnoDB log files. Please refer to
https://mariadb.com/kb/en/library/innodb-recovery-modes/
 for
information
about forcing recovery.


# innodb_fast_shutdown = 0

The next attempt started with serverOld being restarted and
innodb_fast_shutdown = 0 being set beforehand.  I reran the above
steps
and still got stuck on step #5 with the following error:

[ERROR] InnoDB: Upgrade after a crash is not supported. The redo
log was
created with MariaDB 10.2.22.
[ERROR] InnoDB: Plugin initialization aborted with error Generic error

This time, however, when I removed the ib_logfile* files, we
seemed to
have an okay startup:

[Note] InnoDB: Initializing buffer pool, total size = 134217728,
chunk
size = 134217728
[Note] InnoDB: Completed initialization of buffer pool
[Note] InnoDB: Setting log file ./ib_logfile101 size to 50331648 bytes
[Note] InnoDB: Renaming log file ./ib_logfile101 to ./ib_logfile0
[Note] InnoDB: New log file created, LSN=288830457728
[Note] InnoDB: 128 rollback segments are active.
[Note] InnoDB: Removed temporary tablespace data file: "ibtmp1"
[Note] InnoDB: Creating shared tablespace for temporary tables
[Note] InnoDB: Setting file './ibtmp1' size to 12 MB. Physically
writing
the file full; Please wait ...
[Note] InnoDB: File './ibtmp1' size is now 12 MB.
[Note] InnoDB: 10.5.12 started; log sequence number 0; transaction id
3037161218
[Note] 

Re: [Maria-discuss] MySQL crash after 'partial' version upgrade

[Reindl Harald]

Am 26.07.21 um 17:30 schrieb William Edwards:

William Edwards schreef op 2021-07-23 19:16:

Hello,

The weather probably has an effect on me, because I'm not seeing the
cause for the issue below right away. Hopefully someone can use the
cluebat. Also, I apologize if we're not supposed to paste snippets of
this size in email, but I couldn't find a mailing list policy on this.


Some additional information after further debugging:

- The upgrade started at 16:06:18, MariaDB shut down gracefully at 
16:06:23, but - while the upgrade was still in progress - started again 
exactly 5 seconds later at 16:06:28. This makes me suspect a watchdog 
started MariaDB at the wrong time. However, MariaDB shut down 
gracefully, so systemd's 'Restart=on-abort' shouldn't have done anything.
- The server starts up fine with a new datadir created by 
'mysql_install_db'. This confirms the suspicion that the data was 
corrupted because of *something* that happened during the upgrade


that's why we don't use "mysqld_safe" and don't package 
"mysql_install_db" as well as we don't restart services at updates in 
our internal packages


it's simply idiotic doing that within a dist-upgrade and for minor 
version updates even more


___
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] dist-upgrade for minor version upgrade

[Reindl Harald]

Am 10.07.21 um 16:58 schrieb William Edwards:

Hi,

https://mariadb.com/kb/en/upgrading-from-mariadb-104-to-mariadb-105/ 
(and all other minor upgrade guides) contain these steps:


2. Stop MariaDB.
3. Uninstall the old version of MariaDB:
    On Debian, Ubuntu, and other similar Linux distributions, execute 
the following:

    sudo apt-get remove mariadb-server
4. Install the new version of MariaDB.

I'm thinking to myself: doesn't it make more sense to instruct readers 
to 'dist-upgrade' on Ubuntu and Debian (which works because of the 
'Replaces' in newer packages)? That would merge steps 3 and 4 (and maybe 
step 2 as well, because of stop_server() in preinst) into one command 
that could be easier to use for novice users.


Sorry if I missed a detail that dist-upgrade does not take care of


why keep it simple? :-)

our MariaDB instances date back to 2002 aka MySQL3 and the datadir went 
from Windows to MacOSX and later to Linux.


frankly my self built packages don't stop services at upgrades which was 
for most software the reason to blacklist the distribution packages and 
replace them


30 seconds for a dist-upgrade on a VM, reboot, mysql_upgrade, done

___
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] How to Host Multiple Mail Domains (Email Hosting) in iRedMail Full Featured Linux Mail Server

[Reindl Harald]

may i ask you again THIS TIME IN PUBLIC to stop this idiotic mails to 
every single mailing list i am subscribed to?


---

are you mentally ill or why do you send such dumb signatures all the 
time (others already asked to not do that on mailing lists at all)


Mr. Turritopsis Dohrnii Teo En Ming, 43 years old as of 4th May 2021, is 
a TARGETED INDIVIDUAL living in Singapore. He is an IT Consultant with a 
System Integrator (SI)/computer firm in Singapore. He is an IT enthusiast.


---

***IMPORTANT NOTICE*** Please note that Turritopsis Dohrnii Teo En 
Ming’s guide is based on Xiao Guoan’s guide at linuxbabe.com.


nobody gives a shit!

Am 04.05.21 um 16:23 schrieb Turritopsis Dohrnii Teo En Ming:

Subject: How to Host Multiple Mail Domains (Email Hosting) in iRedMail
Full Featured Linux Mail Server

Author: Mr. Turritopsis Dohrnii Teo En Ming (TARGETED INDIVIDUAL)
Country: Singapore
Date: 3rd May 2021 Monday
Type of Publication: PDF Manual
Document Version: 20210503.01

***IMPORTANT NOTICE*** Please note that Turritopsis Dohrnii Teo En
Ming’s guide is based on Xiao Guoan’s guide at linuxbabe.com.

Reference Guide Used by Teo En Ming: How to Host Multiple Mail Domains
in iRedMail with Nginx
Link: 
https://www.linuxbabe.com/mail-server/set-up-iredmail-multiple-domains-nginx
Original Author: Xiao Guoan

The following is a list of open-source software that will be
automatically installed and configured by iRedMail.

• Postfix SMTP server
• Dovecot IMAP server
• Nginx web server to serve the admin panel and webmail
• OpenLDAP, MySQL/MariaDB, or PostgreSQL for storing user information
• Amavised-new for DKIM signing and verification
• SpamAssassin for anti-spam
• ClamAV for anti-virus
• Roundcube webmail
• SOGo groupware, providing webmail, calendar (CalDAV), contacts
(CardDAV), tasks and ActiveSync services.
• Fail2ban for protecting SSH
• mlmmj mailing list manager
• Netdata server monitoring
• iRedAPD Postfix policy server for greylisting

In addition, you need to add MX, A and TXT records to your ISC BIND
DNS domain name server.

Redundant download links for Turritopsis Dohrnii Teo En Ming's PDF manual:

[1] 
https://www.mediafire.com/file/q6txmx0rc1cwfzw/Additional+Mail+Domains+1st+Release.pdf/file

[2] https://www.docdroid.net/Q9TRL5D/additional-mail-domains-1st-release-pdf

[3] 
https://www.scribd.com/document/506193434/Additional-Mail-Domains-1st-Release

[4] 
https://drive.google.com/file/d/10AYGt4-omBeC3vXJfzswQq0M7E09gXpG/view?usp=sharing

[5] 
https://drive.google.com/file/d/113dy0AKmBYGugBueK1vS_dJwI35J6XmJ/view?usp=sharing

[6] 
https://drive.google.com/file/d/1dhpYIZp31ug5hoiVNbjh6uh99s_PEx8q/view?usp=sharing

Mr. Turritopsis Dohrnii Teo En Ming, 43 years old as of 4th May 2021,
is a TARGETED INDIVIDUAL living in Singapore. He is an IT Consultant
with a System Integrator (SI)/computer firm in Singapore. He is an IT
enthusiast.






-BEGIN EMAIL SIGNATURE-

The Gospel for all Targeted Individuals (TIs):

[The New York Times] Microwave Weapons Are Prime Suspect in Ills of
U.S. Embassy Workers

Link:
https://www.nytimes.com/2018/09/01/science/sonic-attack-cuba-microwave.html



Singaporean Targeted Individual Mr. Turritopsis Dohrnii Teo En Ming's
Academic Qualifications as at 14 Feb 2019 and refugee seeking attempts
at the United Nations Refugee Agency Bangkok (21 Mar 2017), in Taiwan
(5 Aug 2019) and Australia (25 Dec 2019 to 9 Jan 2020):

[1] https://tdtemcerts.wordpress.com/

[2] https://tdtemcerts.blogspot.sg/

[3] https://www.scribd.com/user/270125049/Teo-En-Ming

-END EMAIL SIGNATURE-


___
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] Exceeding configured memory

[Reindl Harald]

Am 12.04.21 um 08:31 schrieb Sig Pam:

Hi all!

I run into problems with the memory configuration of MariaDB 10.3.27 on 
Debian 10. It looks as if it exceeds the configured memory.


The server hat 4 GB of memory. It runs MariaDB and a Kopano 
(Mail/Collaboration) server. The configuration I believe I have made is 
2GB for MariaDB, plus 1 GB for Kopano. The rest is for reserved for the OS.


If I look at the process list, I can see that mysql greatly exceeds the 
configured 2GB limit:


root@exchange64:~# ps -e -o "vsz rss pid comm" | grep mysql

4933304 1604212 852 mysqld

The virtual process size is 4.9 GB, with 1.6 GB resident in RAM


VIRT is pointless

Firefox: 45 GB VIRT (main prcoess and 9 workers)
VM1: 9 GB VIRT
VM2: 6 GB VIRT
VM2: 6 GB VIRT
QtWebEngine: 5 GB VIRT
MariaDB: 4 GB VIRT
X11: 3 GB VIRT

[harry@srv-rhsoft:~]$ free -h
  totalusedfree  shared  buff/cache 
available
Mem:   31Gi   3,3Gi   2,1Gi   757Mi25Gi 
   26Gi

Swap: 6,2Gi   7,0Mi   6,2Gi


___
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] MEMORY tables and binlog

[Reindl Harald]

Am 07.04.21 um 14:51 schrieb Antony Stone:

On Wednesday 07 April 2021 at 14:48:55, Reindl Harald wrote:


Am 07.04.21 um 14:46 schrieb Dajka Tamás:

Hi All,

I’m facing a weird error. We’re migrating our old 10.1 multi-master
setup to a new 10.3 cluster (everything is running on Debian).
New-node01 is connected as a slave to the old cluster’s master.

When I tried to set up the replication between the 2 new nodes (with
data files copy), the slave thread stopped nearly immediatelly stating,
that the command is invalid – containing illegal characters. After some
investigation, it turned out, that binlog on the master (new-node01) is
– let’s say – corrupted. After a few iterations/checking I saw, that the
error always happens with some MEMORY tables (I know I can exclude them
from the replica, but want to understand the issue first)


wow - 10 years after stop using memory tables at all because again and
again broken replication they are still a problem?


Does that explain illegal characters such as


DELETE FROM `mydb1`.`collect_output`e#<98>


nope - in our case it was random "record don't exist" errors  when 
replicate a delete-statement


i finally had enough and converted them all to MyISAM for the sake of sanity

___
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] MEMORY tables and binlog

[Reindl Harald]

Am 07.04.21 um 14:46 schrieb Dajka Tamás:

Hi All,

I’m facing a weird error. We’re migrating our old 10.1 multi-master 
setup to a new 10.3 cluster (everything is running on Debian). 
New-node01 is connected as a slave to the old cluster’s master.


When I tried to set up the replication between the 2 new nodes (with 
data files copy), the slave thread stopped nearly immediatelly stating, 
that the command is invalid – containing illegal characters. After some 
investigation, it turned out, that binlog on the master (new-node01) is 
– let’s say – corrupted. After a few iterations/checking I saw, that the 
error always happens with some MEMORY tables (I know I can exclude them 
from the replica, but want to understand the issue first)


wow - 10 years after stop using memory tables at all because again and 
again broken replication they are still a problem?


___
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] Is it possible to upgrade SHA-1 and MD5 algorithms in Mariadb-10.5?

[Reindl Harald]

Am 19.03.21 um 01:47 schrieb Daniel Black:

md5:

extra/mariabackup/xbcloud.cc - old bit, however for old reasons used md5 
as a checksum on a storage format. I'm think can be removed before RHEL9


In SQL there is a MD5 function, we can't just replace that as it will 
break user applications.


sha1:

also a SQL function.

plugin/file_key_management/parser.cc is a digest on the keys, however if 
this is a point of attack you've lost already. I suspect this can be fixed.


sha1 forms part of the mysql_native_password implementation, there's no 
known vulnerabilities in this due to its sha1 usage.


https://mariadb.com/kb/en/authentication-plugin-ed25519/ 
 is available, 
however not everything supports in on the client side.

A mistake was also made (ref MDEV-19217), so a v2 might be needed.

As things like php have mysqlnd and are more strictly tied to MySQL 
rather than MariaDB compatibility so adding MariaDB authentication

plugins hasn't been accepted yet.

On SQL functions, is this going to be a problem? or would a compile 
option that issues a user SQL warning if they are used be useful?


sql functions for sure not matter in that context

besides it would break existing usecases it also would require to change 
applications workign with that data *and* replace the hases with some 
others in *existing* data which is a no-go


--

md5/sha1 are not evil on it's own - it's a matter of what they are used 
for, i have usecases where even MD4 is enough and i use it because it's 
simply faster


it's unlikely in my md4 usecase making sure in autotests that html 
output out of frameworks didn't change to hit a hash-collision at the 
same time a single html attribute in a source code changed


___
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] Problem with InnoDB: Semaphore wait after upgrading to 10.3.27

[Reindl Harald]

Am 16.03.21 um 14:58 schrieb Conor Murphy:

Hi,

We have a handful of servers running MariaDB 10.3. We noticed issues on 
two of them where we were getting issues like "InnoDB: A long semaphore 
wait:--Thread 140602802394880 has waited at dict0stats.cc line 1969 for 
241.00 seconds the semaphore:" and crashes like "ERROR] [FATAL] InnoDB: 
Semaphore wait has lasted > 600 seconds. We intentionally crash the 
server because it appears to be hung.210215  7:14:24 [ERROR] mysqld got 
signal 6 ;"


Turned out that these two servers were running 10.3.27 whereas the 
others were running 10.3.17. After downgrading the two problem servers 
to 10.3.17, all the issues with InnoDB semaphores stopped.


Any ideas on how to track down what change between 10.3.17 to 10.3.27 
might be causing this problem?


any ideas why you jump from 10.3.17 to 10.3.27 at that point in time?

[root@srv-rhsoft:~]$ rpm -q --changelog mariadb | head
* Mo Feb 22 2021 Reindl Harald 
- update to 10.3.28

___
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] Maximum possible memory usage: 123.3G

[Reindl Harald]

Am 19.02.21 um 09:58 schrieb Gordan Bobic:

You are _vastly_ over-tuning, IMO.
Do you actually have empirical evidence that each of the settings you 
are changing is actually yielding a net overall improvement?


yes, it needs to serve only one homegrown application with a few hundret 
instances


Are you actually using MyISAM? 


surely, i could puke everytime i see "ibdata1"

Are you _sure_ that enlarging 
join_buffer_size is helping in your case? 


yes

Query cache is almost always 
harmful if you have done your real optimisation appropriately.


it's not when you know what you are doing like no-cache-hints for 
optimized fast queries


not every query can be optimized and a slow query is terrible for an 
application which typically serves a web-request within 348 us (full 
cache hits, no mysql connection at all)


Is that mysqltuner output you pasted? It is a downright dangerous tool 
that far too often gives cripplingly terrible advice.


i don't follow it blindly

besides not answering any of my questions you really could only reply to 
the list and so not break my reply-list-button with your faster off-list 
copy


On Fri, 19 Feb 2021, 08:08 Reindl Harald, <mailto:h.rei...@thelounge.net>> wrote:


h - i thought i had the per-thread buffers down to a value which
would be reasonable in case the max number of connections is reached

i guess that two are guilty but with low "myisam_sort_buffer_size"
optimize large tables fail from my expierience and a small
"join_buffer_size" don't work well too

are these *really* allocated unconditional per-thread or only in case
it's needed?

myisam_sort_buffer_size = 15M
join_buffer_size = 1M

---

[--] Up for: 19h 10m 52s (174K q [2.520 qps], 688 conn, TX: 65M, RX:
11M)
[--] Reads / Writes: 69% / 31%
[--] Binary logging is enabled (GTID MODE: ON)
[--] Physical Memory     : 31.2G
[--] Max MySQL memory    : 123.3G
[--] Other process memory: 0B
[--] Total buffers: 450.0M global + 251.7M per thread (500 max threads)
[--] P_S Max memory usage: 0B
[--] Galera GCache Max memory usage: 0B
[OK] Maximum reached memory usage: 4.9G (15.57% of installed RAM)
[!!] Maximum possible memory usage: 123.3G (394.87% of installed RAM)
[!!] Overall possible memory usage with other process exceeded memory

---

max_allowed_packet                      = 250M
max_tmp_tables                          = 100
max_connect_errors                      = 500
max_delayed_threads                     = 30

max_connections                         = 500
back_log                                = 1000

query_cache_limit                       = 512K
query_cache_min_res_unit                = 1024
query_cache_size                        = 32M
query_cache_type                        = 1

table_cache                             = 5000
table_definition_cache                  = 512
thread_cache_size                       = 100
tmp_table_size                          = 256M
max_heap_table_size                     = 256M

key_buffer_size                         = 32M
sort_buffer_size                        = 128K
myisam_sort_buffer_size                 = 15M
join_buffer_size                        = 1M
preload_buffer_size                     = 128K
read_buffer_size                        = 128K
read_rnd_buffer_size                    = 128K

innodb_buffer_pool_size                 = 96M
innodb-defragment                       = 1
innodb_buffer_pool_dump_at_shutdown     = 0
innodb_buffer_pool_instances            = 1
innodb_checksum_algorithm               = NONE
innodb_doublewrite                      = 1
innodb_file_per_table                   = 1
innodb_flush_log_at_trx_commit          = 2
innodb_flush_method                     = O_DIRECT
innodb_io_capacity                      = 1000
innodb_lock_wait_timeout                = 50
innodb_log_buffer_size                  = 2M
innodb_log_file_size                    = 32M
innodb_max_dirty_pages_pct              = 60
innodb_max_purge_lag                    = 20
innodb_open_files                       = 300
innodb_page_cleaners                    = 1
innodb_purge_threads                    = 1
innodb_read_io_threads                  = 4
innodb_stats_on_metadata                = 0
innodb_strict_mode                      = 1
innodb_table_locks                      = 0
innodb_thread_concurrency               = 0
innodb_thread_sleep_delay               = 10
innodb_write_io_threads                 = 4
transaction-isolation                   = READ-COMMITTED

server-id                               = 1
expire_logs_days         

[Maria-discuss] Maximum possible memory usage: 123.3G

[Reindl Harald]

h - i thought i had the per-thread buffers down to a value which 
would be reasonable in case the max number of connections is reached


i guess that two are guilty but with low "myisam_sort_buffer_size" 
optimize large tables fail from my expierience and a small 
"join_buffer_size" don't work well too


are these *really* allocated unconditional per-threaf or only in case 
it's needed?


myisam_sort_buffer_size = 15M
join_buffer_size = 1M

---

[--] Up for: 19h 10m 52s (174K q [2.520 qps], 688 conn, TX: 65M, RX: 11M)
[--] Reads / Writes: 69% / 31%
[--] Binary logging is enabled (GTID MODE: ON)
[--] Physical Memory : 31.2G
[--] Max MySQL memory: 123.3G
[--] Other process memory: 0B
[--] Total buffers: 450.0M global + 251.7M per thread (500 max threads)
[--] P_S Max memory usage: 0B
[--] Galera GCache Max memory usage: 0B
[OK] Maximum reached memory usage: 4.9G (15.57% of installed RAM)
[!!] Maximum possible memory usage: 123.3G (394.87% of installed RAM)
[!!] Overall possible memory usage with other process exceeded memory

---

max_allowed_packet  = 250M
max_tmp_tables  = 100
max_connect_errors  = 500
max_delayed_threads = 30

max_connections = 500
back_log= 1000

query_cache_limit   = 512K
query_cache_min_res_unit= 1024
query_cache_size= 32M
query_cache_type= 1

table_cache = 5000
table_definition_cache  = 512
thread_cache_size   = 100
tmp_table_size  = 256M
max_heap_table_size = 256M

key_buffer_size = 32M
sort_buffer_size= 128K
myisam_sort_buffer_size = 15M
join_buffer_size= 1M
preload_buffer_size = 128K
read_buffer_size= 128K
read_rnd_buffer_size= 128K

innodb_buffer_pool_size = 96M
innodb-defragment   = 1
innodb_buffer_pool_dump_at_shutdown = 0
innodb_buffer_pool_instances= 1
innodb_checksum_algorithm   = NONE
innodb_doublewrite  = 1
innodb_file_per_table   = 1
innodb_flush_log_at_trx_commit  = 2
innodb_flush_method = O_DIRECT
innodb_io_capacity  = 1000
innodb_lock_wait_timeout= 50
innodb_log_buffer_size  = 2M
innodb_log_file_size= 32M
innodb_max_dirty_pages_pct  = 60
innodb_max_purge_lag= 20
innodb_open_files   = 300
innodb_page_cleaners= 1
innodb_purge_threads= 1
innodb_read_io_threads  = 4
innodb_stats_on_metadata= 0
innodb_strict_mode  = 1
innodb_table_locks  = 0
innodb_thread_concurrency   = 0
innodb_thread_sleep_delay   = 10
innodb_write_io_threads = 4
transaction-isolation   = READ-COMMITTED

server-id   = 1
expire_logs_days= 21
max_binlog_size = 256M
binlog-format   = ROW
binlog_stmt_cache_size  = 256K
binlog_cache_size   = 256K
sync_binlog = 30
log_bin_compress= 1
binlog-ignore-db= autotest
replicate-ignore-db = autotest

low-priority-updates
skip-symbolic-links
skip-name-resolve
safe-user-create

[mariadb]
aria_pagecache_buffer_size  = 32m
aria_sort_buffer_size   = 32m
aria_page_checksum  = 0
key_cache_segments  = 8
thread_handling = pool-of-threads
thread_pool_idle_timeout= 900

---

MariaDB [(none)]> show variables where variable_name!='optimizer_switch' 
and variable_name!='log_slow_filter' and 
variable_name!='session_track_system_variables' and variable_name not 
like '%ssl%' and variable_name!='version_source_revision' and 
variable_name not like 'log_bin%' and value not like '/var/log%' and 
value not like '%/data/%' and value not like '/var/%' and value not like 
'/usr%';

+-++
| Variable_name   | Value  |
+-++
| alter_algorithm | DEFAULT|
| aria_block_size | 8192   

Re: [Maria-discuss] Set password for all users, regardless of host value

[Reindl Harald]

Am 05.09.20 um 12:32 schrieb Sergei Golubchik:
>> i guess beause not everybody likes % when a user should only have
>> access from 3 hosts - defense in depth
> 
> Hmm, okay. I see. Unfortunately it means creating three distinct
> accounts doing grants three times, etc. And they can get out of sync
> too.

which was easy to avoid by simply fire up the same queries followed by
"flush privileges" before the json crap

everytime when json is the solution i want my problem back

___
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] Set password for all users, regardless of host value

[Reindl Harald]

Am 05.09.20 um 12:32 schrieb Sergei Golubchik:
> On Sep 05, Reindl Harald wrote:
>> well, why in the world was a clear structure replaced with some
>> json-like crap?
> 
> for a couple of reasons.
> every new release was adding more columns to mysql.user, and
> mysql_upgrade was getting more and more complex trying to convert all
> possible intermediate table structures into the latest. and the
> privilege code was doing the same, as it should work without
> mysql_upgrade, so it was guessing and adapting to all intermediate
> numbers of columns. Not always correctly, the latest bug here is MDEV-23201.

and how does json crap magically solve the issue?

> with a json we'll never need to run mysql_upgrade on mysql.user and
> mysql.global_priv ever. I hope :)

yeah, throwing away structure to not need to update structure in the
future - my god send an asteroid making and end to the human race :-)

> a second reason - mysql.user can only have one auth plugin per user,
> while 10.4 supports multiple alternative authentications.
> 
> besides, it doesn't matter whether the structure is clear or json-like
> crap, privilege tables are internal matter of the server, users can but
> aren't supposed to look inside, there is no guarantee that the structure
> will be stable or readable. changing privilege tables directly is
> fragile and is not recommended since 2000.

but it worked - cleaner and quicker than crafting special queries you
mostly need only once or twice per year

one reason going back to 10.3 as long as possible

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] Set password for all users, regardless of host value

[Reindl Harald]

Am 05.09.20 um 10:37 schrieb Sergei Golubchik:
> Hi, Chris!
> 
> On Sep 04, Chris Ross (cross2) wrote:
>> Hello there.  We have scripts to restore credentials to MySQL
>> databases from external store.  The mechanism that was in use,
>> however, stores usernames and passwords, without consideration of the
>> scope (host) of that auth record.  In older systems, UPDATE mysql.user
>> SET password = PASSWORD(‘rawpassword’) WHERE user = ‘username’ worked,
>> updating it for all values of that user that might exist in the table.
>>
>> But, I’m not sure how to do this for MariaDB 10.5.  Is there way to
>> form an “ALTER USER” statement such that it will set the password for
>> any and all userspecs that exist with the given username?  We don’t
>> have that many, and I could iterate the known configurations with
>> “ALTER USER IF EXISTS”, but I worry that might miss things added in
>> the future.
> 
> Yes, you can do an ALTER USER statement, something like
> 
>   for x in (select host from mysql.global_priv where user='username') do
> execute immediate concat('alter user ', 'username', '@`', x.host, '` 
> identified ...and so on' );
>   end for

wow is that ugly

> you can do an UPDATE too, like
> 
>   update mysql.global_priv set priv=json_set(priv, 'authentication_string', 
> password(‘rawpassword’))
> 
> this is rather fragile and of course not recommended.

well, why in the world was a clear structure replaced with some
json-like crap?

> But I think what you're doing is somewhat strange. You have multiple
> accounts with the same username and different hosts, and you want the
> same password for them all? Why do you have multiple accounts in the
> first place?

i guess beause not everybody likes % when a user should only have access
from 3 hosts - defense in depth

___
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] Missing table rows when importing a MySQL 5.7.8 database into MariaDB 10.4.8 database

[Reindl Harald]

Am 27.08.20 um 08:19 schrieb ell...@elliotmywebguy.com:
> No reason. I stated what version I was using in my first post and even
> asked if that could have been the issue. Lesson learned.

indeed, in the middle of the post "Maybe do I need to upgrade to MariaDB
10.4.14"

the amount of bugfixes is amazing in every point release

https://mariadb.com/kb/en/mariadb-1049-changelog/
https://mariadb.com/kb/en/mariadb-10410-changelog/
https://mariadb.com/kb/en/mariadb-10411-changelog/
https://mariadb.com/kb/en/mariadb-10412-changelog/
https://mariadb.com/kb/en/mariadb-10413-changelog/
https://mariadb.com/kb/en/mariadb-10414-changelog/


> On Aug 27, 2020 2:05 AM, Reindl Harald  wrote:
> 
> 
> 
> Am 27.08.20 um 03:30 schrieb Elliot Holden:
> > Long story short, I updated MariaDB Server from 10.4.8 to 10.4.14 and
> > problem solved.
> 
> what was the point using a nearly one year old version to begin with
> (sorry for not realize the outfated version in the subject after your
> first post)
> 
> i won't even consider touching the second bugfix release of a new major
> vesion in production and the first thing i do when whatever softtware
> has issues "is there a newer version which probably fix that"
> 
> Name Release Date Release Status
> 10.4.14 2020-08-10 Stable
> 10.4.13 2020-05-12 Stable
> 10.4.12 2020-01-28 Stable
> 10.4.11 2019-12-11 Stable
> 10.4.10 2019-11-08 Stable
> 10.4.8 2019-09-11 Stable
> 10.4.7 2019-07-31 Stable
> 10.4.6 2019-06-18 Stable


___
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] Missing table rows when importing a MySQL 5.7.8 database into MariaDB 10.4.8 database

[Reindl Harald]

Am 27.08.20 um 03:30 schrieb Elliot Holden:
> Long story short, I updated MariaDB Server from 10.4.8 to 10.4.14 and
> problem solved.

what was the point using a nearly one year old version to begin with
(sorry for not realize the outfated version in the subject after your
first post)

i won't even consider touching the second bugfix release of a new major
vesion in production and the first thing i do when whatever softtware
has issues "is there a newer version which probably fix that"

NameRelease DateRelease Status
10.4.14 2020-08-10  Stable
10.4.13 2020-05-12  Stable
10.4.12 2020-01-28  Stable
10.4.11 2019-12-11  Stable
10.4.10 2019-11-08  Stable
10.4.8  2019-09-11  Stable
10.4.7  2019-07-31  Stable
10.4.6  2019-06-18  Stable

___
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] MariaDB 10.4: subtle change of result ordering

[Reindl Harald]

Am 24.08.20 um 14:23 schrieb Sergei Golubchik:
> Sorry, I couldn't understand, was 10.3 returning 3..2..1 and 10.4
> started to return 1..2..3? Or was it the other way around?

that at a bottom is a unified iff between expected output and what
happens when trying 10.4.14

10.2 and 10.3 returning 1-2-3 for years
10.4.14 in the identical environemnt returns 3-2-1

* they are created 1-2-3
* timestamps identical because created in same second
* 'desc' ordering by timestamp gave 1-2-3

my issue is not that the result as such could be called wrong but that
it changes after years, the autotests which is part of a bug testsuite
has the expected HTML output base64 decoded, fires a diff against the
now created html-output and alerts if there is a byte changed

> I tried your table structure and your test data on both 10.3 and 10.5
> and in both cases I've got 3..2..1
> 
> On Aug 21, Reindl Harald wrote:
>>
>> in all previous versions this test was stable, so as the timestamps are
>> identical and ordering is 'desc' the result was ordered by the creation
>> time of the the records
> ... 
>> diff of the expected application output:
>>
>> -Autotest> name="commentpart">> href="comments_add.php?s2id=1">VerfassenCMS-Autotest
>> 1Test Test Test Test Test Test
>> Test Test Test TestCMS-Autotest
>> 2Test Test Test Test Test Test
>> Test Test Test TestCMS-Autotest
>> 3Test Test Test Test Test Test
>> Test Test Test
>> Test
>>
>> +Autotest> name="commentpart">> href="comments_add.php?s2id=1">VerfassenCMS-Autotest
>> 3Test Test Test Test Test Test
>> Test Test Test TestCMS-Autotest
>> 2Test Test Test Test Test Test
>> Test Test Test TestCMS-Autotest
>> 1Test Test Test Test Test Test
>> Test Test Test
>> Test

___
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] MariaDB 10.4: subtle change of result ordering

[Reindl Harald]

Am 24.08.20 um 09:46 schrieb Sergei Golubchik:
> Hi, Reindl!
> 
> 1. Is it 10.3 to 10.4 difference? There were some optimizations that
> could have such an effect.
> https://mariadb.com/kb/en/changes-improvements-in-mariadb-104/#optimizer
> Can you share the table structure?

it is a 10.3 to 10.4 interface, hence the 10.4 in the subject

> 2. Technically, MyISAM only returns rows in the order of insertion if
> you insert into an empty table. This was always the case, see this
> simple test:
> 
>   create table t1 (a int) engine=myisam;
>   insert t1 values (1),(2),(3),(4),(5); select * from t1;
>   delete from t1 where a<10;select * from t1;
>   insert t1 values (1),(2),(3),(4),(5); select * from t1;
>   drop table t1;
> 
> I don't think this is your case though.

given that tjis is an autotest that table is *always* empty at the begin
of the autotest suite

> On Aug 21, Reindl Harald wrote:
>> MyISAM:
>>
>> in all previous versions this test was stable, so as the timestamps are
>> identical and ordering is 'desc' the result was ordered by the creation
>> time of the the records
>>
>> now it's reverse which can break all sort of expectations in subtle ways
>>
>> while we could discuss what is the expected output when order by
>> 'ktimestamp' and all are identical it still worries me that something
>> which didn't change over years and major versions now comes with the
>> reverse ordering
>>
>> unless someone tells me that's the result of some real peformance
>> optimization i would perfer the known result given that it's hard to
>> know how much other code depends implicit on the previous behavior
>>
>> -
>>
>> select SQL_NO_CACHE SQL_CALC_FOUND_ROWS * from `cl_autotest_comments`
>> where ksid=1 and kaktiv=1  order by ktimestamp desc limit 0,10
>>
>> -
>>
>> Array
>> (
>> [0] => Array
>> (
>> [kid] => 1
>> [kaktiv] => 1
>> [ksid] => 1
>> [ks2id] => 0
>> [ktimestamp] => 1598022502
>> [kip] => 127.0.0.1
>> [kname] => CMS-Autotest 1
>> [kherkunft] => Wien
>> [kkommentar] => Test Test Test Test Test Test Test Test Test
>> Test
>> )
>>
>> [1] => Array
>> (
>> [kid] => 2
>> [kaktiv] => 1
>> [ksid] => 1
>> [ks2id] => 0
>> [ktimestamp] => 1598022502
>> [kip] => 127.0.0.1
>> [kname] => CMS-Autotest 2
>> [kherkunft] => Wien
>> [kkommentar] => Test Test Test Test Test Test Test Test Test
>> Test
>> )
>>
>> [2] => Array
>> (
>> [kid] => 3
>> [kaktiv] => 1
>> [ksid] => 1
>> [ks2id] => 0
>> [ktimestamp] => 1598022502
>> [kip] => 127.0.0.1
>> [kname] => CMS-Autotest 3
>> [kherkunft] => Wien
>> [kkommentar] => Test Test Test Test Test Test Test Test Test
>> Test
>> )
>>
>> )
>>
>> -
>>
>> diff of the expected application output:
>>
>> -Autotest> name="commentpart">> href="comments_add.php?s2id=1">VerfassenCMS-Autotest
>> 1Test Test Test Test Test Test
>> Test Test Test TestCMS-Autotest
>> 2Test Test Test Test Test Test
>> Test Test Test TestCMS-Autotest
>> 3Test Test Test Test Test Test
>> Test Test Test
>> Test
>>
>> +Autotest> name="commentpart">> href="comments_add.php?s2id=1">VerfassenCMS-Autotest
>> 3Test Test Test Test Test Test
>> Test Test Test TestCMS-Autotest
>> 2Test Test Test Test Test Test
>> Test Test Test TestCMS-Autotest
>> 1Test Test Test Test Test Test
>> Test Test Test
>> Test

___
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] MariaDB 10.4: subtle change of result ordering

[Reindl Harald]

Am 21.08.20 um 17:44 schrieb Rodrigo Severo:
> ‐‐‐ Original Message ‐‐‐
> On Friday, August 21, 2020 12:18 PM, Reindl Harald  
> wrote:
> 
>> MyISAM:
>>
>> in all previous versions this test was stable, so as the timestamps are
>> identical and ordering is 'desc' the result was ordered by the creation
>> time of the the records
>>
>> now it's reverse which can break all sort of expectations in subtle ways
>>
>> while we could discuss what is the expected output when order by
>> 'ktimestamp' and all are identical it still worries me that something
>> which didn't change over years and major versions now comes with the
>> reverse ordering
>>
>> unless someone tells me that's the result of some real peformance
>> optimization i would perfer the known result given that it's hard to
>> know how much other code depends implicit on the previous behavior
> 
> 
> I would say that the actual ordering of the records below obtained by the 
> select command shown is undefined. I can very well change for whatever subtle 
> change in code.
> 
> AFAIU, if you need repeatable results, you need to write a select command 
> with a deterministic result.
> 
> If this test has been presenting repeatable results for a long time, that's 
> just chance.
> 
> But that's just the opinion of a MariaDB user. I'm no developer. I would like 
> to know the opinion of the developers.

without explicit ordering the behavior of MyISAM is that you get results
in der ordering the are created and so 'desc' can be and was deterministic

you can even "later table" with ordering MyISAM tables so that the
records are phyisally stored in the ordering they are typically fetched
for the workload

___
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

[Maria-discuss] Mariadb 10.4: mysql_test broken - No option named 'plugin-dir' in group 'mysqld.1' at lib/My/ConfigFactory.pm line 349

[Reindl Harald]

one last thing before i restore the snapshot with the latest 10.3 build

-

/usr/bin/su -c 'cd /usr/share/mysql-test; ./mysql-test-run.pl
--parallel=4 --max-test-fail=0 --mysqld=--binlog-format=row --force
--suites="main-,binlog-,csv-,funcs_1-,funcs_2-,handler-,heap-,maria-,optimizer_unfixed_bugs-,parts-,innodb-,roles-,rpl-,sys_vars-,unit-,vcol-"
--skip-test-list=/var/lib/mysql/skip-tests.txt' mysql

-

[root@testserver:~]$ mysql-test.sh
Logging: ./mysql-test-run.pl  --parallel=4 --max-test-fail=0
--mysqld=--binlog-format=row --force
--suites=main-,binlog-,csv-,funcs_1-,funcs_2-,handler-,heap-,maria-,optimizer_unfixed_bugs-,parts-,innodb-,roles-,rpl-,sys_vars-,unit-,vcol-
--skip-test-list=/var/lib/mysql/skip-tests.txt
Using binlog format 'row'
vardir: /usr/share/mysql-test/var
Removing old var directory...
Couldn't remove directory '/usr/share/mysql-test/var': Device or
resource busy at /usr/share/perl5/File/Find.pm line 511.
Creating var directory '/usr/share/mysql-test/var'...
Checking supported features...
MariaDB Version 10.4.14-MariaDB
 - SSL connections supported
Using suites:
main-,binlog-,csv-,funcs_1-,funcs_2-,handler-,heap-,maria-,optimizer_unfixed_bugs-,parts-,innodb-,roles-,rpl-,sys_vars-,unit-,vcol-
Collecting tests...
No option named 'plugin-dir' in group 'mysqld.1' at
lib/My/ConfigFactory.pm line 349

-

%build
export CFLAGS="%{optflags} %{O3_flags} -fPIC -fwrapv
-fno-stack-protector -fstack-protector --param=ssp-buffer-size=8
-fno-strict-aliasing -D_GNU_SOURCE -D_FILE_OFFSET_BITS=64
-D_LARGEFILE_SOURCE -Wno-stack-protector -Wa,--noexecstack"
export CXXFLAGS="$CFLAGS -fno-rtti"
export CPPFLAGS="$CFLAGS"
export SH_LDFLAGS="-Wl,--as-needed -Wl,-z,now -Wl,-z,relro
-Wl,-z,noexecstack -Wl,-z,nodump"
export LDFLAGS="$SH_LDFLAGS -pie -fPIE"
cmake . \
 -DFEATURE_SET="large" \
 -DCMAKE_INSTALL_PREFIX="%{_prefix}" \
 -DINSTALL_INCLUDEDIR=include/mysql \
 -DINSTALL_LAYOUT=RPM \
 -DDAEMON_NAME="mysqld" \
 -DDAEMON_NO_PREFIX="mysqld" \
 -DNICE_PROJECT_NAME="MariaDB" \
 -DINSTALL_LIBDIR="%{_lib}/mysql" \
 -DINSTALL_MANDIR=share/man \
 -DINSTALL_MYSQLSHAREDIR=share/mysql \
 -DINSTALL_MYSQLTESTDIR=share/mysql-test \
 -DINSTALL_PLUGINDIR="%{_lib}/mysql/plugin" \
 -DINSTALL_SBINDIR=libexec \
 -DINSTALL_SCRIPTDIR=bin \
 -DINSTALL_SQLBENCHDIR= \
 -DINSTALL_SUPPORTFILESDIR=share/mysql \
 -DMYSQL_DATADIR="%{_sharedstatedir}/mysql" \
 -DMYSQL_UNIX_ADDR="%{_sharedstatedir}/mysql/mysql.sock" \
 -DENABLED_PROFILING=OFF \
 -DENABLE_DEBUG_SYNC=OFF \
 -DENABLE_DTRACE=OFF \
 -DPLUGIN_ARIA=YES \
 -DPLUGIN_CSV=YES \
 -DPLUGIN_MYISAM=YES \
 -DPLUGIN_ARCHIVE=NO \
 -DPLUGIN_BLACKHOLE=NO \
 -DPLUGIN_CASSANDRA=NO \
 -DPLUGIN_CONNECT=NO \
 -DPLUGIN_EXAMPLE=NO \
 -DPLUGIN_FEDERATED=NO \
 -DPLUGIN_FEDERATEDX=NO \
 -DPLUGIN_FEEDBACK=NO \
 -DPLUGIN_GALERA=NO \
 -DPLUGIN_MROONGA=NO \
 -DPLUGIN_MYISAMMRG=NO \
 -DPLUGIN_OQGRAPH=NO \
 -DPLUGIN_PARTITION=NO \
 -DPLUGIN_PERFSCHEMA=NO \
 -DPLUGIN_ROCKSDB=NO \
 -DPLUGIN_SEMISYNC=NO \
 -DPLUGIN_SEQUENCE=NO \
 -DPLUGIN_SPHINX=NO \
 -DPLUGIN_SPIDER=NO \
 -DPLUGIN_TOKUDB=NO \
 -DPLUGIN_XTRADB=NO \
 -DPLUGIN_AUTH_SOCKET=NO \
 -DWITHOUT_DYNAMIC_PLUGINS=ON \
 -DWITH_ATOMIC_OPS=smp \
 -DWITH_EMBEDDED_SERVER=OFF \
 -DWITH_INNODB_DISALLOW_WRITES=OFF \
 -DWITH_INNODB_BZIP2=OFF \
 -DWITH_INNODB_LZ4=OFF \
 -DWITH_INNODB_LZMA=OFF \
 -DWITH_INNODB_LZO=OFF \
 -DWITH_INNODB_SNAPPY=OFF \
 -DWITH_MYSQLCOMPAT=ON \
 -DSECURITY_HARDENED=OFF \
 -DWITH_LIBARCHIVE=OFF \
 -DWITH_LIBWRAP=OFF \
 -DWITH_MARIABACKUP=OFF \
 -DWITH_PIC=NO \
 -DWITH_READLINE=OFF \
 -DWITH_SAFEMALLOC=OFF \
 -DWITH_VALGRIND=OFF \
 -DWITH_WSREP=OFF \
 -DWITH_JEMALLOC=OFF \
 -DWITH_SSL=system \
 -DWITH_ZLIB=system

___
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

[Maria-discuss] MariaDB 10.4: subtle change of result ordering

[Reindl Harald]

MyISAM:

in all previous versions this test was stable, so as the timestamps are
identical and ordering is 'desc' the result was ordered by the creation
time of the the records

now it's reverse which can break all sort of expectations in subtle ways

while we could discuss what is the expected output when order by
'ktimestamp' and all are identical it still worries me that something
which didn't change over years and major versions now comes with the
reverse ordering

unless someone tells me that's the result of some real peformance
optimization i would perfer the known result given that it's hard to
know how much other code depends implicit on the previous behavior

-

select SQL_NO_CACHE SQL_CALC_FOUND_ROWS * from `cl_autotest_comments`
where ksid=1 and kaktiv=1  order by ktimestamp desc limit 0,10

-

Array
(
[0] => Array
(
[kid] => 1
[kaktiv] => 1
[ksid] => 1
[ks2id] => 0
[ktimestamp] => 1598022502
[kip] => 127.0.0.1
[kname] => CMS-Autotest 1
[kherkunft] => Wien
[kkommentar] => Test Test Test Test Test Test Test Test Test
Test
)

[1] => Array
(
[kid] => 2
[kaktiv] => 1
[ksid] => 1
[ks2id] => 0
[ktimestamp] => 1598022502
[kip] => 127.0.0.1
[kname] => CMS-Autotest 2
[kherkunft] => Wien
[kkommentar] => Test Test Test Test Test Test Test Test Test
Test
)

[2] => Array
(
[kid] => 3
[kaktiv] => 1
[ksid] => 1
[ks2id] => 0
[ktimestamp] => 1598022502
[kip] => 127.0.0.1
[kname] => CMS-Autotest 3
[kherkunft] => Wien
[kkommentar] => Test Test Test Test Test Test Test Test Test
Test
)

)

-

diff of the expected application output:

-AutotestVerfassenCMS-Autotest
1Test Test Test Test Test Test
Test Test Test TestCMS-Autotest
2Test Test Test Test Test Test
Test Test Test TestCMS-Autotest
3Test Test Test Test Test Test
Test Test Test
Test

+AutotestVerfassenCMS-Autotest
3Test Test Test Test Test Test
Test Test Test TestCMS-Autotest
2Test Test Test Test Test Test
Test Test Test TestCMS-Autotest
1Test Test Test Test Test Test
Test Test Test
Test

___
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

[Maria-discuss] logging options of mariadb are a joke

[Reindl Harald]

it's a shame that even MySQl 5.7 options are unknown in MariaDB 10.3
which was *long* after

--

https://dev.mysql.com/doc/refman/5.7/en/server-system-variables.html#sysvar_log_syslog

[ERROR] /usr/libexec/mysqld: unknown variable 'log-syslog=1'

don't set "log-error" is sloppy crap and results in way to much long
lines with repeated stuff - hell either support proper config or just
don't spit date/time to stdout/stderr, journald knows it anyways

Aug 16 20:23:09 backupserver mysqld[315856]: 2020-08-16 20:23:09 6
[Note] Slave I/O thread exiting, read up to log 'bin.12', position
15906130

--

https://dev.mysql.com/doc/refman/5.7/en/server-system-variables.html#sysvar_log_error_verbosity

log_error_verbosity = 2

2020-08-16 22:17:46 0 [ERROR] /usr/libexec/mysqld: unknown variable
'log_error_verbosity=2'

--


___
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] why stdout? -> [Note] /usr/libexec/mysqld (mysqld 10.0.20-MariaDB) starting as process 115096

[Reindl Harald]

Am 06.08.15 um 17:26 schrieb Reindl Harald:
> Am 06.08.2015 um 17:23 schrieb Sergei Golubchik:
>> Hi, Reindl!
>>
>> On Aug 06, Reindl Harald wrote:
>>> Am 06.08.2015 um 14:25 schrieb Sergei Golubchik:
>>>> On Aug 06, Reindl Harald wrote:
>>>>> Am 06.08.2015 um 13:56 schrieb Sergei Golubchik:
>>>>>> On Aug 06, Reindl Harald wrote:
>>>>>>> Aug  6 12:24:24 testserver mysqld: 150806 12:24:24 [Note]
>>>>>>> /usr/libexec/mysqld (mysqld 10.0.20-MariaDB) starting as process
>>>>>>> 115096 ...
>>>>>>>
>>> the point is that echo something to stdout/stderr in case of a
>>> background service burries the lines and the only reason they appear
>>> at all is journald collecting that stuff and forwards it to syslog
>>>
>>> they should go to "log-error" as all other messages
>>
>> Ah, okay. You're right, this line is sent to stderr before stderr is
>> redirected to log-error. I suppose it's a bug
> 
> thanks for confirmation


that was introduced with 10.0.19 or 10.0.20 five years ago and is still
unchanged - are you kidding me?

Jul  4 22:31:06 backup-prometheus systemd[1]: Starting MariaDB
Replication...
Jul  4 22:31:06 backup-prometheus mysqld[4107]: 2020-07-04 22:31:06 0
[Note] /usr/libexec/mysqld (mysqld 10.3.23-MariaDB) starting as process
4107 ...
Jul  4 22:31:06 backup-prometheus systemd[1]: Started MariaDB Replication.

___
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] Poor performance compared to MySQL

[Reindl Harald]

Am 02.06.20 um 17:13 schrieb Roberto Spadim:
> yeap, i'm just trying to help to reproduce the problem 
> 
> i'm talking about the regression problem of speed between the same
> engine but different versions

tha focus on that when one comes up with numbers comparing exactly that
and *additionally* provides numbers with Aria

BTW: that below looks like after shot in the head because of using HTML
mails previosuly


> Em ter., 2 de jun. de 2020 às 12:07, Reindl Harald
> mailto:h.rei...@thelounge.net>> escreveu:
> 
> 
> 
> Am 02.06.20 um 17:03 schrieb Roberto Spadim:
> > Try to avoid compare aria/myisam cause it have a journal
> 
> how does that matter for selects and the point is "but MariaDB 10 MyISAM
> is still a long way behind 5.5"
> 
> it's complety normal to also compare the same operations with different
> engines and the point is still MyISAM without anything else touched got
> way slower
> 
> 
> > Em ter., 2 de jun. de 2020 às 11:48, Ling, Andy
> > mailto:andy.l...@grassvalley.com>
> <mailto:andy.l...@grassvalley.com
> <mailto:andy.l...@grassvalley.com>>> escreveu:
> >
> >     Well I’ve had a go. Using MariaDB 5.5.68 and MyISAM tables I get
> >     times very similar to MySQL
> >
> >     __ __
> >
> >     Some more definitive timings all on the same hardware…
> >
> >     __ __
> >
> >     MySQL 5.5 MyISAM
> >
> >     __ __
> >
> >     mysql> SELECT r.rushid FROM rushes r LEFT JOIN browse b ON
> r.rushID
> >     = b.rushID WHERE b.rushID IS NULL AND r.updated < NOW() -
> INTERVAL 1
> >     DAY;
> >
> >     +--+
> >
> >     | rushid   |
> >
> >     +--+
> >
> >     | 4de1e340d664dd87c4afda2c27f700a8 |
> >
> >     | 455166dd2cefff65f578aa333f7a5581 |
> >
> >     | 44f02723e901d2e958c58b9813ebaeae |
> >
> >     +--+
> >
> >     3 rows in set (3.63 sec)
> >
> >     __ __
> >
> >     __ __
> >
> >     MariaDB 5.5.68 MyISAM
> >
> >     __ __
> >
> >     MariaDB [quentin_v3]> SELECT r.rushid FROM rushes r LEFT JOIN
> browse
> >     b ON r.rushID = b.rushID WHERE b.rushID IS NULL AND r.updated <
> >     NOW() - INTERVAL 1 DAY;
> >
> >     +--+
> >
> >     | rushid   |
> >
> >     +--+
> >
> >     | 4de1e340d664dd87c4afda2c27f700a8 |
> >
> >     | 455166dd2cefff65f578aa333f7a5581 |
> >
> >     | 44f02723e901d2e958c58b9813ebaeae |
> >
> >     +--+
> >
> >     3 rows in set (3.01 sec)
> >
> >     __ __
> >
> >     MariaDB 10.4.2 MyISAM
> >
> >     __ __
> >
> >     MariaDB [quentin_v3]> SELECT r.rushid FROM rushes r LEFT JOIN
> browse
> >     b ON r.rushID = b.rushID WHERE b.rushID IS NULL AND r.updated <
> >     NOW() - INTERVAL 1 DAY;
> >
> >     +--+
> >
> >     | rushid   |
> >
> >     +--+
> >
> >     | 4de1e340d664dd87c4afda2c27f700a8 |
> >
> >     | 455166dd2cefff65f578aa333f7a5581 |
> >
> >     | 44f02723e901d2e958c58b9813ebaeae |
> >
> >     +--+
> >
> >     3 rows in set (12.890 sec)
> >
> >     __ __
> >
> >     MariaDB 10.4.2 Aria
> >
> >     __ __
> >
> >     MariaDB [quentin_v3]> SELECT r.rushid FROM rushes r LEFT JOIN
> browse
> >     b ON r.rushID = b.rushID WHERE b.rushID IS NULL AND r.updated <
> >     NOW() - INTERVAL 1 DAY;
> >
> >     +--+
> >
> >     | rushid   |
> >
> >     +--+
> >
> >     | 4de1e340d664dd87c4afda2c27f700a8 |
> >
> >     | 455166dd2cefff65f578aa333f7a5581 |
> >
> >     | 44f02723e901d2e958c58b9813ebaeae |
> >
> >     +--+
> >
> >     3 rows in set (16.268 sec)
> >
> >     __ __
> >
> >     So Aria is the slowest, but MariaDB 10 MyISAM is still a long way
> >     behind 5.5_


___
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] Poor performance compared to MySQL

[Reindl Harald]

Am 02.06.20 um 17:03 schrieb Roberto Spadim:
> Try to avoid compare aria/myisam cause it have a journal

how does that matter for selects and the point is "but MariaDB 10 MyISAM
is still a long way behind 5.5"

it's complety normal to also compare the same operations with different
engines and the point is still MyISAM without anything else touched got
way slower


> Em ter., 2 de jun. de 2020 às 11:48, Ling, Andy
> mailto:andy.l...@grassvalley.com>> escreveu:
> 
> Well I’ve had a go. Using MariaDB 5.5.68 and MyISAM tables I get
> times very similar to MySQL
> 
> __ __
> 
> Some more definitive timings all on the same hardware…
> 
> __ __
> 
> MySQL 5.5 MyISAM
> 
> __ __
> 
> mysql> SELECT r.rushid FROM rushes r LEFT JOIN browse b ON r.rushID
> = b.rushID WHERE b.rushID IS NULL AND r.updated < NOW() - INTERVAL 1
> DAY;
> 
> +--+
> 
> | rushid   |
> 
> +--+
> 
> | 4de1e340d664dd87c4afda2c27f700a8 |
> 
> | 455166dd2cefff65f578aa333f7a5581 |
> 
> | 44f02723e901d2e958c58b9813ebaeae |
> 
> +--+
> 
> 3 rows in set (3.63 sec)
> 
> __ __
> 
> __ __
> 
> MariaDB 5.5.68 MyISAM
> 
> __ __
> 
> MariaDB [quentin_v3]> SELECT r.rushid FROM rushes r LEFT JOIN browse
> b ON r.rushID = b.rushID WHERE b.rushID IS NULL AND r.updated <
> NOW() - INTERVAL 1 DAY;
> 
> +--+
> 
> | rushid   |
> 
> +--+
> 
> | 4de1e340d664dd87c4afda2c27f700a8 |
> 
> | 455166dd2cefff65f578aa333f7a5581 |
> 
> | 44f02723e901d2e958c58b9813ebaeae |
> 
> +--+
> 
> 3 rows in set (3.01 sec)
> 
> __ __
> 
> MariaDB 10.4.2 MyISAM
> 
> __ __
> 
> MariaDB [quentin_v3]> SELECT r.rushid FROM rushes r LEFT JOIN browse
> b ON r.rushID = b.rushID WHERE b.rushID IS NULL AND r.updated <
> NOW() - INTERVAL 1 DAY;
> 
> +--+
> 
> | rushid   |
> 
> +--+
> 
> | 4de1e340d664dd87c4afda2c27f700a8 |
> 
> | 455166dd2cefff65f578aa333f7a5581 |
> 
> | 44f02723e901d2e958c58b9813ebaeae |
> 
> +--+
> 
> 3 rows in set (12.890 sec)
> 
> __ __
> 
> MariaDB 10.4.2 Aria
> 
> __ __
> 
> MariaDB [quentin_v3]> SELECT r.rushid FROM rushes r LEFT JOIN browse
> b ON r.rushID = b.rushID WHERE b.rushID IS NULL AND r.updated <
> NOW() - INTERVAL 1 DAY;
> 
> +--+
> 
> | rushid   |
> 
> +--+
> 
> | 4de1e340d664dd87c4afda2c27f700a8 |
> 
> | 455166dd2cefff65f578aa333f7a5581 |
> 
> | 44f02723e901d2e958c58b9813ebaeae |
> 
> +--+
> 
> 3 rows in set (16.268 sec)
> 
> __ __
> 
> So Aria is the slowest, but MariaDB 10 MyISAM is still a long way
> behind 5.5_

___
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] Nosql language with plugins

[Reindl Harald]

what exactly did you not understand in the context "if you once again
are responding to a private mail on a public list" given *that this* is
unacceptable

what is the point warming up a dead thread after TWO days?

did you even bother read the rest of the thread?
did you get any context at all, i mean you had two days time

Am 16.05.20 um 14:26 schrieb Erik Cederstrand:
> Hi mailing list moderators,
> 
> Should I unsubscribe from MariaDB mailing lists now, or will you unsubscribe 
> this person?
> 
> This language is totally unacceptable and in violation the MariaDB CoC.
> 
> Kind regards,
> Erik
> 
>> Den 14. maj 2020 kl. 19.49 skrev Reindl Harald :
>>
>> if you once again are responding to a private mail on a public list i will 
>> care of that you wish you woldn't been born at all - and now for tahe sake 
>> of god just shut up

___
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] Nosql language with plugins

[Reindl Harald]

if you once again are responding to a private mail on a public list i
will care of that you wish you woldn't been born at all - and now for
tahe sake of god just shut up

Am 14.05.20 um 19:45 schrieb Justin Swanhart:
> I am not going to engage with you on this mailing list.
>
> On Thu, May 14, 2020, 1:44 PM Reindl Harald  <mailto:h.rei...@thelounge.net>> wrote:
>
> just a dumb fucker which don't realize that his idiot posts
> talking to himslef are annoying and if he once again comes with
> "You want a flame war? I was a Usenet admin. I know the game. I
> will burn you to the ground and piss on your ashes" and take the
> challenge and make this idot my new hobby
>
> Am 14.05.20 um 19:38 schrieb Jan Steinman:
>> "Closed: Fixed None Opened 5 years ago by rhughes.”
>>
>> FIVE YEARS AGO!
>>
>> Grudge much?
>>
>>> On May 14, 2020, at 10:30, Justin Swanhart >> <mailto:greenl...@gmail.com>> wrote:
>>>
>>> https://pagure.io/CoC/issue/6
>>>
>>> On Thu, May 14, 2020, 1:28 PM Reindl Harald
>>> mailto:h.rei...@thelounge.net>> wrote:
>>>
>>> > I had to go on disability for mental health reasons
>>>
>>> didn't work well - shut the fuck up!
>>>
>>> Am 14.05.20 um 19:20 schrieb Justin Swanhart:
>>> > I propose we just let it go.
>>> >
>>> > I will never speak of MariaDB again and you stop fucking
>>> me over.  We
>>> > both win.
>>> >
>>> > Can we please just stop this stupid fight.  I have nothing
>>> to gain by
>>> > tilting and windmills and you have nothing to gain by
>>> doing demonstrably
>>> > shitty things to me.
>>> >
>>> > On Mon, May 11, 2020, 5:57 PM Justin Swanhart
>>> mailto:greenl...@gmail.com>
>>> > <mailto:greenl...@gmail.com <mailto:greenl...@gmail.com>>>
>>> wrote:
>>> >
>>> >     MariaDB isn't an honest actor.  They repeatedly
>>> utilize FUD to push
>>> >     their agenda.
>>> >
>>> >     I was so frustrated by the columnstore experience that
>>> I had to go
>>> >     on disability for mental health reasons, and I was
>>> fired while on
>>> >     disability for blogging about BSL.
>>> >
>>> >     To attack me for my religious views after criticizing
>>> their
>>> >     characterization of RedShift on LinkedIn was
>>> unconscionable. The
>>> >     account had zero connections, no activity except
>>> commenting on my
>>> >     post, had only one job listed (33 years it said) and
>>> the university
>>> >     the person claimed to be from did not have the person
>>> in the alumni
>>> >     directory.
>>> >
>>> >     MariaDB won't respond to this, but you know it is true
>>> because there
>>> >     was no reason other than spite to remove articles
>>> about my tools
>>> >     that I did not even contribute and which are now dead
>>> links from
>>> >     other community webpages and blogs.
>>> >
>>> >     On Mon, May 11, 2020, 5:41 PM Justin Swanhart
>>> mailto:greenl...@gmail.com>
>>> >     <mailto:greenl...@gmail.com
>>> <mailto:greenl...@gmail.com>>> wrote:
>>> >
>>> >
>>> >         -- Forwarded message -
>>> >         From: *Justin Swanhart* >> <mailto:greenl...@gmail.com>
>>> >         <mailto:greenl...@gmail.com
>>> <mailto:greenl...@gmail.com>>>
>>> >         Date: Mon, May 11, 2020, 5:38 PM
>>> >         Subject: Re: [Maria-discuss] Nosql language with
>>> plugins
>>> >         To: Roberto Spadim >> <mailto:robe...@spadim.com.br>
>>> >         <mailto:robe...@spadim.com.br
>>> <mailto:robe...@spadim.com.br>

Re: [Maria-discuss] Nosql language with plugins

[Reindl Harald]

> I had to go on disability for mental health reasons

didn't work well - shut the fuck up!

Am 14.05.20 um 19:20 schrieb Justin Swanhart:
> I propose we just let it go.
> 
> I will never speak of MariaDB again and you stop fucking me over.  We
> both win.
> 
> Can we please just stop this stupid fight.  I have nothing to gain by
> tilting and windmills and you have nothing to gain by doing demonstrably
> shitty things to me.
> 
> On Mon, May 11, 2020, 5:57 PM Justin Swanhart  > wrote:
> 
> MariaDB isn't an honest actor.  They repeatedly utilize FUD to push
> their agenda.
> 
> I was so frustrated by the columnstore experience that I had to go
> on disability for mental health reasons, and I was fired while on
> disability for blogging about BSL.
> 
> To attack me for my religious views after criticizing their
> characterization of RedShift on LinkedIn was unconscionable. The
> account had zero connections, no activity except commenting on my
> post, had only one job listed (33 years it said) and the university
> the person claimed to be from did not have the person in the alumni
> directory.
> 
> MariaDB won't respond to this, but you know it is true because there
> was no reason other than spite to remove articles about my tools
> that I did not even contribute and which are now dead links from
> other community webpages and blogs.
> 
> On Mon, May 11, 2020, 5:41 PM Justin Swanhart  > wrote:
> 
> 
> -- Forwarded message -
> From: *Justin Swanhart*  >
> Date: Mon, May 11, 2020, 5:38 PM
> Subject: Re: [Maria-discuss] Nosql language with plugins
> To: Roberto Spadim  >
> 
> 
> MariaDB relicensed MaxScale from GPL to Business Source
> License.  The license change effectively extorted customers
> requiring customers using it to pay for it.  While older
> versions of MaxScale become GPL, the license terms prohibit
> backporting any security fixes and MariaDB abandons each release
> and never backports any fixes so it is impossible to use old
> versions in production.
> 
> On Mon, May 11, 2020, 5:34 PM Roberto Spadim
> mailto:robe...@spadim.com.br>> wrote:
> 
> What’s BSL?
> 
> Em seg, 11 de mai de 2020 às 18:19, Justin Swanhart
> mailto:greenl...@gmail.com>> escreveu:
> 
> *crickets*
> 
> On Fri, May 8, 2020, 2:33 PM Justin Swanhart
> mailto:greenl...@gmail.com>> wrote:
> 
> Seems I didn't get Federico's reply.  The answer is
> because:
> War, war never changes...
> 
> I made a stink about BSL, and I have shamed Monty in
> public.
> 
> MariaDB recently created a sock puppet LinkedIn
> account to attack me for my religious views.
> 
> We are at war 
> 
> On Wed, Apr 29, 2020, 9:48 PM Justin Swanhart
> mailto:greenl...@gmail.com>>
> wrote:
> 
> MariaDB doesn't have rewrite plugins.  
> 
> What you want could still not be done with a
> preparse plugin in MySQL because there is no way
> to speak an arbitrary protocol.  You could have
> a client that speaks the MySQL protocol but
> sends non-sql text commands that have some 1:1
> match with SQL, for example MDX.
> 
> For MySQL 8 I have developed an alternative
> rewrite plugin interface that can execute any
> number of SQL statements serially on the THD of
> the client connection, or an arbitrary THD.  It
> would be possible to port to MariaDB but as
> MariaDB has deleted the KB entries related to my
> tools, I highly doubt they would upstream it,
> and I would expect some form of
> compensation/sponsorship from you if you wanted
> me to do it.  In any case the plugin would still
> not speak arbitrary binary protocols.
> 
> MySQL 8 supports the X protocol for document
> access.  It would probably be possible to create
> an X protocol proxy that speaks arbitrary
> protocols but that would be a big project that
> probably not many people would be interested in. 
> 
> On Wed, Apr 29, 

Re: [Maria-discuss] database corrupted when switching from MySQL to MariaDB on Ubuntu 19.04

[Reindl Harald]

Am 16.10.19 um 11:59 schrieb Gordan Bobic:
> I have seen failures when upgrading from 10.0, with the latest 10.1 ->
> 10.2 -> 10.3 -> 10.4 unless I issued a clean shutdown between the latest
> 10.1 and 10.2 as recently as last week, with the latest RPMs for each
> version.
> 
> You are trying to make an argument analogous to "smoking can't be
> harmful because I've been smoking for 50 years and I'm not dead yet".
> 
> What is your sample size?

* 10 years
* 12 setups with innodb
* MySQL 5.0 -> 5.1 -> 5.5
* MariaDB 5.5 -> 10.0 -> 10.1 -> 10.2 -> 10.3

Mo Sep 02 2019: 10.2.26 -> 10.3.17

and frankly i expect whatever software to be able to read it's old data

> On Wed, 16 Oct 2019, 10:51 Reindl Harald,  <mailto:h.rei...@thelounge.net>> wrote:
> 
> 
> Am 16.10.19 um 11:29 schrieb Gordan Bobic:
> > On Wed, Oct 16, 2019 at 10:17 AM Reindl Harald
> mailto:h.rei...@thelounge.net>
> > <mailto:h.rei...@thelounge.net <mailto:h.rei...@thelounge.net>>>
> wrote:
> >
> >
> >     Am 16.10.19 um 10:23 schrieb Gordan Bobic:
> >     > I don't know if it is recoverable but it sounds like you missed
> >     the step
> >     > of always needing a full, clean shutdown between upgrades with
> >     > innodb_fast_shutdown=0. Then you can delete ib_logfile*, and
> upgrade.
> >
> >     always?
> >
> >
> > Yes.
> 
> nonsense
> 
> >     how comes that i didn't need that for the whole past decade
> which means
> >     MySQl 5.0 to MariaDB 10.3 and frankly i wouldn't expect it at
> all, this
> >     is not PostgreSQL
> >
> > Short of an incredible amount of luck, resulting in the ib_logfiles
> > being completely flushed at the point of shutdown (or you having
> > innodb_fast_shutdown=0 set in your configs),
> 
> no, i don't
> 
> > I don't have an explanation
> > for why for you. I have never seen an upgrade from MariaDB 10.1 and
> > earlier to MariaDB 10.2 and later work without following the described
> > process, and I have carried out dozens of such upgrades over the last
> > few years.
> 
> maybe just don't jump on early releases as fast as you can helps a lot,
> see below
> 
> > It is documented, and a simple yum update specifically refuses to
> > upgrade the MariaDB-server package for this exact reason. You have
> to do
> > a clean shutdown, manually remove the old MariaDB-server package and
> > then install the new MariaDB-server package.
> 
> 
> 
> https://mariadb.com/kb/en/library/upgrading-from-mariadb-101-to-mariadb-102/
> 
> Set innodb_fast_shutdown to 0. It can be changed dynamically with SET
> GLOBAL. For example:
> SET GLOBAL innodb_fast_shutdown=0;
> 
> This step is not necessary when upgrading to MariaDB 10.2.5 or later.
> Omitting it can make the upgrade process far faster. See MDEV-12289 for
> more information.

___
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] database corrupted when switching from MySQL to MariaDB on Ubuntu 19.04

[Reindl Harald]

Am 16.10.19 um 11:29 schrieb Gordan Bobic:
> On Wed, Oct 16, 2019 at 10:17 AM Reindl Harald  <mailto:h.rei...@thelounge.net>> wrote:
> 
> 
> Am 16.10.19 um 10:23 schrieb Gordan Bobic:
> > I don't know if it is recoverable but it sounds like you missed
> the step
> > of always needing a full, clean shutdown between upgrades with
> > innodb_fast_shutdown=0. Then you can delete ib_logfile*, and upgrade.
> 
> always?
> 
> 
> Yes.

nonsense

> how comes that i didn't need that for the whole past decade which means
> MySQl 5.0 to MariaDB 10.3 and frankly i wouldn't expect it at all, this
> is not PostgreSQL
> 
> Short of an incredible amount of luck, resulting in the ib_logfiles
> being completely flushed at the point of shutdown (or you having
> innodb_fast_shutdown=0 set in your configs), 

no, i don't

> I don't have an explanation
> for why for you. I have never seen an upgrade from MariaDB 10.1 and
> earlier to MariaDB 10.2 and later work without following the described
> process, and I have carried out dozens of such upgrades over the last
> few years.

maybe just don't jump on early releases as fast as you can helps a lot,
see below

> It is documented, and a simple yum update specifically refuses to
> upgrade the MariaDB-server package for this exact reason. You have to do
> a clean shutdown, manually remove the old MariaDB-server package and
> then install the new MariaDB-server package.


https://mariadb.com/kb/en/library/upgrading-from-mariadb-101-to-mariadb-102/

Set innodb_fast_shutdown to 0. It can be changed dynamically with SET
GLOBAL. For example:
SET GLOBAL innodb_fast_shutdown=0;

This step is not necessary when upgrading to MariaDB 10.2.5 or later.
Omitting it can make the upgrade process far faster. See MDEV-12289 for
more information.

___
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] database corrupted when switching from MySQL to MariaDB on Ubuntu 19.04

[Reindl Harald]

Am 16.10.19 um 10:23 schrieb Gordan Bobic:
> I don't know if it is recoverable but it sounds like you missed the step
> of always needing a full, clean shutdown between upgrades with
> innodb_fast_shutdown=0. Then you can delete ib_logfile*, and upgrade.

always?

how comes that i didn't need that for the whole past decade which means
MySQl 5.0 to MariaDB 10.3 and frankly i wouldn't expect it at all, this
is not PostgreSQL

___
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] MariaDB 10.4.8 crash

[Reindl Harald]

Am 03.10.19 um 13:23 schrieb Thomas Plant:
> Am 03.10.2019 um 11:53 schrieb Reindl Harald:
>> "10.4.6 Stable 2019-06-18"
> 
> Well, its marked 'stable' two releases ago, how long should one wait
> until he uses it? If it crashes on a simple query it should not be
> marked 'stable' IMHO. And if nobody uses it, bugs wont be discovered ;-)
> 
> We reverted to 10.3 and it's alright

honestly a year or so if you don't want to discover all bugs at your
own, given that 10.2 is still supported there is not point jump to 10.4
unless you want/need a specific new feature

___
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] MariaDB 10.4.8 crash

[Reindl Harald]

Am 03.10.19 um 11:41 schrieb Thomas Plant:
>> Client did some tests and he discovered that the following query will
>> crash reliably:
>>
>> SELECT
>> *
>> FROM
>> `users`
>> WHERE
>> ( `role` = 1 OR `role` = 10 )
>> AND EXISTS ( SELECT * FROM `email_templates` INNER JOIN `users_email` ON
>> `email_templates`.`id` = `users_email`.`email_template_id` WHERE
>> `users`.`id` = `users_email`.`user_id` AND `email_template_id` = 12 )
>> AND `users`.`deleted_at` IS NULL;
>>
>> Strange thing is when he changes the `email_template_id` = 12 to
>> `email_template_id` = 11 (or any other value) the query works.
>>
>> I checked with "mysqlcheck -ce dbname" and no error resulted
>>
> Installed MariaDB 10.3 and the query gives no problems. So is this a
> 10.4 bug?

obviously and given that "10.4.6 Stable 2019-06-18" was the first GA
release nobody right in his mind is using 10.4 that early in production,
even Fedora 32 (Rawhide) is still on 10.3.x

we upgraded recently to 10.3 and not earlier for good reasons


P.S.: there is no need for a full quote and include dozens of list
footers for a single line reply

___
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] Rocks, toku and some performance considerations.

[Reindl Harald]

Am 17.09.19 um 16:16 schrieb jocelyn fournier:
>> Le 17 sept. 2019 à 16:07, pslawek83  a écrit :
>>
>> Hi Everyone, just some quick follow up on this topic about MyRocks i 
>> started. It seems that there are some issues with debian9 and cfq scheduler 
>> when using rocks. Tested this on VM, not sure how virtualization is 
>> affecting this. Rocks is easily able to saturate 3 cpu cores with I/O wait 
>> and I/O throughput is very low in this config, even on fast SSD.
>>
>> This gets much better after switching to noop/deadline and best is to switch 
>> to Debian10 with mq-deadline. Then I/O wait drops to 0% and performance 
>> improves a lot.
> 
> Just curious, is mq-deadline faster than none, even on fast SSD / NVME?

given that "none" is nowhere used and poorly testet proven by the data
corruption issues as "mq" was introduced i wouldn't use it no matte rhow
fast it is

https://www.phoronix.com/scan.php?page=news_item=Linux-4.19.8-Released

___
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] Cannot open datafile for read-only: './dbmail/#sql2-704-271.ibd' OS error: 71

[Reindl Harald]

Am 16.09.19 um 16:43 schrieb Marko Mäkelä:
>> it's a shame that you simply can't get rid of garbage from the global
>> tablespace
> 
> Starting with MDEV-14585 InnoDB actually does drop #sql- tables during
> startup. The #sql2 tables are intentionally preserved, because during
> ALTER TABLE…ALGORIHTM=COPY there are multiple internal commits, and if
> the server is killed at the right moment, then the user table will be
> known only by #sql- and #sql2 names. We do not want to remove the only
> copy of the table.
> 
> Ultimately, for new DDL statements, this should be fixed when
> MDEV-17567 implements Atomic DDL. I do not think that we can even then
> safely remove #sql2 tables from old installations, because we must
> think of upgrade scenarios.

that all don't justify why the drop table simply can't remove the
reference to something that literally don#t exist for a whole decade

either that idiotic table is known or it's unknown

if it's unknow get rid of it or at least allow the admin to do so with
doing some crazy dance introducing way more room for troubles than just
forget about something which isn't there anyways

MariaDB [(none)]> SELECT * FROM INFORMATION_SCHEMA.INNODB_SYS_TABLES
WHERE NAME LIKE '%#sql%';
+--+--+--++---++---++
| TABLE_ID | NAME | FLAG | N_COLS | SPACE | ROW_FORMAT |
ZIP_PAGE_SIZE | SPACE_TYPE |
+--+--+--++---++---++
|  672 | dbmail/#sql2-704-271 |   41 |  5 |   545 | Compressed |
 8192 | Single |
+--+--+--++---++---++
1 row in set (0.002 sec)

MariaDB [(none)]> use dbmail
ERROR 1051 (42S02): Unknown table 'dbmail.dbmail/#sql2-704-271'
MariaDB [dbmail]> DROP TABLE `dbmail#sql2-704-271`;
ERROR 1051 (42S02): Unknown table 'dbmail.dbmail#sql2-704-271'
MariaDB [dbmail]>

___
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] Cannot open datafile for read-only: './dbmail/#sql2-704-271.ibd' OS error: 71

[Reindl Harald]

Am 16.09.19 um 15:58 schrieb Sergei Golubchik:
> Hi, Reindl!
> 
> On Sep 14, Reindl Harald wrote:
>> Am 14.09.19 um 14:05 schrieb Sergei Golubchik:
>>> Hi, Reindl!
>>>
>>> 1. Do you actually have /dbmail/*271* files ?
>>
>> no as you can see "Cannot open datafile for read-only:
>> './dbmail/#sql2-704-271.ibd'", i deleted the temp files 10 years ago
>> after one week of not used obviously from anything and didn't imagine
>> the weird behavior of innodb
> 
> Okay.
> 
> It looks like the only way to get rid of this warning would be to drop
> this table manually. Like, `create table t1 ... engine=innodb`
> then copy t1.idb and t1.frm to #sql2-704-271.* and then drop t1 and
> `#mysql50#sql2-704-271` tables.

tried that years ago

i even gone that far to find out which tables that originally was and
copied the real ones to the expected temp-table filenames to silence
that startup errors for some years

with 10.1 or 10.2 i had to delete both files because MariaDB crashed at
startup because they don't really matched what the global tablespace
expected

it's a shame that you simply can't get rid of garbage from the global
tablespace


___
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] Cannot open datafile for read-only: './dbmail/#sql2-704-271.ibd' OS error: 71

[Reindl Harald]

Am 14.09.19 um 14:05 schrieb Sergei Golubchik:
> Hi, Reindl!
> 
> 1. Do you actually have /dbmail/*271* files ?

no as you can see "Cannot open datafile for read-only:
'./dbmail/#sql2-704-271.ibd'", i deleted the temp files 10 years ago
after one week of not used obviously from anything and didn't imagine
the weird behavior of innodb

> 2. What did you do to end up in this situation?
> May be an interrupted ALTER TABLE? A crash or kill -9, perhaps?

yes, 10 yeas ago before systemd came out a f**ing homegrown monitoring
solution before systemed came in my way shortly after apply the inndob
compression patch and cmpresison was done and frankly after excatly a
full deacde i am tired of that dumb startup errors and it's time that
innodb forgets about the /dbmail/*271* files

___
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

[Maria-discuss] Cannot open datafile for read-only: './dbmail/#sql2-704-271.ibd' OS error: 71

[Reindl Harald]

as far as i remember i was told 10.3 is able to fix that after a full
dcade now but it don't

2019-09-11 18:18:12 0 [ERROR] InnoDB: Operating system error number 2 in
a file operation.
2019-09-11 18:18:12 0 [ERROR] InnoDB: The error means the system cannot
find the path specified.
2019-09-11 18:18:12 0 [ERROR] InnoDB: If you are installing InnoDB,
remember that you must create directories yourself, InnoDB does not
create them.
2019-09-11 18:18:12 0 [ERROR] InnoDB: Cannot open datafile for
read-only: './dbmail/#sql2-704-271.ibd' OS error: 71
2019-09-11 18:18:12 0 [ERROR] InnoDB: Operating system error number 2 in
a file operation.
2019-09-11 18:18:12 0 [ERROR] InnoDB: The error means the system cannot
find the path specified.
2019-09-11 18:18:12 0 [ERROR] InnoDB: If you are installing InnoDB,
remember that you must create directories yourself, InnoDB does not
create them.
2019-09-11 18:18:12 0 [ERROR] InnoDB: Could not find a valid tablespace
file for ``dbmail`.`#sql2-704-271``. Please refer to
https://mariadb.com/kb/en/innodb-data-dictionary-troubleshooting/ for
how to resolve the issue.
2019-09-11 18:18:12 0 [Warning] InnoDB: Ignoring tablespace for
`dbmail`.`#sql2-704-271` because it could not be opened.


MariaDB [(none)]> SELECT * FROM INFORMATION_SCHEMA.INNODB_SYS_TABLES
WHERE NAME LIKE '%#sql%';
+--+--+--++---++---++
| TABLE_ID | NAME | FLAG | N_COLS | SPACE | ROW_FORMAT |
ZIP_PAGE_SIZE | SPACE_TYPE |
+--+--+--++---++---++
|  672 | dbmail/#sql2-704-271 |   41 |  5 |   545 | Compressed |
 8192 | Single |
+--+--+--++---++---++
1 row in set (0.002 sec)

MariaDB [(none)]> use dbmail
ERROR 1051 (42S02): Unknown table 'dbmail.dbmail/#sql2-704-271'
MariaDB [dbmail]> DROP TABLE `dbmail#sql2-704-271`;
ERROR 1051 (42S02): Unknown table 'dbmail.dbmail#sql2-704-271'
MariaDB [dbmail]>

___
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] fsync alternative

[Reindl Harald]

Am 07.09.19 um 21:38 schrieb Jure Sah:
> On 7. 09. 19 21:03, Jan Steinman wrote:
>> I’m using an inexpensive Mac Mini, maxed out with RAM, and a 2GB SSD,
>> running NOTHING but MariaDB. I even run it headless, which means all
>> the UI processes stay in sleep(3). When I was having web server
>> performance issues, that was the one thing that improved things the
>> most. And that was after wasting a lot of time trying to tweak MariaDB
>> variables.
> 
> I work for an ISP. The system they use is connected to a dedicated SSD
> RAID array on SAN. On the particular virtual machine the MariaDB is on
> the same server as the Apache webserver.  The main issue is that the
> website gets a lot of traffic. It has some CMS-based website on it and
> the session table is grinding away constantly.
> 
> Normally it's not a problem, but once when a malfunction on the SAN
> network caused degraded performance (not downtime mind you!), with the
> usual traffic the website was simply down with Gateway timeout from
> memcached. The workaround was to temporarily move the database to a
> ramdisk (tmpfs).
> 
> My employer considers stepping outside the recommendations of the open
> source community to be not worth the risk, and the issue was resolved
> since.  However I know that I shouldn't have had to make the workaround
> with the ramdisk, because the kernel page cache was supposed to take
> care of that by itself. The reason this doesn't work is the fsyncs used
> by MariaDB, which effectively disables any advantage offered by the page
> cache. I think that is a great shame so I am trying to see if there is
> anything I can do about that.

that's how are databsed are supposed to work and a proper storage with
battery backed write cahce should have no issue

whatever you do or dirty< hacks you want, they belong to the storage,
there is even software outhere rendering fsync a NOOP


___
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] 10.3.x: unknown variable 'innodb_support_xa=1'

[Reindl Harald]

Am 03.09.19 um 11:53 schrieb Benoit Plessis:
>> [root@srv-rhsoft:~]$ apachectl -t
>> AH00526: Syntax error on line 14 of /etc/httpd/conf/httpd-prefork.conf:
>> Invalid command 'ddd=dfdfdf', perhaps misspelled or defined by a module
>> not included in the server configuration
>>
>> where is something similar for mariadb/mysqld *before* restart the service?
> 
> Yes, that could be nice, not sure if it's really top priority...

for a service which simply refuses to restart because of some unkown
option as result of a different build option it's *mandatory* not just
nice, especially when build-options are known to randomly break between
bugfix releases

___
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] 10.3.x: unknown variable 'innodb_support_xa=1'

[Reindl Harald]

Am 03.09.19 um 11:38 schrieb Benoit Plessis:
> On 03/09/2019 11:25, Reindl Harald wrote:
>> when i *explicit disable* some bloatware crap it's missing exitence is
>> not a hard error
> Well, so you want to add some "bloat" to a software to handle deprecated
> bloated "crap", are you sure to think it through?

a simple array with all known config options is bloat?
have you ever written software in any language?

-

and for the Apache and nginx:

[root@srv-rhsoft:~]$ apachectl -t
AH00526: Syntax error on line 14 of /etc/httpd/conf/httpd-prefork.conf:
Invalid command 'ddd=dfdfdf', perhaps misspelled or defined by a module
not included in the server configuration

where is something similar for mariadb/mysqld *before* restart the service?

___
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] mariadb + FIPS

[Reindl Harald]

Am 02.09.19 um 20:22 schrieb Captain Wiggum:
> Thanks Harald for your reply. I do not disagree with anything you said.
> Unfortunately we cannot tell the US Govt that their requirements are stupid.
> When openssl is in FIPS mode, md5 & sha1 are disabled for everyone.
> So any usage from mariadb (linked with openssl) will fail.

yeah, but not every usage of a hash function is related to openssl

> On Thu, Aug 29, 2019 at 4:33 PM Reindl Harald  <mailto:h.rei...@thelounge.net>> wrote:
> 
> 
> 
> Am 30.08.19 um 00:10 schrieb Captain Wiggum:
> > I have searched the archives and forums and cannot find an answer to
> > this question.
> > Does mariadb support FIPS, and if so, how or where is a document
> about this.
> > I use mariadb 10.3.17 with OpenSSL 1.0.2 with FIPS enabled, all built
> > from source.
> > In FIPS mode, SHA1 is disallowed by openssl, as required by FIPS.
> > However, when I search the mariadb code, SHA1 is used in many places.
> > How can I update mariadb to use sha256, without a ton of recoding?
> > Any tips appreciated.
> 
> outside of encryption code nothing is wrong with SHA1 depending on the
> usecase and without context "SHA1 is used in many place" is a useless
> statement
> 
> there are even usecases where MD4 is just fine
> 
> againb: not every usage of a hash function is security related or
> collisions prone and in that case it would be pretty dumb use a much
> slower sha256 hash

___
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] 10.3.x: unknown variable 'innodb_support_xa=1'

[Reindl Harald]

Am 02.09.19 um 20:20 schrieb Marko Mäkelä:
> On Mon, Sep 2, 2019 at 8:48 PM Reindl Harald  wrote:
>> and yes, i assumed that a core developer other than you would look at
>> that startup log, came to the conslusion "indeed, no warning there"
>> and while read the few lines "indeed, the latest 10.2 version"
> 
> You are right that a warning should be issued for deprecated variables
> if any value was specified in the configuration file or by a command
> line option.
> 
> Unfortunately, I am not aware how a storage engine could distinguish
> the compile-time default value from a user-specified identical value.
> That is why InnoDB did not issue the deprecation warning for you.
> Maybe you can submit a fix that would address this deficiency?

sadly i am not a C/C++ delevoper but i would expect it to be as simple
as two simple *global* lists

$known_options = ['innodb_support_xa', 'performance-schema=0', ...]
$deprecated_options ['innodb_support_xa', ]

-DPLUGIN_PARTITION=NO, -DPLUGIN_PERFSCHEMA=NO where broken in multiple
point releases the past years and everytime one decided "well, then
disable that build option and use the config option to disable it"
leaded later in "oh fuck, now the the build was fixed it no longer
starts because of the now unknown option"

a simple lookup in "known_options" and react with a generic warning that
this option is not supported in the current build instead refuse to
start and refuse only when a total unknownm option appears would have
safed a lot of headache

___
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] 10.3.x: unknown variable 'innodb_support_xa=1'

[Reindl Harald]

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA256



Am 02.09.19 um 19:38 schrieb Faustin Lammler:
> I am truly sorry by the issue you are facing, but giving us *in
> your first post* the version and the OS would have been more
> productive IMHO

don't get me wrong *but* i find it insulting when someone accueses me
that i jump from some random completly outdated version to 10.3.x and
then come up with "but why where the no warning in 10.0/10.1 that
something disappears in 10.3"

that's what i call common sense on both sides

anyways, the real problem i have with your response is that you jumped
into two posts between me and a core developer and stripped everything
relevant while  i showed a complete restart log without any mentioning
of "innodb_support_xa" at all and asked where the warning is the core
developer talked about

and yes, i assumed that a core developer other than you would look at
that startup log, came to the conslusion "indeed, no warning there"
and while read the few lines "indeed, the latest 10.2 version"
-BEGIN PGP SIGNATURE-

iQGzBAEBCAAdFiEEnStGzbwUCjZ1OuTXMxdNWliSt7gFAl1tVYEACgkQMxdNWliS
t7jqpgv+NcClSSpeisaLqPNv7uRm4OhbNYdteyUxXVDMP1DxBTH6i0D+D1/LRqcE
aYcl68l3Ttw34+uCM1oIgY2hutOWb7h4uzzrC7ZxFDsCKU+5b+ZzbSN9jcL5GPWt
z3ArTZS5jUzkPUGcQDqYrEoFqc8HOjYM6pOr0YeFZMFPmURM4LB0q+kumezn7E6i
K0A1GKYebJ0EHsiIQs8r+J3ZZLMPD6K+6Fkk0dB07NIArfDa6VPOXGL2r4/X5sP4
yodVgHWhXGW5dkpyjUuyBoB1IloqqxsutGGiwbLkMS6x9OuUsCq5HaDFau0WDQGH
Kt+CaeCBVwYpsozsgGgPoOnbmUgaoVxGG7pERnbSxrN2X2l5ACgGxpY8Q9nNOGsi
7DJFZm7vOf0M3sOR9XgZ4TWiPbtV2QSWuy9bNNXyiL7LZWAMjfmwsTQFLRGGMwkW
tQZPr/OWbN1xd15dxKu7NHwjCLqxdIwE0n2e8itlU6syzivquepinTGQg7a5D09r
L3dqqB5L
=SGe9
-END PGP SIGNATURE-

___
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] 10.3.x: unknown variable 'innodb_support_xa=1'

[Reindl Harald]

Am 02.09.19 um 18:05 schrieb Faustin Lammler:
> After reading the recent thread on systemd devel ML (/etc/fstab 
> obsolete?) I kind of find your tone a bit inappropriate. May I
> suggest you to try to start by applying your advice to yourself.

that stupid behavior of mariadb was pointed out often enough

> This is clearly not a
>> good start for a discussion
> 
> https://lists.freedesktop.org/archives/systemd-devel/2019-August/043349.html
>
>  Reindl Harald , 02/09/2019 – 17:20:36
> (+0200):
> 
>> bullshit
>> 
>> the part you skipped in your quote contains clearly "Version: 
>> '10.2.26-MariaDB'" and is a full mysqld log (cleaned before
>> restart) with 'innodb_support_xa=1' in the config
> Maybe giving us the version you are upgrading from would have been
> a better starting point.

maybe read what i wrote instead cut down my post by the first line
would be a god start too or simply shut up when you are too lazy read
a log starting with "Normal shutdown" and ending with "Version:
'10.2.26-MariaDB'" leaded by "come on and show me!" would be a good start!

* one pretends 10.2 has a deprecation warning
* i repsoned with "show me" and a full log of a recent 10.2 restart
* you come up with "since you skipped over directly to 10.3"

seriously?

---

Am 02.09.19 um 17:09 schrieb Marko Mäkelä:
> On Mon, Sep 2, 2019 at 5:43 PM Reindl Harald
 wrote:
>> unknown variable 'innodb_support_xa=1'
>> 
>> would you funny guys consider things like deperectaion warnings
>> in previous releases
> 
> A deprecation warning was added in the MariaDB Server 10.2.2, well 
> before it was Generally Available. That said, maybe there is a
> nontrivial amount of users who skipped the 10.2 release and
> upgraded straight from 10.1 to 10.3.

come on and show me!

[root@localhost:~]$ cat mysql_error.log
2019-09-02 17:11:43 139645497730816 [Note] /usr/libexec/mysqld
(initiated by: unknown): Normal shutdown
2019-09-02 17:11:43 139645073479424 [Note] InnoDB: FTS optimize thread
exiting.
2019-09-02 17:11:43 139645497730816 [Note] Event Scheduler: Purging the
queue. 0 events
2019-09-02 17:11:43 139645498156800 [Note] Error reading relay log
event: slave SQL thread was killed
2019-09-02 17:11:43 139645498156800 [Note] Slave SQL thread exiting,
replication stopped in log 'bin.002679' at position 49489
2019-09-02 17:11:43 139645498464000 [Note] Slave I/O thread exiting,
read up to log 'bin.002679', position 49489
2019-09-02 17:11:43 139645497730816 [Note] InnoDB: Starting shutdown...
2019-09-02 17:11:45 139645497730816 [Note] InnoDB: Shutdown completed;
log sequence number 201835120033
2019-09-02 17:11:45 139645497730816 [Note] InnoDB: Removed temporary
tablespace data file: "ibtmp1"
2019-09-02 17:11:45 139645497730816 [Note] /usr/libexec/mysqld: Shutdown
complete

2019-09-02 17:11:45 139893743717888 [Note] InnoDB: Mutexes and rw_locks
use GCC atomic builtins
2019-09-02 17:11:45 139893743717888 [Note] InnoDB: Uses event mutexes
2019-09-02 17:11:45 139893743717888 [Note] InnoDB: Compressed tables use
zlib 1.2.11
2019-09-02 17:11:45 139893743717888 [Note] InnoDB: Using Linux native AIO
2019-09-02 17:11:45 139893743717888 [Note] InnoDB: Number of pools: 1
2019-09-02 17:11:45 139893743717888 [Note] InnoDB: Using SSE2 crc32
instructions
2019-09-02 17:11:45 139893743717888 [Note] InnoDB: Initializing buffer
pool, total size = 64M, instances = 1, chunk size = 64M
2019-09-02 17:11:45 139893743717888 [Note] InnoDB: Completed
initialization of buffer pool
2019-09-02 17:11:45 139893416630016 [Note] InnoDB: page_cleaner
coordinator priority: -20
2019-09-02 17:11:45 139893743717888 [Note] InnoDB: Highest supported
file format is Barracuda.
2019-09-02 17:11:46 139893743717888 [Note] InnoDB: 128 out of 128
rollback segments are active.
2019-09-02 17:11:46 139893743717888 [Note] InnoDB: Creating shared
tablespace for temporary tables
2019-09-02 17:11:46 139893743717888 [Note] InnoDB: Setting file
'./ibtmp1' size to 12 MB. Physically writing the file full; Please
wait ...
2019-09-02 17:11:46 139893743717888 [Note] InnoDB: File './ibtmp1' size
is now 12 MB.
2019-09-02 17:11:46 139893743717888 [Note] InnoDB: Waiting for purge to
start
2019-09-02 17:11:46 139893743717888 [Note] InnoDB: 5.7.27 started; log
sequence number 201835120033
2019-09-02 17:11:46 139893275596544 [Note] InnoDB: Loading buffer
pool(s) from /Volumes/dune/mysql/mysql_dbmail/ib_buffer_pool
2019-09-02 17:11:46 139893275596544 [Note] InnoDB: Cannot open
'/Volumes/dune/mysql/mysql_dbmail/ib_buffer_pool' for reading: No such
file or directory
2019-09-02 17:11:46 139893743717888 [Note] Server socket created on IP:
'0.0.0.0'.
2019-09-02 17:11:46 139893743717888 [Note] /usr/libexec/mysqld: ready
for connections.
Version: '10.2.26-MariaDB'  socket: '/var/lib/mysql/mysqld_dbmail.sock'
 port: 3307  thelounge
2019

Re: [Maria-discuss] 10.3.x: unknown variable 'innodb_support_xa=1'

[Reindl Harald]

Am 02.09.19 um 17:18 schrieb Benoit Plessis:
> On 02/09/2019 17:13, Reindl Harald wrote:
>>> A deprecation warning was added in the MariaDB Server 10.2.2, well
>>> before it was Generally Available.
>>> That said, maybe there is a nontrivial amount of users who skipped the
>>> 10.2 release and upgraded straight from 10.1 to 10.3.
>> come on and show me!
> 
> The way i understand Marko's sentence the deprecation warning was in
> 10.2 and only 10.2, since you skipped over directly to 10.3 it's to late
> for the warning

bullshit

the part you skipped in your quote contains clearly "Version:
'10.2.26-MariaDB'" and is a full mysqld log (cleaned before restart)
with 'innodb_support_xa=1' in the config

___
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] 10.3.x: unknown variable 'innodb_support_xa=1'

[Reindl Harald]

Am 02.09.19 um 17:09 schrieb Marko Mäkelä:
> On Mon, Sep 2, 2019 at 5:43 PM Reindl Harald  wrote:
>> unknown variable 'innodb_support_xa=1'
>>
>> would you funny guys consider things like deperectaion warnings in
>> previous releases
> 
> A deprecation warning was added in the MariaDB Server 10.2.2, well
> before it was Generally Available.
> That said, maybe there is a nontrivial amount of users who skipped the
> 10.2 release and upgraded straight from 10.1 to 10.3.

come on and show me!

[root@localhost:~]$ cat mysql_error.log
2019-09-02 17:11:43 139645497730816 [Note] /usr/libexec/mysqld
(initiated by: unknown): Normal shutdown
2019-09-02 17:11:43 139645073479424 [Note] InnoDB: FTS optimize thread
exiting.
2019-09-02 17:11:43 139645497730816 [Note] Event Scheduler: Purging the
queue. 0 events
2019-09-02 17:11:43 139645498156800 [Note] Error reading relay log
event: slave SQL thread was killed
2019-09-02 17:11:43 139645498156800 [Note] Slave SQL thread exiting,
replication stopped in log 'bin.002679' at position 49489
2019-09-02 17:11:43 139645498464000 [Note] Slave I/O thread exiting,
read up to log 'bin.002679', position 49489
2019-09-02 17:11:43 139645497730816 [Note] InnoDB: Starting shutdown...
2019-09-02 17:11:45 139645497730816 [Note] InnoDB: Shutdown completed;
log sequence number 201835120033
2019-09-02 17:11:45 139645497730816 [Note] InnoDB: Removed temporary
tablespace data file: "ibtmp1"
2019-09-02 17:11:45 139645497730816 [Note] /usr/libexec/mysqld: Shutdown
complete

2019-09-02 17:11:45 139893743717888 [Note] InnoDB: Mutexes and rw_locks
use GCC atomic builtins
2019-09-02 17:11:45 139893743717888 [Note] InnoDB: Uses event mutexes
2019-09-02 17:11:45 139893743717888 [Note] InnoDB: Compressed tables use
zlib 1.2.11
2019-09-02 17:11:45 139893743717888 [Note] InnoDB: Using Linux native AIO
2019-09-02 17:11:45 139893743717888 [Note] InnoDB: Number of pools: 1
2019-09-02 17:11:45 139893743717888 [Note] InnoDB: Using SSE2 crc32
instructions
2019-09-02 17:11:45 139893743717888 [Note] InnoDB: Initializing buffer
pool, total size = 64M, instances = 1, chunk size = 64M
2019-09-02 17:11:45 139893743717888 [Note] InnoDB: Completed
initialization of buffer pool
2019-09-02 17:11:45 139893416630016 [Note] InnoDB: page_cleaner
coordinator priority: -20
2019-09-02 17:11:45 139893743717888 [Note] InnoDB: Highest supported
file format is Barracuda.
2019-09-02 17:11:46 139893743717888 [Note] InnoDB: 128 out of 128
rollback segments are active.
2019-09-02 17:11:46 139893743717888 [Note] InnoDB: Creating shared
tablespace for temporary tables
2019-09-02 17:11:46 139893743717888 [Note] InnoDB: Setting file
'./ibtmp1' size to 12 MB. Physically writing the file full; Please wait ...
2019-09-02 17:11:46 139893743717888 [Note] InnoDB: File './ibtmp1' size
is now 12 MB.
2019-09-02 17:11:46 139893743717888 [Note] InnoDB: Waiting for purge to
start
2019-09-02 17:11:46 139893743717888 [Note] InnoDB: 5.7.27 started; log
sequence number 201835120033
2019-09-02 17:11:46 139893275596544 [Note] InnoDB: Loading buffer
pool(s) from /Volumes/dune/mysql/mysql_dbmail/ib_buffer_pool
2019-09-02 17:11:46 139893275596544 [Note] InnoDB: Cannot open
'/Volumes/dune/mysql/mysql_dbmail/ib_buffer_pool' for reading: No such
file or directory
2019-09-02 17:11:46 139893743717888 [Note] Server socket created on IP:
'0.0.0.0'.
2019-09-02 17:11:46 139893743717888 [Note] /usr/libexec/mysqld: ready
for connections.
Version: '10.2.26-MariaDB'  socket: '/var/lib/mysql/mysqld_dbmail.sock'
 port: 3307  thelounge
2019-09-02 17:11:46 139893708191488 [Note] Slave SQL thread initialized,
starting replication in log 'bin.002679' at position 49489, relay log
'./mysql-relay-bin.983139' position: 549
2019-09-02 17:11:46 139893708498688 [Note] Slave I/O thread: connected
to master 'replication@c*:3307',replication started in log
'bin.002679' at position 49489
[root@localhost:~]$


___
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

[Maria-discuss] 10.3.x: unknown variable 'innodb_support_xa=1'

[Reindl Harald]

unknown variable 'innodb_support_xa=1'

would you funny guys consider things like deperectaion warnings in
previous releases or at least offer an option to change all these
fucking "i don't know a option because it was removed or you did not
compile something in and hence i refuse to start the server" to warnings?

___
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] mariadb + FIPS

[Reindl Harald]

Am 30.08.19 um 00:10 schrieb Captain Wiggum:
> I have searched the archives and forums and cannot find an answer to
> this question.
> Does mariadb support FIPS, and if so, how or where is a document about this.
> I use mariadb 10.3.17 with OpenSSL 1.0.2 with FIPS enabled, all built
> from source.
> In FIPS mode, SHA1 is disallowed by openssl, as required by FIPS.
> However, when I search the mariadb code, SHA1 is used in many places.
> How can I update mariadb to use sha256, without a ton of recoding?
> Any tips appreciated.

outside of encryption code nothing is wrong with SHA1 depending on the
usecase and without context "SHA1 is used in many place" is a useless
statement

there are even usecases where MD4 is just fine

againb: not every usage of a hash function is security related or
collisions prone and in that case it would be pretty dumb use a much
slower sha256 hash

___
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] Disk increase with MAD and MAI extension files in tmp dir

[Reindl Harald]

Am 07.08.19 um 10:30 schrieb Kevin DG:
> MariaDB version -> 10.3.14
> 
> Recently, we had a new problem with our MariaDB instance. Indeed,
> suddenly the size of the tmp directory has increased almost
> instantaneously, to finish saturating the disk.
> 
> We have encountered this problem twice and don't understand currently
> the problem origin.
> 
> The result of 'ls -l /tmp' during the problem:
> 
> mysql@16c212e7dbb5:/tmp# ls -l
> total 126786988
> -rw-rw 1 mysql mysql 14190428160 Jul  8 15:18 '#sql_1_1.MAD'
> -rw-rw 1 mysql mysql        8192 Jul  8 15:02 '#sql_1_1.MAI'
> -rw-rw 1 mysql mysql 13344178176 Jul  8 15:18 '#sql_1_11.MAD'
> -rw-rw 1 mysql mysql        8192 Jul  8 15:02 '#sql_1_11.MAI'
> -rw-rw 1 mysql mysql 13344546816 Jul  8 15:18 '#sql_1_14.MAD'
looks like temporary tables from bad queries
enable slow query log

___
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] ERROR 1071 with mysql_upgrade

[Reindl Harald]

Am 16.07.19 um 21:13 schrieb Sergei Golubchik:
> you can run mysql_fix_privilege_tables.sql manually. Like with
> mysql -uroot -p -vvv < mysql_fix_privilege_tables.sql

how would that solve the issue of a obviously incompatible change in 10.4?

> On Jul 16, Erik Cederstrand wrote:
>> Hi,
>>
>> I'm trying to upgrade a MariaDB 10.2 server to 10.4.6 on FreeBSD.
>>
>> When running the mysql_update command, it dies with:
>>
>> $ mysql_upgrade 
>> Phase 1/7: Checking and upgrading mysql database
>> Processing databases
>> mysql
> ...
>> mysql.transaction_registry OK
>> Phase 2/7: Installing used storage engines... Skipped
>> Phase 3/7: Fixing views
>> mysql.user OK
>> Phase 4/7: Running 'mysql_fix_privilege_tables'
>> ERROR 1071 (42000) at line 437: Specified key was too long; max key length 
>> is 1000 bytes
>> FATAL ERROR: Upgrade failed
>>
>> Adding verbose option does not give more hints, and the failing SQL
>> statement doesn't seem to be logged with full query logging turned on.
>>
>> How do I debug this? I can't even see which table or column it's
>> complaining about. I don't remember fiddling with collation or
>> character sets on system tables.


___
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] How do I determine if versions of phpMyAdmin before 4.8.5 is SQL Injectable using sqlmap?

[Reindl Harald]

Am 17.04.19 um 23:03 schrieb Jeff Dyke:
> I've done this and i'm doing this, its not hard, everyone that needs db
> access can read a readme and give me a public key in a matter of
> seconds.  I'll take SSH over http-auth and a freaken app that can drop
> tables/database via a SQL injection bug any day of the week.  Granted
> that could be from poor user management, as NOONE has access to do
> anything destructive.
> 
> I really don't care if you don't believe me, b/c this process has been
> fluid with 0 issues since i started using it about 6 years ago.  Oh and
> yesterdays users were 100% ordinary users (it doesn't get much more
> ordinary than marketing), they were added to the slave group with select
> only, and didn't get added to anything production related.

well, that's a completly different world than typical hosting

when you require from that target audience public-keys, install ative
apps, give them only read access you are just done because you ahrdly
can sell that to anybody



___
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] How do I determine if versions of phpMyAdmin before 4.8.5 is SQL Injectable using sqlmap?

[Reindl Harald]

Am 17.04.19 um 22:43 schrieb Reindl Harald:
> 
> 
> Am 17.04.19 um 22:39 schrieb Jeff Dyke:
>> How can you say it doesn't scale when you have now idea how i'm set up. 
>> I had to add 5 users yesterday, took 5-10 (mostly talking to people)
>> minutes.  Using a config mgmt system i set up ssh and mysql in the same
>> single call to multiple database servers some users will have multiple
>> logins based on the ability to read and the ability to write, which
>> based on the configured security group.  It scales quite well indeed and
>> i don't have to worry about a php application were security risks are
>> more prone to come with each update.  Also http-auth takes admin as well.  
> 
> yeah, explain ordianry users how to get ssh-certificates all day long
> and don't come with "but for the tunnel password auth is enough" when
> you weaken the most cruial service on a systemd for a damend web application

and no, it's not only about how make credentials, it's tell a random
monkey "go to this URL" versus "you need this and that and a local
native application" and that in 2019

___
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] How do I determine if versions of phpMyAdmin before 4.8.5 is SQL Injectable using sqlmap?

[Reindl Harald]

Am 17.04.19 um 22:39 schrieb Jeff Dyke:
> How can you say it doesn't scale when you have now idea how i'm set up. 
> I had to add 5 users yesterday, took 5-10 (mostly talking to people)
> minutes.  Using a config mgmt system i set up ssh and mysql in the same
> single call to multiple database servers some users will have multiple
> logins based on the ability to read and the ability to write, which
> based on the configured security group.  It scales quite well indeed and
> i don't have to worry about a php application were security risks are
> more prone to come with each update.  Also http-auth takes admin as well.  

yeah, explain ordianry users how to get ssh-certificates all day long
and don't come with "but for the tunnel password auth is enough" when
you weaken the most cruial service on a systemd for a damend web application

___
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] How do I determine if versions of phpMyAdmin before 4.8.5 is SQL Injectable using sqlmap?

[Reindl Harald]

i yet need to see the difference between SSH tunnels and all the
administrative burden versus phpMyAdmin behind http-auth long before
it's native login

your stuff don't scale on a setup with external users which for sure
don't get ssh-tunnels or much worser vpn access and without external
users the whole issue don't exist

Am 17.04.19 um 19:30 schrieb Jeff Dyke:
> I appreciate your points, but i don't give them out to 'every random
> monkey', that would completely against the setup I've chosen.  Showing
> someone how to ssh-tunnel via putty is not hard, and is only once and
> can be documented.  The people that i give ssh access to are managed
> centrally via a config mgmt system and they only have access to the
> bastion host, and are not users on any other host.  Also they can only
> connect to mysql from that host(which really doesn't matter since they
> can't get to another host).  And my point really mainly is for cloud
> infrastructures; if you're on a corporate network, hopefully the
> sysadmin has installed a VPN which can be used and then you can VPN to
> the network and connect like you're local, which you could also do in
> the cloud.
> 
> So IMHO it is much more secure, perhaps the way it's set up here and
> again it's just my 2 cents.  SSH Tunnels to a bastion host that is not
> allowed to talk to another host will always be more secure than any
> phpMyAdmin configuration.
> 
> Again, i appreciate your point of view, but wanted to qualify some of my
> answers.
> 
> On Wed, Apr 17, 2019 at 1:18 PM Reindl Harald  <mailto:h.rei...@thelounge.net>> wrote:
> 
> 
> 
> Am 17.04.19 um 18:55 schrieb Jeff Dyke:
> > Reindl's (funny) comments aside.  Why still use phpMyAdmin in this day
> > and age.  Nearly every maria/percona/mysql client supports ssh
> > tunneling.  SequelPro on Mac, Heidi (or others) on Windows, and any
> > windows client running through wine if your desktop/laptop is linux. 
> > Also developers can just use intellij or similar IDE's that have a
> > database pane. 
> >
> > Trusting administration to an exposed phpMyAdmin in this day and age
> > frightens me greatly.  Also if you had an HIDS server running to track
> > bad phpMyAdmin logins i bet there would be a ton of alerts.  I've
> > blocked all such attempts in my IPS even though i don't have
> phpMyAdmin.
> >
> > I realize this does not answer your question, but if this fits
> into your
> > architecture i'd say good by to that web interface.
> 
> because it's nonsense to believe that you can manage to handle everybody
> which probably needs to access mysql with his restricted account to
> learn how to use ssh-tunnles
> 
> and that you are plain wrong when you believe hand out ssh tunnels into
> your network for every random monkey increases security
> 
> not talking about that he is obviously a 3rd party to a customer where
> you have no say in that context
> 
> the problem is *exposing* phpMyAdmin for the whole world and asking
> stupid questions like which version before the latest one instead just
> update it and when you are too dumb building packages for the target OS
> hire some one which is capable to do so or unpack that dmaned folder
> ph hand
> 
> > On Wed, Apr 17, 2019 at 10:54 AM Reindl Harald
> mailto:h.rei...@thelounge.net>
> > <mailto:h.rei...@thelounge.net <mailto:h.rei...@thelounge.net>>>
> wrote:
> >
> >
> >
> >     Am 17.04.19 um 16:50 schrieb Turritopsis Dohrnii Teo En Ming:
> >     > Subject/Topic: How do I determine if versions of phpMyAdmin
> before
> >     4.8.5 is SQL Injectable using sqlmap?
> >
> >     frankly are you drunken?
> >
> >     you posted this exactly same message to
> >
> >     * phpmyadmin list TWICE
> >     * oracle mysql list
> >     * now mariadb list
> >
> >     i seriously looked if my mailserver has a problem - stop it
> damned!

___
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] How do I determine if versions of phpMyAdmin before 4.8.5 is SQL Injectable using sqlmap?

[Reindl Harald]

Am 17.04.19 um 18:55 schrieb Jeff Dyke:
> Reindl's (funny) comments aside.  Why still use phpMyAdmin in this day
> and age.  Nearly every maria/percona/mysql client supports ssh
> tunneling.  SequelPro on Mac, Heidi (or others) on Windows, and any
> windows client running through wine if your desktop/laptop is linux. 
> Also developers can just use intellij or similar IDE's that have a
> database pane. 
> 
> Trusting administration to an exposed phpMyAdmin in this day and age
> frightens me greatly.  Also if you had an HIDS server running to track
> bad phpMyAdmin logins i bet there would be a ton of alerts.  I've
> blocked all such attempts in my IPS even though i don't have phpMyAdmin.
> 
> I realize this does not answer your question, but if this fits into your
> architecture i'd say good by to that web interface.

because it's nonsense to believe that you can manage to handle everybody
which probably needs to access mysql with his restricted account to
learn how to use ssh-tunnles

and that you are plain wrong when you believe hand out ssh tunnels into
your network for every random monkey increases security

not talking about that he is obviously a 3rd party to a customer where
you have no say in that context

the problem is *exposing* phpMyAdmin for the whole world and asking
stupid questions like which version before the latest one instead just
update it and when you are too dumb building packages for the target OS
hire some one which is capable to do so or unpack that dmaned folder ph hand

> On Wed, Apr 17, 2019 at 10:54 AM Reindl Harald  <mailto:h.rei...@thelounge.net>> wrote:
> 
> 
> 
> Am 17.04.19 um 16:50 schrieb Turritopsis Dohrnii Teo En Ming:
> > Subject/Topic: How do I determine if versions of phpMyAdmin before
> 4.8.5 is SQL Injectable using sqlmap?
> 
> frankly are you drunken?
> 
> you posted this exactly same message to
> 
> * phpmyadmin list TWICE
> * oracle mysql list
> * now mariadb list
> 
> i seriously looked if my mailserver has a problem - stop it damned!

___
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] How do I determine if versions of phpMyAdmin before 4.8.5 is SQL Injectable using sqlmap?

[Reindl Harald]

Am 17.04.19 um 16:50 schrieb Turritopsis Dohrnii Teo En Ming:
> Subject/Topic: How do I determine if versions of phpMyAdmin before 4.8.5 is 
> SQL Injectable using sqlmap?

frankly are you drunken?

you posted this exactly same message to

* phpmyadmin list TWICE
* oracle mysql list
* now mariadb list

i seriously looked if my mailserver has a problem - stop it damned!


___
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] required mysql_upgrade; MDEV-14637

[Reindl Harald]

Am 03.04.19 um 09:54 schrieb mj:
> On 3/28/19 11:59 AM, Reindl Harald wrote:
>> our production datadirs date back to 2002, originally on windows then
>> moved to MacOS and in 2008 to Fedora and i did not dump/restore a single
>> time in my whole life, this is not postgresql
> 
> Just curiosity: does the above statement mean that you consider
> postgresql less stable than mariadb/mysql? And why..?

beasue any application which can't read it's data after upgrade to a new
version is f**g crap and pretty unusable when using as example
distro-packages - when you forgot the dump with the old version your are
fucked

additionally that means you have downtimes nobody needs, a dist-upgrade
here is a "dnf --releasever=xx distro-sync" for 11 years now followed by
a reboot like for any kernel update with no downtimes

again: my "mysql" database dates back to version 3.x, that's what i
consider production quality

___
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] required mysql_upgrade; MDEV-14637

[Reindl Harald]

Am 28.03.19 um 11:16 schrieb Michal Schorm:
> Hello,
> I have a questions regarding the warnings showing up at 10.2 and 10.3 
> releases:
> 
> When upgrading from MariaDB 10.2.16 or earlier to MariaDB 10.2.17 or higher,
> running mysql_upgrade is required due to changes introduced in MDEV-14637.
> 
> When upgrading from MariaDB 10.3.8 or earlier to MariaDB 10.3.9 or higher,
> running mysql_upgrade is required due to changes introduced in MDEV-14637.
> 
> --
> 
> 1) The same applies for upgrading <=10.2.16 to >= 10.3.9, right?
> 
> 2) Does it mean, it is impossible to use "dump and restore" technique,
> or it only means I need to run the mysql_upgrade afterwards?
> 
> 3) The problem is not triggered when upgrading from 5.5, 10.0 and 10.1?
> 4) The problem is not triggered when upgrading to 10.4 ?

just run "mysql_upgrade" after each update and you are done

our production datadirs date back to 2002, originally on windows then
moved to MacOS and in 2008 to Fedora and i did not dump/restore a single
time in my whole life, this is not postgresql

___
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] MariaDB 10.2.23 and MariaDB Connector/J 2.4.1 now available

[Reindl Harald]

Am 26.03.19 um 00:19 schrieb Sergei Golubchik:
> Hi, Reindl!
> 
> Sorry. You have a highly customized configuration that doesn't match
> anything we test, so these issues happen sometimes :(

well it's a "nobody needs anything above innodb, myisam and be it aria
on most environvents"-build based on "what's not used needs not to be
here and what's not here don't make troubles" basicly unchanged for
years as long you guys not force me to touch it

other than most software projects where as much as possible
disable/without reduces all sorts of issues, at build too, it's always
fun with MariaDB

> I've now added -DENABLED_PROFILING=OFF to one of our builders, so this
> particular failure won't happen again

thanks

> We also test -DPLUGIN_PERFSCHEMA=NO and -DPLUGIN_PARTITION=NO as they've
> used to cause problems before.

yeah, guess where, my config is not new :-)

> Regards,
> Sergei
> Chief Architect MariaDB
> and secur...@mariadb.org
> 
> On Mar 25, Reindl Harald wrote:
>> congratulations, again a point update which just don't compile
>>
>> frankly what about RC announcements so that idiots like me building
>> packages from source can point out such issues *before* official
>> announcements?
>>
>> [ 92%] Building CXX object sql/CMakeFiles/sql.dir/sql_plugin.cc.o
>> [ 92%] Building CXX object sql/CMakeFiles/sql.dir/sql_prepare.cc.o
>> [ 92%] Building CXX object sql/CMakeFiles/sql.dir/sql_rename.cc.o
>> /home/builduser/rpmbuild/BUILD/mariadb-10.2.23/sql/sql_parse.cc: In
>> function 'int mysql_execute_command(THD*)':
>> /home/builduser/rpmbuild/BUILD/mariadb-10.2.23/sql/sql_parse.cc:3515:16:
>> error: 'class THD' has no member named 'profiling'
>>thd->profiling.discard_current_query();
>>
>>
>> cmake . \
>>  -DFEATURE_SET="large" \
>>  -DCMAKE_INSTALL_PREFIX="%{_prefix}" \
>>  -DINSTALL_INCLUDEDIR=include/mysql \
>>  -DINSTALL_LAYOUT=RPM \
>>  -DDAEMON_NAME="mysqld" \
>>  -DDAEMON_NO_PREFIX="mysqld" \
>>  -DNICE_PROJECT_NAME="MariaDB" \
>>  -DINSTALL_LIBDIR="%{_lib}/mysql" \
>>  -DINSTALL_MANDIR=share/man \
>>  -DINSTALL_MYSQLSHAREDIR=share/mysql \
>>  -DINSTALL_MYSQLTESTDIR=share/mysql-test \
>>  -DINSTALL_PLUGINDIR="%{_lib}/mysql/plugin" \
>>  -DINSTALL_SBINDIR=libexec \
>>  -DINSTALL_SCRIPTDIR=bin \
>>  -DINSTALL_SQLBENCHDIR= \
>>  -DINSTALL_SUPPORTFILESDIR=share/mysql \
>>  -DMYSQL_DATADIR="%{_sharedstatedir}/mysql" \
>>  -DMYSQL_UNIX_ADDR="%{_sharedstatedir}/mysql/mysql.sock" \
>>  -DENABLED_PROFILING=OFF \
>>  -DENABLE_DEBUG_SYNC=OFF \
>>  -DENABLE_DTRACE=OFF \
>>  -DPLUGIN_ARIA=YES \
>>  -DPLUGIN_CSV=YES \
>>  -DPLUGIN_MYISAM=YES \
>>  -DPLUGIN_ARCHIVE=NO \
>>  -DPLUGIN_BLACKHOLE=NO \
>>  -DPLUGIN_CASSANDRA=NO \
>>  -DPLUGIN_CONNECT=NO \
>>  -DPLUGIN_EXAMPLE=NO \
>>  -DPLUGIN_FEDERATED=NO \
>>  -DPLUGIN_FEDERATEDX=NO \
>>  -DPLUGIN_FEEDBACK=NO \
>>  -DPLUGIN_MROONGA=NO \
>>  -DPLUGIN_MYISAMMRG=NO \
>>  -DPLUGIN_OQGRAPH=NO \
>>  -DPLUGIN_PARTITION=NO \
>>  -DPLUGIN_PERFSCHEMA=NO \
>>  -DPLUGIN_ROCKSDB=NO \
>>  -DPLUGIN_SEMISYNC=NO \
>>  -DPLUGIN_SEQUENCE=NO \
>>  -DPLUGIN_SPHINX=NO \
>>  -DPLUGIN_SPIDER=NO \
>>  -DPLUGIN_TOKUDB=NO \
>>  -DPLUGIN_XTRADB=NO \
>>  -DWITHOUT_DYNAMIC_PLUGINS=ON \
>>  -DWITH_ATOMIC_OPS=smp \
>>  -DWITH_EMBEDDED_SERVER=OFF \
>>  -DWITH_INNODB_DISALLOW_WRITES=OFF \
>>  -DWITH_INNODB_BZIP2=OFF \
>>  -DWITH_INNODB_LZ4=OFF \
>>  -DWITH_INNODB_LZMA=OFF \
>>  -DWITH_INNODB_LZO=OFF \
>>  -DWITH_INNODB_SNAPPY=OFF \
>>  -DWITH_MYSQLCOMPAT=ON \
>>  -DSECURITY_HARDENED=OFF \
>>  -DWITH_LIBARCHIVE=OFF \
>>  -DWITH_LIBWRAP=OFF \
>>  -DWITH_MARIABACKUP=OFF \
>>  -DWITH_PIC=NO \
>>  -DWITH_READLINE=OFF \
>>  -DWITH_SAFEMALLOC=OFF \
>>  -DWITH_VALGRIND=OFF \
>>  -DWITH_WSREP=OFF \
>>  -DWITH_JEMALLOC=OFF \
>>  -DWITH_SSL=system \
>>  -DWITH_ZLIB=system

___
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] [MariaDB Announce] MariaDB 10.2.23 and MariaDB Connector/J 2.4.1 now available

[Reindl Harald]

congratulations, again a point update which just don't compile

frankly what about RC announcements so that idiots like me building
packages from source can point out such issues *before* official
announcements?

[ 92%] Building CXX object sql/CMakeFiles/sql.dir/sql_plugin.cc.o
[ 92%] Building CXX object sql/CMakeFiles/sql.dir/sql_prepare.cc.o
[ 92%] Building CXX object sql/CMakeFiles/sql.dir/sql_rename.cc.o
/home/builduser/rpmbuild/BUILD/mariadb-10.2.23/sql/sql_parse.cc: In
function 'int mysql_execute_command(THD*)':
/home/builduser/rpmbuild/BUILD/mariadb-10.2.23/sql/sql_parse.cc:3515:16:
error: 'class THD' has no member named 'profiling'
   thd->profiling.discard_current_query();


cmake . \
 -DFEATURE_SET="large" \
 -DCMAKE_INSTALL_PREFIX="%{_prefix}" \
 -DINSTALL_INCLUDEDIR=include/mysql \
 -DINSTALL_LAYOUT=RPM \
 -DDAEMON_NAME="mysqld" \
 -DDAEMON_NO_PREFIX="mysqld" \
 -DNICE_PROJECT_NAME="MariaDB" \
 -DINSTALL_LIBDIR="%{_lib}/mysql" \
 -DINSTALL_MANDIR=share/man \
 -DINSTALL_MYSQLSHAREDIR=share/mysql \
 -DINSTALL_MYSQLTESTDIR=share/mysql-test \
 -DINSTALL_PLUGINDIR="%{_lib}/mysql/plugin" \
 -DINSTALL_SBINDIR=libexec \
 -DINSTALL_SCRIPTDIR=bin \
 -DINSTALL_SQLBENCHDIR= \
 -DINSTALL_SUPPORTFILESDIR=share/mysql \
 -DMYSQL_DATADIR="%{_sharedstatedir}/mysql" \
 -DMYSQL_UNIX_ADDR="%{_sharedstatedir}/mysql/mysql.sock" \
 -DENABLED_PROFILING=OFF \
 -DENABLE_DEBUG_SYNC=OFF \
 -DENABLE_DTRACE=OFF \
 -DPLUGIN_ARIA=YES \
 -DPLUGIN_CSV=YES \
 -DPLUGIN_MYISAM=YES \
 -DPLUGIN_ARCHIVE=NO \
 -DPLUGIN_BLACKHOLE=NO \
 -DPLUGIN_CASSANDRA=NO \
 -DPLUGIN_CONNECT=NO \
 -DPLUGIN_EXAMPLE=NO \
 -DPLUGIN_FEDERATED=NO \
 -DPLUGIN_FEDERATEDX=NO \
 -DPLUGIN_FEEDBACK=NO \
 -DPLUGIN_MROONGA=NO \
 -DPLUGIN_MYISAMMRG=NO \
 -DPLUGIN_OQGRAPH=NO \
 -DPLUGIN_PARTITION=NO \
 -DPLUGIN_PERFSCHEMA=NO \
 -DPLUGIN_ROCKSDB=NO \
 -DPLUGIN_SEMISYNC=NO \
 -DPLUGIN_SEQUENCE=NO \
 -DPLUGIN_SPHINX=NO \
 -DPLUGIN_SPIDER=NO \
 -DPLUGIN_TOKUDB=NO \
 -DPLUGIN_XTRADB=NO \
 -DWITHOUT_DYNAMIC_PLUGINS=ON \
 -DWITH_ATOMIC_OPS=smp \
 -DWITH_EMBEDDED_SERVER=OFF \
 -DWITH_INNODB_DISALLOW_WRITES=OFF \
 -DWITH_INNODB_BZIP2=OFF \
 -DWITH_INNODB_LZ4=OFF \
 -DWITH_INNODB_LZMA=OFF \
 -DWITH_INNODB_LZO=OFF \
 -DWITH_INNODB_SNAPPY=OFF \
 -DWITH_MYSQLCOMPAT=ON \
 -DSECURITY_HARDENED=OFF \
 -DWITH_LIBARCHIVE=OFF \
 -DWITH_LIBWRAP=OFF \
 -DWITH_MARIABACKUP=OFF \
 -DWITH_PIC=NO \
 -DWITH_READLINE=OFF \
 -DWITH_SAFEMALLOC=OFF \
 -DWITH_VALGRIND=OFF \
 -DWITH_WSREP=OFF \
 -DWITH_JEMALLOC=OFF \
 -DWITH_SSL=system \
 -DWITH_ZLIB=system

Am 25.03.19 um 22:28 schrieb MariaDB Announce List:
> The MariaDB Foundation is pleased to announce the availability
> of MariaDB 10.2.23, the latest stable release in the MariaDB
> 10.2 series, as well as MariaDB Connector/J 2.4.1, the latest
> stable MariaDB Connector/J release.
> 
> See the Release Notes and Changelogs for details.
> 
> 
> - - Links  - - - - - - - - - - - - - - - - - - - - - - - - - - - - - -
> 
> MariaDB 10.2.23
>   - Release Notes: https://mariadb.com/kb/en/mdb-10223-rn/
>   - Changelog: https://mariadb.com/kb/en/mdb-10223-cl/
>   - Downloads: https://downloads.mariadb.org/mariadb/10.2.23
> 
>   About MariaDB 10.2:
>    - https://mariadb.com/kb/en/what-is-mariadb-102/
> 
>   APT and YUM Repository Configuration Generator:
>    - https://downloads.mariadb.org/mariadb/repositories/
> 
> 
> MariaDB Connector/J 2.4.1
>  - Release Notes: https://mariadb.com/kb/en/mcj-241-rn/
>  - Changelog: https://mariadb.com/kb/en/mcj-241-cl/
>  - Downloads: https://downloads.mariadb.org/connector-java/2.4.1/
> 
> - - MariaDB Books  - - - - - - - - - - - - - - - - - - - - - - - - - -
> 
> There is an ever-growing library of MariaDB books available to help
> you get the most out of MariaDB. See the MariaDB Books page for
> details and links:
> 
>   - https://mariadb.org/learn/books/
> 
> 
> - - User Feedback plugin - - - - - - - - - - - - - - - - - - - - - - -
> 
> MariaDB includes a User Feedback plugin. This plugin is disabled by
> default. If enabled, it submits basic, completely anonymous MariaDB
> usage information. This information is used by the developers to
> track trends in MariaDB usage to better guide development efforts.
> 
> If you would like to help make MariaDB better, please add
> "feedback=ON" to your my.cnf or my.ini file!
> 
> See http://mariadb.com/kb/en/user-feedback-plugin for more
> information.
> 
> 
> - - Quality  - - - - - - - - - - - - - - - - - - - - - - - - - - - - -
> 
> The project always strives for quality, but in reality, nothing is
> perfect. Please take time to report any issues you encounter at:
> 
>   - http://jira.mariadb.org
> 
> Note that the bug tracker is not a support channel. If you are
> running MariaDB in an enterprise environment, please consider paying
> for support and related services from a commercial company:
> 
> - https://mariadb.org/about/service-providers/
> 
> MariaDB is a true open source project. We welcome everyone's
> contributions, be it by testing, submitting 

[Maria-discuss] Fwd: [MariaDB Announce] MariaDB 10.2.19 now available

[Reindl Harald]

hell, a new file again breaking rpm-build
/usr/lib/pkgconfig/libmariadb.pc

adjusted mariadb.spec
error: File not found:
/home/builduser/rpmbuild/BUILDROOT/mariadb-10.2.19-0.fc28.20181114.rh.sandybridge.x86_64/usr/lib64/pkgconfig/libmariadb.pc

WTF - why is that crap on a x86_64 system in
/usr/lib/pkgconfig/libmariadb.pc instead /usr/lib64/pkgconfig/libmariadb.pc

sane people use rpm macros
%{_libdir}/pkgconfig/mariadb.pc
%{_libdir}/pkgconfig/libmariadb.pc

well, another trial and error to fix the build...

 Weitergeleitete Nachricht 
Betreff: [MariaDB Announce] MariaDB 10.2.19 now available
Datum: Tue, 13 Nov 2018 20:20:34 +0200
Von: MariaDB Announce List 
An: annou...@mariadb.org

The MariaDB Foundation is pleased to announce the availability
of MariaDB 10.2.19, the latest stable release in the MariaDB
10.2 series.


___
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] My Solution to MariaDB Database Server Crashed in Experimental Online Store

[Reindl Harald]

Am 22.10.18 um 23:12 schrieb Daniel Black:
>> Giving my virtual server more than 1 GB of RAM will cost me more
>> money.
> 
> Sometimes you can't run a real service on less memory than your phone

+1

with 1 GB you just survive basic operations and system-upgrades, below
768 MB you even don't surivive memory spikes of a "dnf upgrade"

and yes, i remember the times when i had run MS Windows Advances Server
with LAMP, Office, Photoshop, CorelDraw and a tiny Linux VM on a machine
with 192 MB RAM but sadly that times are gone by lazy developers wating
ressources

frankly i had seen page allocation errors leading to VMware HA trigger
in 2015 on Fedora guests wth just 1 GB RAM doing *nothing* than rsync
backups, that got better but doing anything useful with 1 GB RAM is a
bad job and shows lack of any expirience as well as the orginal post did
talking about crahses while not show any single sing of them but talk
about "sytemctl start/enable" which has nothing to do with crashes

___
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] My Solution to MariaDB Database Server Crashed in Experimental Online Store

[Reindl Harald]

Am 22.10.18 um 11:48 schrieb Turritopsis Dohrnii Teo En Ming:
> My MariaDB SQL Database Server really crashed. I did not reboot my virtual 
> server at all. It has crashed twice already.

in your first message you only mentioned
systemctl start mariadb.service
systemctl enable mariadb.service

at at least when you pretend that enable a service solved your porblemn
and don't provide any useful informations what do you think?

http://www.catb.org/esr/faqs/smart-questions.html#beprecise

> 181019  9:04:06 [ERROR] mysqld: Out of memory (Needed 128917504 bytes)
> 181019  9:04:06 [ERROR] mysqld: Out of memory (Needed 96681984 bytes)
> 181019  9:04:06 [ERROR] mysqld: Out of memory (Needed 72499200 bytes)

reduce innodb_buffer_pool_size and look with mysqltuner which
per-thread-buffers which you thougfht are per instance are pervertly
high which is a often made mistake and last but not least it tells you
the highest to expect memory usage from mysqld with your config where
you need in mind that the OS and other applications needs memory too

anyways, 1 GB is a joke for a server doing more than sitting around


___
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] My Solution to MariaDB Database Server Crashed in Experimental Online Store

[Reindl Harald]

Am 19.10.18 um 13:17 schrieb Turritopsis Dohrnii Teo En Ming:
> Good evening from Singapore,
> 
> Here is my solution:
> 
> # systemctl start mariadb.service
> 
> # mysql
> Welcome to the MariaDB monitor.  Commands end with ; or \g.
> Your MariaDB connection id is 2
> Server version: 5.5.60-MariaDB MariaDB Server
> 
> Copyright (c) 2000, 2018, Oracle, MariaDB Corporation Ab and others.
> 
> Type 'help;' or '\h' for help. Type '\c' to clear the current input statement.
> 
> MariaDB [(none)]> quit
> Bye
> 
> # systemctl enable mariadb.service

what has this to do with a crash?
you simply forgot to enable the service and rebootet

___
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] [EXTERNAL] Re: Copying database files

[Reindl Harald]

Am 13.08.2018 um 14:33 schrieb Sergei Golubchik:
> On Aug 13, Reindl Harald wrote:
>>
>>
>> Am 13.08.2018 um 12:22 schrieb Ling, Andy:
>>>> "The advantage of FLUSH TABLES table_name FOR EXPORT is that the table
>>>> is read locked until UNLOCK TABLES is executed" is not really true
>>>> because that's only valid for the running connection
>>>
>>> Surely not. If you've locked a table for read only nothing should be
>>> able to write to it from any connection otherwise what's the point
>>> of a multi-threaded server? Tests suggest otherwise.
>>
>> surely YES
>>
>> https://blogs.vmware.com/vsphere/2014/12/mysql-backup-with-vdp.html
>> "Another item to be aware of with this statement is that the read lock
>> is released as soon as the session that made the call ends. When the
>> pre-freeze-script finishes, the session is closed" - try it out
>>
>> and how do you make a script that locks the table and continues without
>> closing the session to mysqld?
> 
> It's possible. In one of my personal projects I've used something like
> 
> echo "flush tables with read lock;\n\! mysqlhotcopy ..." | mysql

please read again what i quoted from the article!
it is *not* possible except for some very limited usecases

* vmware calls a shell script which should lock tables
* vmware does fs-freeze, the script is completly finished
* vmware takes a snaphot of the guest
* from the moment the script with "flush tables with read lock;"
  has finsihed the lock is gone


___
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] [EXTERNAL] Re: Copying database files

[Reindl Harald]

Am 13.08.2018 um 12:27 schrieb Sergei Golubchik:
> On Aug 13, Ling, Andy wrote:
>>
>> The code doing this stops everything talking to the database (Yes, I
>> know there could be someone fiddling remotely in a shell, but this is
>> very unlikely). Even tables which are never written to cause this
>> error
>>
>> So if I'm careful, is there a way to make this work without stopping
>> the server?
> 
> I'd expect FLUSH TABLES ... FOR EXPORT to work.
> 
> What exactly are you getting? Can you perhaps create a test case? Or
> just report a bug at jira.mariadb.org?

https://blogs.vmware.com/vsphere/2014/12/mysql-backup-with-vdp.html

"Another item to be aware of with this statement is that the read lock
is released as soon as the session that made the call ends" is still
true for MariaDB 10.2.x

___
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] [EXTERNAL] Re: Copying database files

[Reindl Harald]

Am 13.08.2018 um 12:22 schrieb Ling, Andy:
>> "The advantage of FLUSH TABLES table_name FOR EXPORT is that the table
>> is read locked until UNLOCK TABLES is executed" is not really true
>> because that's only valid for the running connection
> 
> Surely not. If you've locked a table for read only nothing should be able to 
> write to it from any connection otherwise what's the point of a 
> multi-threaded server? Tests suggest otherwise.

surely YES

https://blogs.vmware.com/vsphere/2014/12/mysql-backup-with-vdp.html
"Another item to be aware of with this statement is that the read lock
is released as soon as the session that made the call ends. When the
pre-freeze-script finishes, the session is closed" - try it out

and how do you make a script that locks the table and continues without
closing the session to mysqld?

--

"I forgot to use reply all. Most lists, just reply works" - FOR THE SAKE
OF GOD reply just to the list, no reply all, no reply to from-address -
that's why proper mail clients have a reply-list button in case headers
in the mail exists which is true here and with your idiotic reply-all
you broke my reply-list button and that breaks threading now

___
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] [EXTERNAL] Re: Copying database files

[Reindl Harald]

Am 13.08.2018 um 11:57 schrieb Ling, Andy:
>>> I'm using MariaDB 10.2.13 on Windows 7.  All tables are using the Aria
>>> engine.
>>>
>>> I am trying to initialise a slave database by copying the files between
>>> PCs, but when I try and use the copied files I get the error
>>>
>>> Table is from another system and must be zerofilled or repaired to be
>>> usable on this system
>>>
>>> Repairing the tables fixes this, but I'd rather not have to so that.
>>>
>>> I have tried various things suggested to stop this, but nothing seems to
>>> help. On the source server I have run aria_chk -zerofill on all the
>>> tables. Before copying the tables I run FLUSH TABLES  FOR
>>> EXPORT, but I still get the error.
>> jesus don't copy tbale files around while the server is running
>>

no idea why you repsond off-list

> Does that mean this is not valid then...

did you read and understand it

> https://mariadb.com/kb/en/library/copying-tables-between-different-mariadb-databases-and-mariadb-servers/


how make you sure "The server is not accessing the tables during the
copy process"

"The advantage of FLUSH TABLES table_name FOR EXPORT is that the table
is read locked until UNLOCK TABLES is executed" is not really true
because that's only valid for the running connection

"Warning: If you do the above live copy, you are doing this on your own
risk" should be clear

in short: nobody right in his mind copies database tables hot

___
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] Copying database files

[Reindl Harald]

Am 13.08.2018 um 11:30 schrieb Ling, Andy:
> I’m using MariaDB 10.2.13 on Windows 7.  All tables are using the Aria
> engine.
> 
> I am trying to initialise a slave database by copying the files between
> PCs, but when I try and use the copied files I get the error
>  
> Table is from another system and must be zerofilled or repaired to be
> usable on this system
> 
> Repairing the tables fixes this, but I’d rather not have to so that.
> 
> I have tried various things suggested to stop this, but nothing seems to
> help. On the source server I have run aria_chk –zerofill on all the
> tables. Before copying the tables I run FLUSH TABLES  FOR
> EXPORT, but I still get the error.
jesus don't copy tbale files around while the server is running

* rsync hot
* shutdown master server
* rsync cold
* start master server


___
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] Disable Stric Mode MariaDB 10.4

[Reindl Harald]

Am 04.08.2018 um 17:55 schrieb Wilmer Arambula:
> Hi, i need disable strict mode Maria DB 10.4

what are you talking about?
http://www.catb.org/esr/faqs/smart-questions.html#beprecise

___
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