2009-05-27 15:15:59 +05:30
|
|
|
/*****************************************************************************
|
|
|
|
|
2017-05-15 17:17:16 +03:00
|
|
|
Copyright (c) 1995, 2017, Oracle and/or its affiliates. All Rights Reserved.
|
2017-05-23 11:09:47 +03:00
|
|
|
Copyright (c) 2017, MariaDB Corporation.
|
2009-05-27 15:15:59 +05:30
|
|
|
|
|
|
|
This program is free software; you can redistribute it and/or modify it under
|
|
|
|
the terms of the GNU General Public License as published by the Free Software
|
|
|
|
Foundation; version 2 of the License.
|
|
|
|
|
|
|
|
This program is distributed in the hope that it will be useful, but WITHOUT
|
|
|
|
ANY WARRANTY; without even the implied warranty of MERCHANTABILITY or FITNESS
|
|
|
|
FOR A PARTICULAR PURPOSE. See the GNU General Public License for more details.
|
|
|
|
|
|
|
|
You should have received a copy of the GNU General Public License along with
|
2012-08-01 17:27:34 +03:00
|
|
|
this program; if not, write to the Free Software Foundation, Inc.,
|
|
|
|
51 Franklin Street, Suite 500, Boston, MA 02110-1335 USA
|
2009-05-27 15:15:59 +05:30
|
|
|
|
|
|
|
*****************************************************************************/
|
|
|
|
|
|
|
|
/**************************************************//**
|
|
|
|
@file include/srv0start.h
|
|
|
|
Starts the Innobase database server
|
|
|
|
|
|
|
|
Created 10/10/1995 Heikki Tuuri
|
|
|
|
*******************************************************/
|
|
|
|
|
|
|
|
#ifndef srv0start_h
|
|
|
|
#define srv0start_h
|
|
|
|
|
|
|
|
#include "univ.i"
|
2012-08-01 17:27:34 +03:00
|
|
|
#include "log0log.h"
|
2009-05-27 15:15:59 +05:30
|
|
|
#include "ut0byte.h"
|
|
|
|
|
2016-08-12 11:17:45 +03:00
|
|
|
// Forward declaration
|
|
|
|
struct dict_table_t;
|
|
|
|
|
|
|
|
/** If buffer pool is less than the size,
|
|
|
|
only one buffer pool instance is used. */
|
|
|
|
#define BUF_POOL_SIZE_THRESHOLD (1024 * 1024 * 1024)
|
2012-08-01 17:27:34 +03:00
|
|
|
|
MDEV-12548 Initial implementation of Mariabackup for MariaDB 10.2
InnoDB I/O and buffer pool interfaces and the redo log format
have been changed between MariaDB 10.1 and 10.2, and the backup
code has to be adjusted accordingly.
The code has been simplified, and many memory leaks have been fixed.
Instead of the file name xtrabackup_logfile, the file name ib_logfile0
is being used for the copy of the redo log. Unnecessary InnoDB startup and
shutdown and some unnecessary threads have been removed.
Some help was provided by Vladislav Vaintroub.
Parameters have been cleaned up and aligned with those of MariaDB 10.2.
The --dbug option has been added, so that in debug builds,
--dbug=d,ib_log can be specified to enable diagnostic messages
for processing redo log entries.
By default, innodb_doublewrite=OFF, so that --prepare works faster.
If more crash-safety for --prepare is needed, double buffering
can be enabled.
The parameter innodb_log_checksums=OFF can be used to ignore redo log
checksums in --backup.
Some messages have been cleaned up.
Unless --export is specified, Mariabackup will not deal with undo log.
The InnoDB mini-transaction redo log is not only about user-level
transactions; it is actually about mini-transactions. To avoid confusion,
call it the redo log, not transaction log.
We disable any undo log processing in --prepare.
Because MariaDB 10.2 supports indexed virtual columns, the
undo log processing would need to be able to evaluate virtual column
expressions. To reduce the amount of code dependencies, we will not
process any undo log in prepare.
This means that the --export option must be disabled for now.
This also means that the following options are redundant
and have been removed:
xtrabackup --apply-log-only
innobackupex --redo-only
In addition to disabling any undo log processing, we will disable any
further changes to data pages during --prepare, including the change
buffer merge. This means that restoring incremental backups should
reliably work even when change buffering is being used on the server.
Because of this, preparing a backup will not generate any further
redo log, and the redo log file can be safely deleted. (If the
--export option is enabled in the future, it must generate redo log
when processing undo logs and buffered changes.)
In --prepare, we cannot easily know if a partial backup was used,
especially when restoring a series of incremental backups. So, we
simply warn about any missing files, and ignore the redo log for them.
FIXME: Enable the --export option.
FIXME: Improve the handling of the MLOG_INDEX_LOAD record, and write
a test that initiates a backup while an ALGORITHM=INPLACE operation
is creating indexes or rebuilding a table. An error should be detected
when preparing the backup.
FIXME: In --incremental --prepare, xtrabackup_apply_delta() should
ensure that if FSP_SIZE is modified, the file size will be adjusted
accordingly.
2017-06-30 10:49:37 +03:00
|
|
|
/** Open the configured number of dedicated undo tablespaces.
|
|
|
|
@param[in] create_new_db whether the database is being initialized
|
|
|
|
@return DB_SUCCESS or error code */
|
|
|
|
dberr_t
|
|
|
|
srv_undo_tablespaces_init(bool create_new_db);
|
|
|
|
|
2018-04-29 09:41:42 +03:00
|
|
|
/** Start InnoDB.
|
|
|
|
@param[in] create_new_db whether to create a new database
|
2016-08-12 11:17:45 +03:00
|
|
|
@return DB_SUCCESS or error code */
|
2018-04-29 09:41:42 +03:00
|
|
|
dberr_t srv_start(bool create_new_db);
|
2012-08-01 17:27:34 +03:00
|
|
|
|
2017-01-31 19:43:03 +02:00
|
|
|
/** Shut down InnoDB. */
|
2018-04-29 09:41:42 +03:00
|
|
|
void innodb_shutdown();
|
2012-08-01 17:27:34 +03:00
|
|
|
|
2017-06-08 15:43:06 +03:00
|
|
|
/** Shut down background threads that can generate undo log. */
|
2018-04-29 09:41:42 +03:00
|
|
|
void srv_shutdown_bg_undo_sources();
|
2016-12-14 17:46:58 +01:00
|
|
|
|
2013-03-26 00:03:13 +02:00
|
|
|
/*************************************************************//**
|
|
|
|
Copy the file path component of the physical file to parameter. It will
|
|
|
|
copy up to and including the terminating path separator.
|
|
|
|
@return number of bytes copied or ULINT_UNDEFINED if destination buffer
|
|
|
|
is smaller than the path to be copied. */
|
|
|
|
ulint
|
|
|
|
srv_path_copy(
|
|
|
|
/*==========*/
|
|
|
|
char* dest, /*!< out: destination buffer */
|
|
|
|
ulint dest_len, /*!< in: max bytes to copy */
|
|
|
|
const char* basedir, /*!< in: base directory */
|
|
|
|
const char* table_name) /*!< in: source table name */
|
2016-06-21 14:21:03 +02:00
|
|
|
MY_ATTRIBUTE((nonnull, warn_unused_result));
|
2013-03-26 00:03:13 +02:00
|
|
|
|
2016-08-12 11:17:45 +03:00
|
|
|
/** Get the meta-data filename from the table name for a
|
|
|
|
single-table tablespace.
|
|
|
|
@param[in] table table object
|
|
|
|
@param[out] filename filename
|
|
|
|
@param[in] max_len filename max length */
|
2013-03-26 00:03:13 +02:00
|
|
|
void
|
|
|
|
srv_get_meta_data_filename(
|
2016-08-12 11:17:45 +03:00
|
|
|
dict_table_t* table,
|
|
|
|
char* filename,
|
|
|
|
ulint max_len);
|
2013-03-26 00:03:13 +02:00
|
|
|
|
2016-09-06 09:43:16 +03:00
|
|
|
/** Get the encryption-data filename from the table name for a
|
|
|
|
single-table tablespace.
|
|
|
|
@param[in] table table object
|
|
|
|
@param[out] filename filename
|
|
|
|
@param[in] max_len filename max length */
|
|
|
|
void
|
|
|
|
srv_get_encryption_data_filename(
|
|
|
|
dict_table_t* table,
|
|
|
|
char* filename,
|
|
|
|
ulint max_len);
|
|
|
|
|
2009-05-27 15:15:59 +05:30
|
|
|
/** Log sequence number at shutdown */
|
2012-08-01 17:27:34 +03:00
|
|
|
extern lsn_t srv_shutdown_lsn;
|
2009-05-27 15:15:59 +05:30
|
|
|
/** Log sequence number immediately after startup */
|
2012-08-01 17:27:34 +03:00
|
|
|
extern lsn_t srv_start_lsn;
|
2009-05-27 15:15:59 +05:30
|
|
|
|
|
|
|
/** TRUE if the server is being started */
|
2016-08-12 11:17:45 +03:00
|
|
|
extern bool srv_is_being_started;
|
|
|
|
/** TRUE if SYS_TABLESPACES is available for lookups */
|
|
|
|
extern bool srv_sys_tablespaces_open;
|
2009-05-27 15:15:59 +05:30
|
|
|
/** TRUE if the server is being started, before rolling back any
|
|
|
|
incomplete transactions */
|
2016-08-12 11:17:45 +03:00
|
|
|
extern bool srv_startup_is_before_trx_rollback_phase;
|
2009-05-27 15:15:59 +05:30
|
|
|
|
|
|
|
/** TRUE if a raw partition is in use */
|
|
|
|
extern ibool srv_start_raw_disk_in_use;
|
|
|
|
|
|
|
|
/** Shutdown state */
|
2016-08-12 11:17:45 +03:00
|
|
|
enum srv_shutdown_t {
|
2009-05-27 15:15:59 +05:30
|
|
|
SRV_SHUTDOWN_NONE = 0, /*!< Database running normally */
|
|
|
|
SRV_SHUTDOWN_CLEANUP, /*!< Cleaning up in
|
|
|
|
logs_empty_and_mark_files_at_shutdown() */
|
2012-08-01 17:27:34 +03:00
|
|
|
SRV_SHUTDOWN_FLUSH_PHASE,/*!< At this phase the master and the
|
|
|
|
purge threads must have completed their
|
|
|
|
work. Once we enter this phase the
|
|
|
|
page_cleaner can clean up the buffer
|
|
|
|
pool and exit */
|
2009-05-27 15:15:59 +05:30
|
|
|
SRV_SHUTDOWN_LAST_PHASE,/*!< Last phase after ensuring that
|
|
|
|
the buffer pool can be freed: flush
|
|
|
|
all file spaces and close all files */
|
|
|
|
SRV_SHUTDOWN_EXIT_THREADS/*!< Exit all threads */
|
|
|
|
};
|
|
|
|
|
MDEV-13039 innodb_fast_shutdown=0 may fail to purge all undo log
When a slow shutdown is performed soon after spawning some work for
background threads that can create or commit transactions, it is possible
that new transactions are started or committed after the purge has finished.
This is violating the specification of innodb_fast_shutdown=0, namely that
the purge must be completed. (None of the history of the recent transactions
would be purged.)
Also, it is possible that the purge threads would exit in slow shutdown
while there exist active transactions, such as recovered incomplete
transactions that are being rolled back. Thus, the slow shutdown could
fail to purge some undo log that becomes purgeable after the transaction
commit or rollback.
srv_undo_sources: A flag that indicates if undo log can be generated
or the persistent, whether by background threads or by user SQL.
Even when this flag is clear, active transactions that already exist
in the system may be committed or rolled back.
innodb_shutdown(): Renamed from innobase_shutdown_for_mysql().
Do not return an error code; the operation never fails.
Clear the srv_undo_sources flag, and also ensure that the background
DROP TABLE queue is empty.
srv_purge_should_exit(): Do not allow the purge to exit if
srv_undo_sources are active or the background DROP TABLE queue is not
empty, or in slow shutdown, if any active transactions exist
(and are being rolled back).
srv_purge_coordinator_thread(): Remove some previous workarounds
for this bug.
innobase_start_or_create_for_mysql(): Set buf_page_cleaner_is_active
and srv_dict_stats_thread_active directly. Set srv_undo_sources before
starting the purge subsystem, to prevent immediate shutdown of the purge.
Create dict_stats_thread and fts_optimize_thread immediately
after setting srv_undo_sources, so that shutdown can use this flag to
determine if these subsystems were started.
dict_stats_shutdown(): Shut down dict_stats_thread. Backported from 10.2.
srv_shutdown_table_bg_threads(): Remove (unused).
2017-06-08 15:43:06 +03:00
|
|
|
/** Whether any undo log records can be generated */
|
|
|
|
extern bool srv_undo_sources;
|
|
|
|
|
2009-05-27 15:15:59 +05:30
|
|
|
/** At a shutdown this value climbs from SRV_SHUTDOWN_NONE to
|
|
|
|
SRV_SHUTDOWN_CLEANUP and then to SRV_SHUTDOWN_LAST_PHASE, and so on */
|
2016-08-12 11:17:45 +03:00
|
|
|
extern enum srv_shutdown_t srv_shutdown_state;
|
MDEV-12548 Initial implementation of Mariabackup for MariaDB 10.2
InnoDB I/O and buffer pool interfaces and the redo log format
have been changed between MariaDB 10.1 and 10.2, and the backup
code has to be adjusted accordingly.
The code has been simplified, and many memory leaks have been fixed.
Instead of the file name xtrabackup_logfile, the file name ib_logfile0
is being used for the copy of the redo log. Unnecessary InnoDB startup and
shutdown and some unnecessary threads have been removed.
Some help was provided by Vladislav Vaintroub.
Parameters have been cleaned up and aligned with those of MariaDB 10.2.
The --dbug option has been added, so that in debug builds,
--dbug=d,ib_log can be specified to enable diagnostic messages
for processing redo log entries.
By default, innodb_doublewrite=OFF, so that --prepare works faster.
If more crash-safety for --prepare is needed, double buffering
can be enabled.
The parameter innodb_log_checksums=OFF can be used to ignore redo log
checksums in --backup.
Some messages have been cleaned up.
Unless --export is specified, Mariabackup will not deal with undo log.
The InnoDB mini-transaction redo log is not only about user-level
transactions; it is actually about mini-transactions. To avoid confusion,
call it the redo log, not transaction log.
We disable any undo log processing in --prepare.
Because MariaDB 10.2 supports indexed virtual columns, the
undo log processing would need to be able to evaluate virtual column
expressions. To reduce the amount of code dependencies, we will not
process any undo log in prepare.
This means that the --export option must be disabled for now.
This also means that the following options are redundant
and have been removed:
xtrabackup --apply-log-only
innobackupex --redo-only
In addition to disabling any undo log processing, we will disable any
further changes to data pages during --prepare, including the change
buffer merge. This means that restoring incremental backups should
reliably work even when change buffering is being used on the server.
Because of this, preparing a backup will not generate any further
redo log, and the redo log file can be safely deleted. (If the
--export option is enabled in the future, it must generate redo log
when processing undo logs and buffered changes.)
In --prepare, we cannot easily know if a partial backup was used,
especially when restoring a series of incremental backups. So, we
simply warn about any missing files, and ignore the redo log for them.
FIXME: Enable the --export option.
FIXME: Improve the handling of the MLOG_INDEX_LOAD record, and write
a test that initiates a backup while an ALGORITHM=INPLACE operation
is creating indexes or rebuilding a table. An error should be detected
when preparing the backup.
FIXME: In --incremental --prepare, xtrabackup_apply_delta() should
ensure that if FSP_SIZE is modified, the file size will be adjusted
accordingly.
2017-06-30 10:49:37 +03:00
|
|
|
|
|
|
|
/** Files comprising the system tablespace */
|
|
|
|
extern pfs_os_file_t files[1000];
|
2009-05-27 15:15:59 +05:30
|
|
|
#endif
|