ch huang wrote:
> i see the follow text in cluster document:
> http://dev.mysql.com/doc/refman/5.1/en/mysql-cluster-config-lcp-params.html
>
> 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.
>
> i wander if the size of 16-MB can be set to other value,if can ,use which
> variable(i see the FragmentLogFileSize ,is it the right var?).
Yes
> and how can
> i conclude the minimum value is 3?
http://dev.mysql.com/doc/refman/5.1/en/mysql-cluster-ndbd-definition.html
See NoOfFragmentLogFiles entry
> also the redo log hold all LCP data(i use
> 7.0.7 ,so have 2 LCP,and my redo log must hold the 2 LCP data),and in the
> scenario double the redo log size so i calculate the total byte up to
> 11MB,so in config.ini ,is it enough to set FragmentLogFileSize=12M?
Not clear what you're asking here.
If your total data size is 11MB (e.g. DataMemory == 11MB) then double
this would be 22MB. Redo log size is NoOfFragmentLogFiles * 4 *
FragmentLogFileSize.
The default values are :
16 * 4 * 16MB = 1024MB = 1GB
The minimum value of NoOfFragmentLogFiles is 3 and the minimum value of
FragmentLogFileSize is 4MB, so the minimum Redo log file size is :
3 * 4 * 4MB = 48MB
Note that the 2 * LCP data Redo log sizing method is a 'rule of thumb'
unusual configurations may need more (or less) than this. If you have a
very small, but heavily updated database, then you may need more Redo
log than this figure suggests.
> i check
> my config.ini,NoOfFragmentLogFiles=48,is it the value too big for this
> scenario(or just waste disk space)?
Possibly, see above
> and last question is how can i tuning
> the RedoBuffer ,the default value is enough? thanks all
>
RedoBuffer is difficult to tune. I expect the default value is enough.
As with all of these parameters, it is best if you can run your worst
case scenarios (in terms of update rates) and verify that the system
performs as expected.
We are in the process of giving more visibility into the working of the
Redo mechanism within the data nodes. That should help with making
sizing decisions such as these.
Until then it's safest to err on the side of caution, possibly using a
little more disk or memory than is strictly necessary.
--
Frazer Clement, Software Engineer, MySQL Cluster
Sun Microsystems - www.mysql.com
Office: Edinburgh, UK
Are you MySQL certified? www.mysql.com/certification
