Received: from malur.postgresql.org ([217.196.149.56]) by arkaria.postgresql.org with esmtps (TLS1.3) tls TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384 (Exim 4.94.2) (envelope-from ) id 1s4Ii2-002alz-0X for pgsql-novice@arkaria.postgresql.org; Tue, 07 May 2024 11:10:09 +0000 Received: from localhost ([127.0.0.1] helo=malur.postgresql.org) by malur.postgresql.org with esmtp (Exim 4.94.2) (envelope-from ) id 1s4Ihx-002EMq-PQ for pgsql-novice@arkaria.postgresql.org; Tue, 07 May 2024 11:10:06 +0000 Received: from makus.postgresql.org ([2001:4800:3e1:1::229]) by malur.postgresql.org with esmtps (TLS1.3) tls TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384 (Exim 4.94.2) (envelope-from ) id 1s4CPy-000Y6u-NS; Tue, 07 May 2024 04:27:07 +0000 Received: from mail-oo1-xc2d.google.com ([2607:f8b0:4864:20::c2d]) by makus.postgresql.org with esmtps (TLS1.3) tls TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256 (Exim 4.94.2) (envelope-from ) id 1s4CPu-001oyH-Qm; Tue, 07 May 2024 04:27:05 +0000 Received: by mail-oo1-xc2d.google.com with SMTP id 006d021491bc7-5acf5c1a2f5so1652294eaf.0; Mon, 06 May 2024 21:27:02 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20230601; t=1715056022; x=1715660822; darn=lists.postgresql.org; h=cc:to:subject:message-id:date:from:in-reply-to:references :mime-version:from:to:cc:subject:date:message-id:reply-to; bh=Q1eN54SIEO6fV8hEUT+Gcvg9m6M1f7sElqtswUzzMwE=; b=HaSlSjRj+mtwV0bZt7GUWKR4peMtXOY8ItziLf9L1bZpHSUmp2XCjxRQEI36MwpT9E MBUeuKDr1HxuLCYdIuS445amtG+YCVHUNFDgvUGRsIOk/ct43SIgIMfc30fA3JePgrAT L157/uvwq+i5ljIPFCJPAKVdNRt0qzrK9oQe9r1rn5R2WBe3go9m8Mvjhww+eUwMByXp dy6tMnsXJTtT6Hz+AlFfq3yyhntZUlNsxjNXEzJ69VUz3p4jsKuxZe6QdwEbYUmikgIq UUwbyDvp2eZ67deqso1tBF+wbz07sxRx6vp/hpeWpMqappcLDmJmSanQB8qHY+w6EpC3 E2iw== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20230601; t=1715056022; x=1715660822; h=cc:to:subject:message-id:date:from:in-reply-to:references :mime-version:x-gm-message-state:from:to:cc:subject:date:message-id :reply-to; bh=Q1eN54SIEO6fV8hEUT+Gcvg9m6M1f7sElqtswUzzMwE=; b=Aohnc+hh0/6Wza7fjDgDcZaFVd5BGhR5o1X5aFrbcuLaoMm3hHlHXAysfjiJVv443Z ryMf5+xkNph221BZ2UrRGa1ibphvMmQhLusEl/gKy6xQWiW/3rhyHWov30lkPGySBt2R bBmVCXzEhYdn2GIg38iu/FZgaARKMDqberB+B6DODupK+Gn/dSwANboyox09fd9HLvY+ Q0OmXcbQdrmppWgifkto5ONoTav6l+tVHg7loJvgUHQEHkalfyuYNETi1cm69zTUMuoc CATgLrB5Of8H1ExKLYsv1dlKaURJisxDuPL1GAqdShiLu7HI6Q431taHBarRS29aowRN IRXg== X-Forwarded-Encrypted: i=1; AJvYcCV0QkA/mIO8g3FJby6KSYkuqKozaCDRnlU7i814O9BDDh/z7H1/L8ayd86IGWf02NdypUohJOX+HFiJqd1KHBf4ljkXkdv0rleP39+rhrQ= X-Gm-Message-State: AOJu0YxKCAT38piKg6WryEW8BGIZsm2817GgGMRwa8Xcb30G90LHLryQ 5EznLxxnjgIWaSl+FeKsJFv1wJsEeuW1IBdLQUeYKPIWE6U+njvEbPHhP2H/CXOvgKw32H6KGKY wcVxGe8VjkMT4feXWpmd2lfGFe8/OF33RBBmTHg== X-Google-Smtp-Source: AGHT+IGv0/kud358zVHQ+AxUaF4JoU0yxxkVb1quKBU8vM+VZF+pkAruyARidg/LmvC5xl0goxTGlX7701lyuXD7J7I= X-Received: by 2002:a05:6358:340b:b0:18f:42fe:267f with SMTP id h11-20020a056358340b00b0018f42fe267fmr14310845rwd.8.1715056022023; Mon, 06 May 2024 21:27:02 -0700 (PDT) MIME-Version: 1.0 References: <03caa4a3b0daf352e53e99212baa9c012cd744f2.camel@lists.simkin.ca> In-Reply-To: <03caa4a3b0daf352e53e99212baa9c012cd744f2.camel@lists.simkin.ca> From: first last Date: Tue, 7 May 2024 09:56:50 +0530 Message-ID: Subject: Re: Access a Postgres storage with two independent instances To: Alan Hodgson Cc: pgsql-novice@lists.postgresql.org, pgsql-sql@lists.postgresql.org Content-Type: multipart/alternative; boundary="000000000000f675e10617d5988c" List-Id: List-Help: List-Subscribe: List-Post: List-Owner: List-Archive: Archived-At: Precedence: bulk --000000000000f675e10617d5988c Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable Actually what I want is multiple Postgres instances to have read and write access to the same data storage directory. Anyway, that can not be possible as what you say. But, when I deploy MySQL/MongoDB deployment with multiple replicas to access the same storage, the all pods except one become CrashLoopBackOff state. This is happening for MySQL/Mongo. When it comes to Postgres, I deployed it with multiple pods, all the pods became healthy and there is no such CrashLoopBackOff state occurred. But those pods access different storages for every pod. Why this totally different from MySQL and Mongo? On Tue, May 7, 2024 at 2:34=E2=80=AFAM Alan Hodgson wrote: > On Tue, 2024-05-07 at 00:47 +0530, first last wrote: > > I tried to deploy Postgres deployment with Kubernetes, having three > replicas that are accessing the same storage(PVC). Here is the configurat= ion > . Anyway, it can not use single storage( > https://stackoverflow.com/questions/78436945/access-a-mysql-storage-with-= two-independent-instances > ). > > Finally, my question is, why the scenario is different for MySQL and > Postgres? Could you please help me to figure out the issue? This is for = my > Final year project testing Kubernetes using fuzzing. > > > Not sure what you're trying to accomplish, but PostgreSQL can definitely > not share storage between active postmasters. Nor can MySQL, afaik. > On Tue, May 7, 2024 at 2:34=E2=80=AFAM Alan Hodgson wrote: > On Tue, 2024-05-07 at 00:47 +0530, first last wrote: > > I tried to deploy Postgres deployment with Kubernetes, having three > replicas that are accessing the same storage(PVC). Here is the configurat= ion > . Anyway, it can not use single storage( > https://stackoverflow.com/questions/78436945/access-a-mysql-storage-with-= two-independent-instances > ). > > Finally, my question is, why the scenario is different for MySQL and > Postgres? Could you please help me to figure out the issue? This is for = my > Final year project testing Kubernetes using fuzzing. > > > Not sure what you're trying to accomplish, but PostgreSQL can definitely > not share storage between active postmasters. Nor can MySQL, afaik. > --000000000000f675e10617d5988c Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
Actually what I want is=C2=A0multiple Postgres=C2=A0instances to have read and w= rite access to the same data storage directory. Anyway, that can not be pos= sible as what you=C2=A0say. But, when I deploy MySQL/MongoDB deployment wit= h multiple replicas to access the same storage, the all pods except one bec= ome=C2=A0CrashLoopBackOff= =C2=A0state. This is happening for MySQ= L/Mongo. When it comes to Postgres, I deployed it with multiple pods, all t= he pods became healthy and there is no such=C2=A0CrashLoopBackOff state occurred. But those pods access dif= ferent storages for every pod. Why this totally different from MySQL and Mo= ngo?

On Tue, May 7, 2024 at 2:34=E2=80=AFAM Alan Hodgson <ahodgson@lists.simkin.ca> wrote= :
On Tue, 2024-05-07 at 00:47 +0530, first last wrote:
I=C2=A0tried to deploy Postgr= es deployment with Kubernetes, having three replicas that are accessing the= same storage(PVC). Here is the configuration

Finally, my ques= tion is, why the scenario is different for MySQL and Postgres?=C2=A0 Could = you please help me to figure out=C2=A0the issue? This is for my Final year = project testing Kubernetes using fuzzing.

=
Not sure what you're trying to accomplish, but PostgreSQ= L can definitely not share storage between active postmasters. Nor can MySQ= L, afaik.

On Tue, May 7, 2024 at 2:34= =E2=80=AFAM Alan Hodgson <ah= odgson@lists.simkin.ca> wrote:
On Tue, 2024-05-07 at 00:47 +0530, fi= rst last wrote:
I=C2=A0tried to deploy Postgres deployment with Kubernetes, having = three replicas that are accessing the same storage(PVC). Here is the config= uration

Finally, my question is, why the scenario is different= for MySQL and Postgres?=C2=A0 Could you please help me to figure out=C2=A0= the issue? This is for my Final year project testing Kubernetes using fuzzi= ng.


Not sure what you'r= e trying to accomplish, but PostgreSQL can definitely not share storage bet= ween active postmasters. Nor can MySQL, afaik.
--000000000000f675e10617d5988c--