Skip to content

M
mariadb
Commit 651095ca authored by serg@serg.mysql.com's avatar serg@serg.mysql.com
Browse files
Options

GEMINI manual removed

parent 59968f3a
Show whitespace changes
Inline Side-by-side
Showing with 18 additions and 903 deletions
Docs/manual.texi
View file @ 651095ca
......@@ -498,7 +498,6 @@ MySQL Table Types
* HEAP:: HEAP tables
* InnoDB:: InnoDB tables
* BDB:: BDB or Berkeley_db tables
* GEMINI:: GEMINI tables
MyISAM Tables
......@@ -573,28 +572,6 @@ BDB or Berkeley_DB Tables
* BDB portability:: Operating systems supported by @strong{BDB}
* BDB errors:: Errors You May Get When Using BDB Tables
GEMINI Tables
* GEMINI Overview::
* Using GEMINI Tables::
GEMINI Overview
* GEMINI Features::
* GEMINI Concepts::
* GEMINI Limitations::
Using GEMINI Tables
* Startup Options::
* Creating GEMINI Tables::
* Backing Up GEMINI Tables::
* Restoring GEMINI Tables::
* Using Auto_Increment Columns With GEMINI Tables::
* Performance Considerations::
* Sample Configurations::
* When To Use GEMINI Tables::
MySQL Tutorial
* Connecting-disconnecting:: Connecting to and disconnecting from the server
......@@ -4232,12 +4209,11 @@ phone back within 48 hours to discuss @code{MySQL} related issues.
@cindex support, BDB Tables
@cindex support, InnoDB Tables
@cindex support, GEMINI Tables
@node Table handler support, , Telephone support, Support
@subsection Support for other table handlers
To get support for @code{BDB} tables, @code{InnoDB} tables or
@code{GEMINI} tables you have to pay an additional 30% on the standard
To get support for @code{BDB} tables or @code{InnoDB} tables
you have to pay an additional 30% on the standard
support price for each of the table handlers you would like to have
support for.
......@@ -10074,8 +10050,8 @@ reload the grant tables.
@cindex server, starting problems
@cindex problems, starting the server
If you are going to use tables that support transactions (BDB, InnoDB or
Gemini), you should first create a my.cnf file and set startup options
If you are going to use tables that support transactions (BDB or InnoDB),
you should first create a my.cnf file and set startup options
for the table types you plan to use. @xref{Table types}.
Generally, you start the @code{mysqld} server in one of three ways:
......@@ -10227,9 +10203,6 @@ options. @xref{InnoDB start}.
If you are using BDB (Berkeley DB) tables, you should familiarize
yourself with the different BDB specific startup options. @xref{BDB start}.
If you are using Gemini tables, refer to the Gemini-specific startup options.
@xref{Using GEMINI Tables}.
@node Automatic start, Command-line options, Starting server, Post-installation
@subsection Starting and Stopping MySQL Automatically
@cindex starting, the server automatically
......@@ -11659,8 +11632,8 @@ concerned about transactions. For them transactions are not an
issue. For those of our users who are concerned with or have wondered
about transactions vis-a-vis @strong{MySQL}, there is a ``@strong{MySQL}
way'' as we have outlined above. For those where safety is more
important than speed, we recommend them to use the @code{BDB},
@code{GEMINI} or @code{InnoDB} tables for all their critical
important than speed, we recommend them to use the @code{BDB}
or @code{InnoDB} tables for all their critical
data. @xref{Table types}.
One final note: We are currently working on a safe replication schema
......@@ -11887,12 +11860,11 @@ Entry level SQL92. ODBC levels 0-2.
@cindex tables, updating
@cindex updating, tables
@cindex @code{BDB} tables
@cindex @code{GEMINI} tables
@cindex @code{InnoDB} tables
The following mostly applies only for @code{ISAM}, @code{MyISAM}, and
@code{HEAP} tables. If you only use transaction-safe tables (@code{BDB},
@code{GEMINI} or @code{InnoDB} tables) in an an update, you can do
@code{HEAP} tables. If you only use transaction-safe tables (@code{BDB}
or @code{InnoDB} tables) in an an update, you can do
@code{COMMIT} and @code{ROLLBACK} also with @strong{MySQL}.
@xref{COMMIT}.
......@@ -19074,7 +19046,7 @@ When you insert a value of @code{NULL} (recommended) or @code{0} into an
If you delete the row containing the maximum value for an
@code{AUTO_INCREMENT} column, the value will be reused with an
@code{ISAM}, @code{GEMINI} or @code{BDB} table but not with a
@code{ISAM} or @code{BDB} table but not with a
@code{MyISAM} or @code{InnoDB} table. If you delete all rows in the table
with @code{DELETE FROM table_name} (without a @code{WHERE}) in
@code{AUTOCOMMIT} mode, the sequence starts over for all table types.
......@@ -19247,7 +19219,6 @@ The different table types are:
@multitable @columnfractions .20 .80
@item BDB or Berkeley_db @tab Transaction-safe tables with page locking. @xref{BDB}.
@item GEMINI @tab Transaction-safe tables with row-level locking @xref{GEMINI}.
@item HEAP @tab The data for this table is only stored in memory. @xref{HEAP}.
@item ISAM @tab The original table handler. @xref{ISAM}.
@item InnoDB @tab Transaction-safe tables with row locking. @xref{InnoDB}.
......@@ -22915,8 +22886,8 @@ By default, @strong{MySQL} runs in @code{autocommit} mode. This means that
as soon as you execute an update, @strong{MySQL} will store the update on
disk.
If you are using transactions safe tables (like @code{BDB},
@code{InnoDB} or @code{GEMINI}), you can put @strong{MySQL} into
If you are using transactions safe tables (like @code{BDB} or
@code{InnoDB}), you can put @strong{MySQL} into
non-@code{autocommit} mode with the following command:
@example
......@@ -23798,7 +23769,6 @@ used them.
@cindex table types, choosing
@cindex @code{BDB} table type
@cindex @code{Berkeley_db} table type
@cindex @code{GEMINI} table type
@cindex @code{HEAP} table type
@cindex @code{ISAM} table type
@cindex @code{InnoDB} table type
......@@ -23811,8 +23781,8 @@ used them.
As of @strong{MySQL} Version 3.23.6, you can choose between three basic
table formats (@code{ISAM}, @code{HEAP} and @code{MyISAM}. Newer
@strong{MySQL} may support additional table type (@code{BDB},
@code{GEMINI} or @code{InnoDB}), depending on how you compile it.
@strong{MySQL} may support additional table type (@code{BDB}
or @code{InnoDB}), depending on how you compile it.
When you create a new table, you can tell @strong{MySQL} which table
type it should use for the table. @strong{MySQL} will always create a
......@@ -23837,8 +23807,8 @@ You can convert tables between different types with the @code{ALTER
TABLE} statement. @xref{ALTER TABLE, , @code{ALTER TABLE}}.
Note that @strong{MySQL} supports two different kinds of
tables. Transaction-safe tables (@code{BDB}, @code{InnoDB} or
@code{GEMINI}) and not transaction-safe tables (@code{HEAP}, @code{ISAM},
tables. Transaction-safe tables (@code{BDB} or @code{InnoDB})
and not transaction-safe tables (@code{HEAP}, @code{ISAM},
@code{MERGE}, and @code{MyISAM}).
Advantages of transaction-safe tables (TST):
......@@ -23880,7 +23850,6 @@ of both worlds.
* HEAP:: HEAP tables
* InnoDB:: InnoDB tables
* BDB:: BDB or Berkeley_db tables
* GEMINI:: GEMINI tables
@end menu
@node MyISAM, MERGE, Table types, Table types
......@@ -25936,7 +25905,7 @@ Finland
@cindex tables, @code{BDB}
@cindex tables, @code{Berkeley DB}
@node BDB, GEMINI, InnoDB, Table types
@node BDB, , InnoDB, Table types
@section BDB or Berkeley_DB Tables
@menu
......@@ -26221,856 +26190,6 @@ not in @code{auto_commit} mode, until this problem is fixed (the fix is
not trivial).
@end itemize
@cindex GEMINI tables
@node GEMINI, , BDB, Table types
@section GEMINI Tables
@cindex GEMINI tables, overview
@menu
* GEMINI Overview::
* Using GEMINI Tables::
@end menu
@node GEMINI Overview, Using GEMINI Tables, GEMINI, GEMINI
@subsection GEMINI Overview
GEMINI is currently not included in the @strong{MySQL} 3.23 distribution
because it's not to our knowledge an open source (GPL) product.
@code{GEMINI} is a transaction-safe table handler for @strong{MySQL}. It
provides row-level locking, robust transaction support and reliable
crash recovery. It is targeted for databases that need to handle heavy
multi-user updates typical of transaction processing applications while
still providing excellent performance for read-intensive operations. The
@code{GEMINI} table type is developed and supported by NuSphere
Corporation (see @url{http://www.nusphere.com}).
@code{GEMINI} provides full ACID transaction properties (Atomic,
Consistent, Independent, and Durable) with a programming model that
includes support for statement atomicity and all four standard isolation
levels (Read Uncommitted, Read Committed, Repeatable Read, and
Serializable) defined in the SQL standard.
The @code{GEMINI} tables support row-level and table-level locking to
increase concurrency in applications and allow reading of tables without
locking for maximum concurrency in a heavy update environment. The
transaction, locking, and recovery mechanisms are tightly integrated to
eliminate unnecessary administration overhead.
In general, if @code{GEMINI} tables are selected for an application, it
is recommended that all tables updated in the application be
@code{GEMINI} tables to provide well-defined system behavior. If
non-@code{GEMINI} tables are mixed into the application then, ACID
transaction properties cannot be maintained. While there are clearly
cases where mixing table types is appropriate, it should always be done
with careful consideration of the impact on transaction consistency and
recoverability needs of the application and underlying database.
The @code{GEMINI} table type is derived from a successful commercial
database and uses the storage kernel technology tightly integrated with
@strong{MySQL} server. The basic @code{GEMINI} technology is in use by
millions of users worldwide in production environments today. This
maturity allows @code{GEMINI} tables to provide a solution for those
users who require transaction-based behavior as part of their
applications.
The @code{GEMINI} table handler supports a configurable data cache that
allows a significant portion of any database to be maintained in memory
while still allowing durable updates.
@cindex GEMINI tables, features
@menu
* GEMINI Features::
* GEMINI Concepts::
* GEMINI Limitations::
@end menu
@node GEMINI Features, GEMINI Concepts, GEMINI Overview, GEMINI Overview
@subsubsection GEMINI Features
The following summarizes the major features provided by @code{GEMINI}
tables.
@itemize @bullet
@item
Supports all optimization statistics used by the @strong{MySQL} optimizer
including table cardinality, index range estimates and multi-component
selectivity to insure optimal query performance.
@item
Maintains exact cardinality information for each table so @code{SELECT
COUNT(*) FROM} table-name always returns an answer immediately.
@item
Supports index-only queries; when index data is sufficient to resolve a
query no record data is read (for non character types).
@item
@code{GEMINI} uses block based I/O for better performance. There is no
performance penalty for using @code{VARCHAR} fields. The maximum record size is
currently 32K.
@item
The number of rows in a single @code{GEMINI} table can be 4 quintillion
(full use of 64 bits).
@item
Individual tables can be as large as 16 petabytes.
@item
Locking is done at a record or row level rather than at table level
unless table locks are explicitly requested. When a row is inserted into
a table, other rows can be updated, inserted or deleted without waiting
for the inserted row to be committed.
@item
Provides durable transactions backed by a crash recovery mechanism that
returns the database to a known consistent state in the event of an
unexpected failure.
@item
Support for all isolation levels and statement atomicity defined in the
SQL standard.
@item
Reliable Master Replication; the master database can survive system
failure and recover all committed transactions.
@end itemize
@cindex GEMINI tables, concepts
@node GEMINI Concepts, GEMINI Limitations, GEMINI Features, GEMINI Overview
@subsubsection GEMINI Concepts
This section highlights some of the important concepts behind
@code{GEMINI} and the @code{GEMINI} programming model, including:
@itemize @bullet
@item
ACID Transactions
@item
Transaction COMMIT/ROLLBACK
@item
Statement Atomicity
@item
Recovery
@item
Isolation Levels
@item
Row-Level Locking
@end itemize
These features are described below.
@cindex GEMINI tables, ACID transactions
@noindent
@strong{ACID Transactions}
ACID in the context of transactions is an acronym which stands for
@emph{Atomicity}, @emph{Consistency}, @emph{Isolation}, @emph{Durability}.
@multitable @columnfractions .25 .75
@item @sc{Attribute} @tab @sc{Description}
@item
@strong{Atomicity}
@tab A transaction allows for the grouping of one or more changes to
tables and rows in the database to form an atomic or indivisible
operation. That is, either all of the changes occur or none of them
do. If for any reason the transaction cannot be completed, everything
this transaction changed can be restored to the state it was in prior to
the start of the transaction via a rollback operation.
@item
@strong{Consistency}
@tab
Transactions always operate on a consistent view of the data and when
they end always leave the data in a consistent state. Data may be said to
be consistent as long as it conforms to a set of invariants, such as no
two rows in the customer table have the same customer ID and all orders
have an associated customer row. While a transaction executes, these
invariants may be violated, but no other transaction will be allowed to
see these inconsistencies, and all such inconsistencies will have been
eliminated by the time the transaction ends.
@item
@strong{Isolation}
@tab To a given transaction, it should appear as though it is running
all by itself on the database. The effects of concurrently running
transactions are invisible to this transaction, and the effects of this
transaction are invisible to others until the transaction is committed.
@item
@strong{Durability}
@tab Once a transaction is committed, its effects are guaranteed to
persist even in the event of subsequent system failures. Until the
transaction commits, not only are any changes made by that transaction
not durable, but are guaranteed not to persist in the face of a system
failures, as crash recovery will rollback their effects.
@end multitable
@cindex GEMINI tables, COMMIT/ROLLBACK
@noindent
@strong{Transaction COMMIT/ROLLBACK}
As stated above, a transaction is a group of work being done to
data. Unless otherwise directed, @strong{MySQL} considers each statement
a transaction in itself. Multiple updates can be accomplished by placing
them in a single statement, however they are limited to a single table.
Applications tend to require more robust use of transaction
concepts. Take, for example, a system that processes an order: A row may
be inserted in an order table, additional rows may be added to an
order-line table, updates may be made to inventory tables, etc. It is
important that if the order completes, all the changes are made to all
the tables involved; likewise if the order fails, none of the changes to
the tables must occur. To facilitate this requirement, @strong{MySQL}
has syntax to start a transaction called @code{BEGIN WORK}. All
statements that occur after the @code{BEGIN WORK} statement are grouped
into a single transaction. The end of this transaction occurs when a
@code{COMMIT} or @code{ROLLBACK} statement is encountered. After the
@code{COMMIT} or @code{ROLLBACK} the system returns back to the behavior
before the @code{BEGIN WORK} statement was encountered where every
statement is a transaction.
To permanently turn off the behavior where every statement is a
transaction, @strong{MySQL} added a variable called
@code{AUTOCOMMIT}. The @code{AUTOCOMMIT} variable can have two values,
@code{1} and @code{0}. The mode where every statement is a transaction
is when @code{AUTOCOMMIT} is set to @code{1} (@code{AUTOCOMMIT=1}). When
@code{AUTOCOMMIT} is set to @code{0} (@code{AUTOCOMMIT=0}), then every
statement is part of the same transaction until the transaction end by
either @code{COMMIT} or @code{ROLLBACK}. Once a transaction completes, a
new transaction is immediately started and the process repeats.
Here is an example of the SQL statements that you may find in a typical
order:
@example
BEGIN WORK;
INSERT INTO order VALUES ...;
INSERT INTO order-lines VALUES ...;
INSERT INTO order-lines VALUES ...;
INSERT INTO order-lines VALUES ...;
UPDATE inventory WHERE ...;
COMMIT;
@end example
This example shows how to use the @code{BEGIN WORK} statement to start a
transaction. If the variable @code{AUTOCOMMIT} is set to @code{0}, then
a transaction would have been started already. In this case, the
@code{BEGIN WORK} commits the current transaction and starts a new one.
@cindex GEMINI tables, statement atomicity
@noindent
@strong{Statement Atomicity}
As mentioned above, when running with @code{AUTOCOMMIT} set to @code{1},
each statement executes as a single transaction. When a statement has an
error, then all changes make by the statement must be
undone. Transactions support this behavior. Non-transaction safe table
handlers would have a partial statement update where some of the changes
from the statement would be contained in the database and other changes
from the statement would not. Work would need to be done to manually
recover from the error.
@cindex GEMINI tables, recovery
@noindent
@strong{Recovery}
Transactions are the basis for database recovery. Recovery is what
supports the Durability attribute of the ACID transaction.
@code{GEMINI} uses a separate file called the Recovery Log located in
the @code{$DATADIR} directory named @code{gemini.rl}. This file
maintains the integrity of all the @code{GEMINI} tables. @code{GEMINI}
can not recover any data from non-@code{GEMINI} tables. In addition, the
@code{gemini.rl} file is used to rollback transactions in support of the
@code{ROLLBACK} statement.
In the event of a system failure, the next time the @strong{MySQL}
server is started, @code{GEMINI} will automatically go through its
crash recovery process. The result of crash recovery is that all the
@code{GEMINI} tables will contain the latest changes made to them, and
all transactions that were open at the time of the crash will have been
rolled back.
The @code{GEMINI} Recovery Log reuses space when it can. Space can be
reused when information in the Recovery Log is no longer needed for
crash recovery or rollback.
@cindex GEMINI tables, isolation levels
@noindent
@strong{Isolation Levels}
There are four isolation levels supported by @code{GEMINI}:
@itemize @bullet
@item
READ UNCOMMITTED
@item
READ COMMITTED
@item
REPEATABLE READ
@item
SERIALIZABLE
@end itemize
These isolation levels apply only to shared locks obtained by select
statements, excluding select for update. Statements that get exclusive
locks always retain those locks until the transaction commits or rolls
back.
By default, @code{GEMINI} operates at the @code{READ COMMITTED}
level. You can override the default using the following command:
@example
SET [GLOBAL | SESSION] TRANSACTION ISOLATION LEVEL [READ UNCOMMITTED |
READ COMMITTED | REPEATABLE READ | SERIALIZABLE ]
@end example
If the @code{SESSION} qualifier used, the specified isolation level
persists for the entire session. If the @code{GLOBAL} qualifier is used,
the specified isolation level is applied to all new connections from
this point forward. Note that the specified isolation level will not
change the behavior for existing connections including the connection
that exectues the @code{SET GLOBAL TRANSACTION ISOLATION LEVEL}
statement.
@multitable @columnfractions .30 .70
@item @sc{Isolation Level} @tab @sc{Description}
@item
@strong{READ UNCOMMITTED}
@tab Does not obtain any locks when reading rows. This means that if a
row is locked by another process in a transaction that has a more strict
isolation level, the @code{READ UNCOMMITTED} query will not wait until
the locks are released before reading the row. You will get an error if
attempt any updates while running at this isolation level.
@item
@strong{READ COMMITTED}
@tab Locks the requested rows long enough to copy the row from the
database block to the client row buffer. If a @code{READ COMMITTED}
query finds that a row is locked exclusively by another process, it will
wait until either the row has been released, or the lock timeout value
has expired.
@item
@strong{REPEATABLE READ}
@tab Locks all the rows needed to satisfy the query. These locks are
held until the transaction ends (commits or rolls back). If a
@code{REPEATABLE READ} query finds that a row is locked exclusively by
another process, it will wait until either the row has been released, or
the lock timeout value has expired.
@item
@strong{SERIALIZABLE}
@tab Locks the table that contains the rows needed to satisfy the
query. This lock is held until the transaction ends (commits or rolls
back). If a @code{SERIALIZABLE} query finds that a row is exclusively
locked by another process, it will wait until either the row has been
released, or the lock timeout value has expired.
@end multitable
The statements that get exclusive locks are @code{INSERT},
@code{UPDATE}, @code{DELETE} and @code{SELECT ... FOR UPDATE}. Select
statements without the @code{FOR UPDATE} qualifier get shared locks
which allow other not ''for update'' select statements to read the same
rows but block anyone trying to update the row from accessing it. Rows
or tables with exclusive locks block all access to the row from other
transactions until the transaction ends.
In general terms, the higher the Isolation level the more likelihood of
having concurrent locks and therefore lock conflicts. In such cases,
adjust the @code{-O gemini_lock_table_size} accordingly.
@cindex GEMINI tables, row-level locking
@noindent
@strong{Row-Level Locking}
@code{GEMINI} uses row locks, which allows high concurrency for requests
on the same table.
In order to avoid lock table overflow, SQL statements that require
applying locks to a large number of rows should either be run at the
serializable isolation level or should be covered by a lock table
statement.
Memory must be pre-allocated for the lock table. The mysqld server
startup option @code{-0 gemini_lock_table_size} can be used to adjust
the number of concurrent locks.
@cindex GEMINI tables, limitations
@node GEMINI Limitations, , GEMINI Concepts, GEMINI Overview
@subsubsection GEMINI Limitations
The following limitations are in effect for the current version of
@code{GEMINI}:
@itemize @bullet
@item
@code{DROP DATABASE} does not work with @code{GEMINI} tables; instead,
drop all the tables in the database first, then drop the database.
@item
Maximum number of @code{GEMINI} tables is 1012.
@item
Maximum number of @code{GEMINI} files a server can manage is 1012. Each
table consumes one file; an additional file is consumed if the table has
any indexes defined on it.
@item
Maximum size of BLOBs is 16MB.
@item
@code{FULLTEXT} indexes are not supported with @code{GEMINI} tables.
@item
There is no support for multi-component @code{AUTO_INCREMENT} fields
that provide alternating values at the component level. If you try to
create such a field, @code{GEMINI} will refuse.
@item
@code{TEMPORARY TABLES} are not supported by @code{GEMINI}. The
statement @code{CREATE TEMPORARY TABLE ... TYPE=GEMINI} will generate
the response: @code{ERROR 1005: Can't create table '/tmp/#sqlxxxxx'
(errno: 0)}.
@item
@code{FLUSH TABLES} has not been implemented with @code{GEMINI} tables.
@end itemize
@cindex GEMINI tables, using
@node Using GEMINI Tables, , GEMINI Overview, GEMINI
@subsection Using GEMINI Tables
This section explains the various startup options you can use with
@code{GEMINI} tables, how to backup @code{GEMINI} tables, some
performance considerations and sample configurations, and a brief
discussion of when to use @code{GEMINI} tables.
Specifically, the topics covered in this section are:
@itemize @bullet
@item
Startup Options
@item
Creating @code{GEMINI} Tables
@item
Backing Up @code{GEMINI} Tables
@item
Using Auto_Increment Columns With @code{GEMINI} Tables
@item
Performance Considerations
@item
Sample Configurations
@item
When To Use @code{GEMINI} Tables
@end itemize
@cindex GEMINI tables, startup options
@menu
* Startup Options::
* Creating GEMINI Tables::
* Backing Up GEMINI Tables::
* Restoring GEMINI Tables::
* Using Auto_Increment Columns With GEMINI Tables::
* Performance Considerations::
* Sample Configurations::
* When To Use GEMINI Tables::
@end menu
@node Startup Options, Creating GEMINI Tables, Using GEMINI Tables, Using GEMINI Tables
@subsubsection Startup Options
The table below lists options to mysqld that can be used to change the
behavior of @code{GEMINI} tables.
@multitable @columnfractions .40 .60
@item @sc{Option} @tab @sc{Description}
@item
@code{--default-table-type=gemini}
@tab Sets the default table handler to be @code{GEMINI}. All create
table statements will create @code{GEMINI} tables unless otherwise
specified with @code{TYPE=@var{table-type}}. As noted above, there is
currently a limitation with @code{TEMPORARY} tables using @code{GEMINI}.
@item
@code{--gemini-flush-log-at-commit}
@tab Forces the recovery log buffers to be flushed after every
commit. This can have a serious performance penalty, so use with
caution.
@item
@code{--gemini-recovery=FULL | NONE | FORCE}
@tab Sets the recovery mode. Default is @code{FULL}. @code{NONE} is
useful for performing repeatable batch operations because the updates
are not recorded in the recovery log. @code{FORCE} skips crash recovery
upon startup; this corrupts the database, and should be used in
emergencies only.
@item
@code{--gemini-unbuffered-io}
@tab All database writes bypass the OS cache. This can provide a
performance boost on heavily updated systems where most of the dataset
being worked on is cached in memory with the @code{gemini_buffer_cache}
parameter.
@item
@code{--O gemini_buffer_cache=size}
@tab Amount of memory to allocate for database buffers, including Index
and Record information. It is recommended that this number be 10% of the
total size of all @code{GEMINI} tables. Do not exceed amount of memory
on the system!
@item
@code{--O gemini_connection_limit=#}
@tab Maximum number of connections to @code{GEMINI}; default is
@code{100}. Each connection consumes about 1K of memory.
@item
@code{--O gemini_io_threads=#}
@tab Number of background I/O threads; default is @code{2}. Increase the
number when using @code{--gemini-unbuffered-io}
@item
@code{--O gemini_lock_table_size=#}
@tab Sets the maximum number of concurrent locks; default is 4096. Using
@code{SET [ GLOBAL | SESSION ] TRANSACTION ISOLATION = ...} will
determine how long a program will hold row locks.
@item
@code{--O gemini_lock_wait_timeout=seconds}
@tab Number of seconds to wait for record locks when performing queries;
default is 10 seconds. Using @code{SET [ GLOBAL | SESSION ] TRANSACTION
ISOLATION = ...} will determine how long a program will hold row locks.
@item
@code{--skip-gemini}
@tab Do not use @code{GEMINI}. If you use @code{--skip-gemini}, @strong{MySQL}
will not initialize the @code{GEMINI} table handler, saving memory; you
cannot use @code{GEMINI} tables if you use @code{--skip-gemini}.
@item
@code{--transaction-isolation=READ-UNCOMMITTED | READ-COMMITTED | REPEATABLE-READ | SERIALIZABLE}
@tab Sets the GLOBAL transaction isolation level for all users that
connect to the server; can be overridden with the SET ISOLATION LEVEL
statement.
@end multitable
@cindex GEMINI tables, creating
@node Creating GEMINI Tables, Backing Up GEMINI Tables, Startup Options, Using GEMINI Tables
@subsubsection Creating GEMINI Tables
@code{GEMINI} tables can be created by either using the @code{CREATE
TABLE} syntax or the @code{ALTER TABLE} syntax.
@itemize @bullet
@item
The syntax for creating a @code{GEMINI} table is:
@example
CREATE TABLE @var{table-name} (....) TYPE=GEMINI;
@end example
@item
The syntax to convert a table to @code{GEMINI} is:
@example
ALTER TABLE @var{table-name} TYPE=GEMINI;
@end example
@end itemize
@xref{Tutorial}, for more information on how to create and use
@code{MySQL} tables.
@cindex GEMINI tables, backing up
@node Backing Up GEMINI Tables, Restoring GEMINI Tables, Creating GEMINI Tables, Using GEMINI Tables
@subsubsection Backing Up GEMINI Tables
@code{GEMINI} supports both @code{BACKUP TABLE} and @code{RESTORE TABLE}
syntax. To learn more about how to use @code{BACKUP} and @code{RESTORE},
see @ref{BACKUP TABLE} and @ref{RESTORE TABLE}.
To backup @code{GEMINI} tables outside of the @code{MySQL} environment,
you must first shut down the @code{MySQL} server. Once the server is
shut down, you can copy the files associated with @code{GEMINI} to a
different location. The files that make up the @code{GEMINI} table
handler are:
@itemize @bullet
@item
All files associated with a table with a @code{.gmd} extention below the
@code{$DATADIR} directory. Such files include @code{@var{table}.gmd},
@code{@var{table}.gmi}, and @code{@var{table}.frm}
@item
@code{gemini.db} in the @code{$DATADIR} directory
@item
@code{gemini.rl} in the @code{$DATADIR} directory
@item
@code{gemini.lg} in the @code{$DATADIR} directory
@end itemize
All the @code{GEMINI} files must be copied together. You can not copy
just the @code{.gmi} and @code{.gmd} files to a different
@code{$DATADIR} and have them become part of a new database. You can
copy an entire @code{$DATADIR} directory to another location and start a
@strong{MySQL} server using the new @code{$DATADIR}.
@cindex GEMINI tables, restoring
@node Restoring GEMINI Tables, Using Auto_Increment Columns With GEMINI Tables, Backing Up GEMINI Tables, Using GEMINI Tables
@subsubsection Restoring GEMINI Tables
To restore @code{GEMINI} tables outside of the @code{MySQL} environment,
you must first shut down the @code{MySQL} server. Once the server is
shut down, you can remove all @code{GEMINI} files in the target
@code{$DATADIR} and then copy the files previously backed up into the
@code{$DATADIR} directory.
As mentioned above, the files that make up the @code{GEMINI} table
handler are:
@itemize @bullet
@item
All files associated with a table with a @code{.gmd} extention below the
@code{$DATADIR} directory. Such files include @code{@var{table}.gmd},
@code{@var{table}.gmi}, and @code{@var{table}.frm}
@item
@code{gemini.db} in the @code{$DATADIR} directory
@item
@code{gemini.rl} in the @code{$DATADIR} directory
@item
@code{gemini.lg} in the @code{$DATADIR} directory
@end itemize
When restoring a table, all the @code{GEMINI} files must be copied
together. You can not restore just the @code{.gmi} and @code{.gmd}
files.
@cindex GEMINI tables, auto_increment
@node Using Auto_Increment Columns With GEMINI Tables, Performance Considerations, Restoring GEMINI Tables, Using GEMINI Tables
@subsubsection Using Auto_Increment Columns With GEMINI Tables
As mentioned previously, @code{GEMINI} tables support row-level and
table-level locking to increase concurrency in applications and to allow
reading of tables without locking for maximum concurrency in heavy
update environments. This feature has several implications when working
with @code{auto_increment} tables.
In @code{MySQL}, when a column is defined as an @code{auto_increment}
column, and a row is inserted into the table with a @code{NULL} for the
column, the @code{auto_increment} column is updated to be 1 higher than
the highest value in the column.
With @code{MyISAM} tables, the @code{auto_increment} function is
implemented by looking in the index and finding the highest value and
adding 1 to it. This is possible because the entire @code{ISAM} table is
locked during the update period and the increment value is therefore
guaranteed to not be changing.
With @code{GEMINI} tables, the @code{auto_increment} function is
implemented by maintaining a counter in a separate location from the
table data. Instead of looking at the highest value in the table index,
@code{GEMINI} tables look at this separately maintained counter. This
means that in a transactional model, unlike the bottleneck inherent in
the @code{MyISAM} approach, @code{GEMINI} users do @b{not} have to wait
until the transaction that added the last value either commits or
rollbacks before looking at the value.
Two side-effects of the @code{GEMINI} implementation are:
@itemize @bullet
@item
If an insert is done where the column with the @code{auto_increment} is
specified, and this specified value is the highest value, @code{MyISAM}
uses it as its @code{auto_increment} value, and every subsequent insert
is based on this. By contrast, @code{GEMINI} does not use this value,
but instead uses the value maintained in the separate @code{GEMINI}
counter location.
@item
To set the counter to a specific value, you can use @code{SET
insert_id=#} and insert a new row in the table. However, as a general
rule, values should not be inserted into an @code{auto_increment}
column; the database manager should be maintaining this field, not the
application. @code{SET insert_id} is a recovery mechanism that should be
used in case of error only.
@end itemize
Note that if you delete the row containing the maximum value for an
@code{auto_increment} column, the value will be reused with a
@code{GEMINI} table but not with a @code{MyISAM} table.
See @ref{CREATE TABLE} for more information about creating
@code{auto_increment} columns.
@cindex GEMINI tables, peformance considerations
@node Performance Considerations, Sample Configurations, Using Auto_Increment Columns With GEMINI Tables, Using GEMINI Tables
@subsubsection Performance Considerations
In addition to designing the best possible application, configuration of
the data and the server startup parameters need to be considered. How
the hardware is being used can have a dramatic affect on how fast the
system will respond to queries. Disk Drives and Memory must both be
considered.
@noindent
@strong{Disk Drives}
For best performance, you want to spread the data out over as many disks
as possible. Using RAID 10 stripes work very well. If there are a lot of
updates then the recovery log (@code{gemini.rl}) should be on a
relatively quiet disk drive.
To spread the data out without using RAID 10, you can do the following:
@itemize @bullet
@item
Group all the tables into three categories: Heavy Use, Moderate Use,
Light Use.
@item
Take the number of disk drives available and use a round-robin approach
to the three categories grouping the tables on a disk drive. The result
will be an equal distribution of Heavy/Moderate/Light tables assigned to
each disk drive.
@item
Once the tables have been converted to @code{GEMINI} by using the
@code{ALTER TABLE <name> TYPE=GEMINI} statements, move (@code{mv}) the
@code{.gmd} and @code{.gmi} files to a different disk drive and link
(@code{ln -s}) them back to the original directory where the @code{.frm}
file resides.
@item
Finally, move the @code{gemini.rl} file to its quiet disk location and link
the file back to the @code{$DATADIR} directory.
@end itemize
@noindent
@strong{Memory}
The more data that can be placed in memory the faster the access to the
data. Figure out how large the @code{GEMINI} data is by adding up the
@code{.gmd} and @code{.gmi} file sizes. If you can, put at least 10% of
the data into memory. You allocate memory for the rows and indexes by
using the @code{gemini_buffer_cache} startup parameter. For example:
@example
mysqld -O gemini_buffer_cache=800M
@end example
@noindent
would allocate 800 MB of memory for the @code{GEMINI} buffer cache.
@cindex GEMINI tables, sample configurations
@node Sample Configurations, When To Use GEMINI Tables, Performance Considerations, Using GEMINI Tables
@subsubsection Sample Configurations
Based on the performance considerations above, we can look at some
examples for how to get the best performance out of the system when
using @code{GEMINI} tables.
@multitable @columnfractions .30 .70
@item @sc{Hardware} @tab @sc{Configuration}
@item
One CPU, 128MB memory, one disk drive
@tab Allocate 80MB of memory for reading and updating @code{GEMINI}
tables by starting the mysqld server with the following option:
@example
-O gemini_buffer_cache=80M
@end example
@item
Two CPUs, 512MB memory, four disk drives
@tab Use RAID 10 to stripe the data across all available disks, or use
the method described in the performance considerations section,
above. Allocate 450MB of memory for reading/updating @code{GEMINI}
tables:
@example
-O gemini_buffer_cache=450M
@end example
@end multitable
@cindex GEMINI tables, when to use
@node When To Use GEMINI Tables, , Sample Configurations, Using GEMINI Tables
@subsubsection When To Use GEMINI Tables
Because the @code{GEMINI} table handler provides crash recovery and
transaction support, there is extra overhead that is not found in other
non-transaction safe table handlers. Here are some general guidelines
for when to employ @code{GEMINI} and when to use other non-transaction
safe tables (@code{NTST}).
Note that in the following table, you could instead of GEMINI use
InnoDB or BDB tables.
@multitable @columnfractions .30 .25 .45
@item
@sc{Access Trends} @tab @sc{Table Type} @tab @sc{Reason}
@item
Read-only
@tab @code{NTST}
@tab Less overhead and faster
@item
Critical data
@tab @code{GEMINI}
@tab Crash recovery protection
@item
High concurrency
@tab @code{GEMINI}
@tab Row-level locking
@item
Heavy update
@tab @code{GEMINI}
@tab Row-level locking
@end multitable
The table below shows how a typical application schema could be defined.
@multitable @columnfractions .15 .30 .25 .30
@item
@sc{Table} @tab @sc{Contents} @tab @sc{Table Type} @tab @sc{Reason}
@item
account
@tab Customer account data
@tab @code{GEMINI}
@tab Critical data, heavy update
@item
order
@tab Orders for a customer
@tab @code{GEMINI}
@tab Critical data, heavy update
@item
orderline
@tab Orderline detail for an order
@tab @code{GEMINI}
@tab Critical data, heavy update
@item
invdesc
@tab Inventory description
@tab @code{NTST}
@tab Read-only, frequent access
@item
salesrep
@tab Sales rep information
@tab @code{NTST}
@tab Infrequent update
@item
inventory
@tab Inventory information
@tab @code{GEMINI}
@tab High concurrency, critical data
@item
config
@tab System configuration
@tab @code{NTST}
@tab Read-only
@end multitable
@cindex tutorial
@cindex terminal monitor, defined
@cindex monitor, terminal
......@@ -44039,8 +43158,8 @@ included in the source.
applications that need all speed they can get. The tables may be memory
based,@code{HEAP} tables or disk based @code{MyISAM}. @xref{Table types}.
@item
@strong{MySQL} has support for 3 different table handles that support
transactions (@code{BDB}, @code{InnoDB} and @code{Gemini}. Because
@strong{MySQL} has support for 2 different table handles that support
transactions (@code{BDB} and @code{InnoDB}}. Because
every transaction engine performs differently under different
conditions, this gives the application writer more options to find an
optimal solution for his/her setup. @xref{Table types}.
......@@ -46584,10 +45703,6 @@ transaction-safe tables.
@item @strong{InnoDB}
A transaction-safe table handler that supports row level locking, and many
Oracle-like features.
@c change "three" to "four" above when uncommenting this
@c @item Gemini
@c A transaction-safe, row-level locking table handler that supports many
@c features required in a mission-critical environment.
@end table
Note that only MyISAM is available in the standard binary distribution.
Markdown is supported
0% or
You are about to add 0 people to the discussion. Proceed with caution.
Finish editing this message first!
Please register or to comment
GitLab Nexedi Edition | About GitLab | About Nexedi | 沪ICP备2021021310号-2 | 沪ICP备2021021310号-7