Justin,
I think the fsync I was concerning and the torn page problem are two
different things. But now I have a question about double write buffer. If
we can detect a torn page by checking the top and bottom of a page, why
would we still need double write buffer? If the page is consistent, then we
Hi,
The log does not have whole pages. Pages must not be torn for the recovery
process to work. A fsync is required when a page is written to disk.
During recovery all changes since the last checkpoint are replayed, then
transactions that do not have a commit marker are rolled back. This is
cal
Justin,
I was thinking of if fsync is needed each time after a write. The
operations are already in the log. So recovery can always be done from the
log. The difference is that during recovery, we need to go back further in
the log and it will take longer. But in that way, I guess it would be hard
Hi,
InnoDB recovery can not handle torn pages. An fsync is required to ensure
that the page is fully written to disk. This is also why the doublewrite
buffer is used. Before pages are written down to disk, they are first
written sequentially into the doublewrite buffer. This buffer is synced,
Laurynas,
This is exactly what I was looking for. I went through these functions
before. I disabled double write buffer, so I didn't pay attention to code
under buf_dblwr... The reason I asked this question is because I didn't
know how the recovery process works, so I was wondering if it's necessa
Am 08.05.2015 um 12:06 schrieb Sergei Golubchik:
Hi, Reindl!
On May 07, Reindl Harald wrote:
No, it affects the server, not mysql_upgrade. But it's a new
statement, that mysql_upgrade is using, no existing query can
possibly trigger that bug
well, in other words anybody could crash the s
Hi, Reindl!
On May 07, Reindl Harald wrote:
>
> > No, it affects the server, not mysql_upgrade. But it's a new
> > statement, that mysql_upgrade is using, no existing query can
> > possibly trigger that bug
>
> well, in other words anybody could crash the server by write a
> specific query and
Hi Ian, Pantelis,
What MySQL docs say is true, however confusing.
The value was switched ON in early versions of MySQL 5.5; caused some
problems; was switched back to OFF in 5.5.7; stayed OFF in all further
5.5 releases and early releases of 5.6; and was switched ON from 5.6.6.
For MariaDB it
Although the first MariaDB 5.5 release was 5.5.20... Anyway, fixed in
the docs now, thanks for the report.
On 08/05/2015 09:50, Ian Gilfillan wrote:
You're right that ON and OFF are switched around. I'll double check
the version that this changed - the 5.5 version of the MySQL docs at
http:
Thanks Pantelis
You're right that ON and OFF are switched around. I'll double check the
version that this changed - the 5.5 version of the MySQL docs at
http://dev.mysql.com/doc/refman/5.5/en/innodb-parameters.html#sysvar_innodb_file_per_table
also say that this was changed in 5.5.7 (so it was
10 matches
Mail list logo
