Re: Error with "Read Backup"

[Mikael Ronström]

Jeff Steele Wrote:
-------------------------------------------------------
> I have some basic questions to help clarify what
> is going on when "READ_BACKUP" is used:
>
> 1) I have two data nodes in one node group with
> NoOfReplicas set to 2. I assumed that this means
> that each node has a full copy of the data. Is
> that correct?

Correct

>
> 2) I assume that "READ_BACKUP" only works if there
> is a full copy of the data stored locally.
> Otherwise, the local sql node will still have to
> go to the other data node to get the data. Is that
> correct?
>

Yep, it goes to the local node and if data is there it
fetches it from there, otherwise it goes to the primary data
node.

> 3) If I am wrong about (1) but right about (2),
> does READ_BACKUP cause the table to be copied so
> that all that table's data is on both nodes?
>

You were right on 1) and 2). READ_BACKUP only affects
which replica is read.

> 4) you identified a discrepancy between my
> NoOfFragmentLogParts and MaxNoOfExecutionThreads
> settings. My data node servers have 12 threads (6
> cores with 2 threads each). Should I set
> MaxNoOfExecutionThreads to 12 or do I need to
> leave cores free for other things (an sql node is
> on the same server)?
>

Usually the MySQL Server consumes more CPU, so should
be sufficient to use MaxNoOfExecutionThreads and thus
use 4 LDM threads. With this setup you should definitely
have NoOfFragmentLogParts set to 4.

> 5) If I leave MaxNoOfExecutionThreads set to 8 as
> it is now, should I change NoOfFragmentLogParts to
> 4?
>

Yep, but problem with that is that this change is decreasing
number of partitions, so this change can only be done as an
offline operation.

> 6) My IndexMemory usage is currently 54% so I
> would have to do an initial restart if I change
> either NoOfFragmentLogParts or
> MaxNoOfExecutionThreads. If I do that, do I simply
> do a rolling restart using "--initial" for each
> ndb_mgmd and ndbmtd? Will my data be safe if I do
> that?
>
> Thanks much for all of your help which has been
> lighting fast and very impressive.

Problem is that your data has now been distributed with
8 log parts and thus 16 partitions per table. There is no online
operation to decrease the number of partitions. There is
only online operations to increase number of partitions.

So not sure how you should handle that, depends on your uptime
requirements and if there are slots where you can bring the
system down.

Fastest way to change is probably to take a backup, change the
configuration followed by initial start and restoring the backup.

ALTER TABLE gives read access while performing the changes. So this
is an alternative as well.

Not changing is also an alternative. The data is not endangered using
too many partitions. It will use more resources to execute scan operations
though which is likely what you saw happen after the change.