[Postgres-xl-developers] 答复: Patch for new initdb parameter nodetype,to ensure datanode has correct node_type 'D'.(Internet mail)

jasonysli(李跃森) jasonysli at tencent.com
Mon Aug 14 19:03:07 PDT 2017


Hi all:
	I think I am supposed to explain why I did this. Before we init a cluster ,we will edit a config file of pgxc_ctl, then we start pgxc_ctl and run clean all;init all;start all. This way , we will get datanode with 'C' type.
And, in our cluster management system, when adding new node, we use initdb to add a new node to the cluster, we hope the step can be tomic. So we hope we can add the parameter of initdb to init a node with specific 
type to cluster.

-----邮件原件-----
发件人: Tomas Vondra [mailto:tomas.vondra at 2ndquadrant.com] 
发送时间: 2017年8月14日 21:31
收件人: Pavan Deolasee
抄送: jasonysli(李跃森); postgres-xl-developers at lists.postgres-xl.org
主题: Re: [Postgres-xl-developers] Patch for new initdb parameter nodetype,to ensure datanode has correct node_type 'D'.(Internet mail)



On 08/14/2017 03:14 PM, Pavan Deolasee wrote:
> 
> 
> On Mon, Aug 14, 2017 at 6:32 PM, Tomas Vondra 
> <tomas.vondra at 2ndquadrant.com <mailto:tomas.vondra at 2ndquadrant.com>> wrote:
> 
>     Hi,
> 
>     On 08/14/2017 11:49 AM, Pavan Deolasee wrote:
> 
> 
> 
> 
> 
>         I am a bit confused too about whether this would be a net
>         positive change. It will definitely break existing scripts that
>         other users
>         might have written and will require changes initdb man page,
>         documentation, examples etc. Also, if we do this then we will also
>         need to add safeguards to ensure that a data directory initialised
>         for a coordinator must not be used for a datanode and vice versa. We
>         might also want to disallow ALTER NODE for node type.
> 
> 
>     I think if we allow/support bootstrapping a cluster from pgxc_ctl,
>     we should end up with a valid cluster metadata in pgxc_node - all
>     nodes having node_type 'C' seems like a bug. I've been unable to
>     reproduce it so far, but I guess I'm doing something differently
>     than Jason.
> 
> 
> AFAIU Jason's point is that initdb always sets node_type as 'C' and 
> that's what he is trying to fix. But he can clarify what is the exact 
> problem. May be there is something that I don't see.
> 

That's how I understand the patch.

> 
>     I'm not sure how this could break existing scripts? Can you give an
>     example? Also, if a script relies on incorrect values in pgxc_node,
>     then perhaps breaking it is a good thing?
> 
> 
> Scripts which do not use pgxc_ctl, but directly call initdb will break 
> because we are adding a new non-optional switch to the command.
> 

Ah, right. I've been thinking about scripts using pgxc_ctl, not about using initdb directly. You're right those scripts will be broken.

> 
>     Not sure I understand the issue with using coordinator datadir for
>     datanode and disabling ALTER NODE. Isn't that an independent issue
>     that we already have to deal with anyway? How does initidb setting
>     datanode instead of coordinator make this worse?
> 
> 
> If we are relying on initdb to set the correct node_type, then I don't 
> see why we should allow altering the type later. It is needed today 
> because initdb puts a kinda dummy value, which is later modified to 
> reflect the role assigned to the node.

I agree with that if we require initdb to set the node type, then we don't need the ALTER NODE (at least not to change the node type).

But I was more asking about the suggestion that we'll need to "add safeguards to ensure that a data directory initialised for a coordinator must not be used for a datanode and vice versa."

Why would that be a new requirement? Presumably we can't do those safeguards now, because initdb creates all nodes as coordinators (so we need to be able to start the node as datanode and change the type).

But that's probably a good thing that we'll be able to add those safeguards, no?

regards

-- 
Tomas Vondra                  http://www.2ndQuadrant.com
PostgreSQL Development, 24x7 Support, Remote DBA, Training & Services



More information about the Postgres-xl-developers mailing list