Oracle 5.0, Справочное руководство

Страница: 1613 / 3232

Overview of MySQL Cluster Configuration Parameters
1593
there are always uncertainties—for instance, we cannot be sure that disks always operate at top speed
or with maximum throughput. For this reason, it is best to err on the side of caution, so we double our
requirement and calculate a number of fragment log files which should be enough to keep records
covering 6 local checkpoints.
It is also important to remember that the disk also handles writes to the REDO log and UNDO
log, so if you find that the amount of data being written to disk as determined by the values of
NoOfDiskPagesToDiskAfterRestartACC
and
NoOfDiskPagesToDiskAfterRestartTUP
is
approaching the amount of disk bandwidth available, you may wish to increase the time between local
checkpoints.
Given 5 minutes (300 seconds) per local checkpoint, this means that we need to support writing log
records at maximum speed for 6 * 300 = 1800 seconds. The size of a REDO log record is 72 bytes
plus 4 bytes per updated column value plus the maximum size of the updated column, and there is one
REDO log record for each table record updated in a transaction, on each node where the data reside.
Using the numbers of operations set out previously in this section, we derive the following:
• 50000 select operations per hour yields 0 log records (and thus 0 bytes), since
SELECT
statements
are not recorded in the REDO log.
• 15000
DELETE
statements per hour is approximately 5 delete operations per second. (Since we wish
to be conservative in our estimate, we round up here and in the following calculations.) No columns
are updated by deletes, so these statements consume only 5 operations * 72 bytes per operation =
360 bytes per second.
• 15000
UPDATE
statements per hour is roughly the same as 5 updates per second. Each update uses
72 bytes, plus 4 bytes per column * 5 columns updated, plus 32 bytes per column * 5 columns—this
works out to 72 + 20 + 160 = 252 bytes per operation, and multiplying this by 5 operation per second
yields 1260 bytes per second.
• 15000
INSERT
statements per hour is equivalent to 5 insert operations per second. Each insert
requires REDO log space of 72 bytes, plus 4 bytes per record * 40 columns, plus 32 bytes per
column * 40 columns, which is 72 + 160 + 1280 = 1512 bytes per operation. This times 5 operations
per second yields 7560 bytes per second.
So the total number of REDO log bytes being written per second is approximately 0 + 360 + 1260 +
7560 = 9180 bytes. Multiplied by 1800 seconds, this yields 16524000 bytes required for REDO logging,
or approximately 15.75 MB. The unit used for
NoOfFragmentLogFiles
represents a set of 4 16-MB
log files—that is, 64 MB. Thus, the minimum value (3) for this parameter is sufficient for the scenario
envisioned in this example, since 3 times 64 = 192 MB, or about 12 times what is required; the default
value of 8 (or 512 MB) is more than ample in this case.
A copy of each altered table record is kept in the UNDO log. In the scenario discussed above, the
UNDO log would not require any more space than what is provided by the default seetings. However,
given the size of disks, it is sensible to allocate at least 1 GB for it.
17.3.3. Overview of MySQL Cluster Configuration Parameters
The next four sections provide summary tables of MySQL Cluster configuration parameters used in
the
config.ini
file to govern the cluster's functioning. Each table lists the parameters for one of the
Cluster node process types (
ndbd
,
ndb_mgmd
, and
mysqld
), and includes the parameter's type as
well as its default, mimimum, and maximum values as applicable.
These tables also indicate what type of restart is required (node restart or system restart)—and
whether the restart must be done with
--initial
—to change the value of a given configuration
parameter.
When performing a node restart or an initial node restart, all of the cluster's data nodes must be
restarted in turn (also referred to as a rolling restart). It is possible to update cluster configuration