Thread: Cluster on NAS and data center.
<p dir="ltr">Hello everyone,<p dir="ltr"><p dir="ltr">Right now we have PostgreSQL on Windows Server (main data center) andcluster is placed on NAS. We have emergency data center on UNIX architecture. We want that emergency data center couldcontinue work on PostgreSQL cluster that has been used by Windows PostgreSQL.<p dir="ltr"><p dir="ltr">We know thatstandard PostgreSQL is not able to use cluster created on different OS. We think that recompilation PostgreSQL with somespecific flags. This should give us compatibility of cluster on different Systems. We see a small differences in clusterfiles on binary level. Can You help us pick proper compilation flags?
On 4 July 2016 at 17:33, Krzysztof Kaczkowski <grafvader@gmail.com> wrote:
Hello everyone,
Right now we have PostgreSQL on Windows Server (main data center) and cluster is placed on NAS. We have emergency data center on UNIX architecture. We want that emergency data center could continue work on PostgreSQL cluster that has been used by Windows PostgreSQL.
We know that standard PostgreSQL is not able to use cluster created on different OS. We think that recompilation PostgreSQL with some specific flags. This should give us compatibility of cluster on different Systems. We see a small differences in cluster files on binary level. Can You help us pick proper compilation flags?
I wouldn't recommend that, and it might be pretty tricky.
Windows is an LLP64 architecture, and *nix is usually LP64. Because PostgreSQL's data directory format is directly tied to the size of data types in the host operating system this might cause you problems. See http://stackoverflow.com/a/384672/398670 . sizeof(long) will differ.
I'd love to break that particular assumption if/when an on-disk format break is done, since it's very unfortunate that PostgreSQL on one architecture/OS won't read data directories from another architecture/OS. But for now we're fairly stuck with it AFAIK.
Why can'y you just deploy a Windows backup cluster?
<p dir="ltr">Hello,<p dir="ltr"><p dir="ltr">About Your question, please do not ask. This infrastructure is an outcome ofa very long talk with supervisors.<p dir="ltr"><p dir="ltr">Back to the topic. I like the tricky part. Do You think thereis some way to achieve this on compilation level or shall we search somewhere else? For example UNIX libraries or evenchange and recompile kernel?
Craig Ringer <craig@2ndquadrant.com> writes:
> On 4 July 2016 at 17:33, Krzysztof Kaczkowski <grafvader@gmail.com> wrote:
>> We know that standard PostgreSQL is not able to use cluster created on
>> different OS. We think that recompilation PostgreSQL with some specific
>> flags. This should give us compatibility of cluster on different Systems.
>> We see a small differences in cluster files on binary level. Can You help
>> us pick proper compilation flags?
> I wouldn't recommend that, and it might be pretty tricky.
Indeed. Aside from architectural differences, I'd be very afraid of
differences in collation order (resulting in incompatible indexes on
textual columns). You might be able to make it work if you only ever
use "C" locale. But really, this is not and will never be considered
supported usage, and if it fails, no one is going to say anything
except "we warned you not to do that".
regards, tom lane
<div dir="ltr"><div style="white-space:pre-wrap">As someone who has bitten by index corruption due to collation changes betweenglibc versions that shipped CentOS 6 and CentOS 7, don't even try to do this with anything other than C collation.The default collation _will_ deterministically leave you with a silently corrupt database if you store anythingother than ASCII text. Windows and Linux are going to implement en_US.utf-8 slightly differently and Postgres iscurrently relying on the OS to provide collation implementations. Go search for my mailing list post about the dangersof running across versions of glibc for more info.<br /><br />I'm going to echo everyone else's sentiment though,and assert that what you are trying to do is really an insane idea. You might be able to make it appear like its workingbut as a DBA, I would have absolutely no confidence in using that server for disaster recovery.<br /><br />If yourcompany is saving money by not getting Windows licenses for your DR environment, you are far better off just saving onemore license and making both your production and DR server be Linux builds.<br /><br />- Matt K.</div></div>
<p dir="ltr">Hello,<p dir="ltr"><p dir="ltr">Thanks to emails, we have achieved what we wanted. This is what we’ve done:<pdir="ltr">Compilation (for 32 bit version, initdb with locale=C):<p dir="ltr">CFLAGS="-mx32 -fexcess-precision=standard-O2"<br /> CXXFLAGS="-mx32"<p dir="ltr">configure --without-zlib --disable-float8-byval --without-readline--host=x86_64-linux-gnux32<p dir="ltr">We also have installed libx32.<p dir="ltr">Right now we receivedcluster that is fully manageable from both systems. Anyone see something dangerous with this compilation?
On Tue, Jul 5, 2016 at 7:46 AM, Krzysztof Kaczkowski <grafvader@gmail.com> wrote: > Thanks to emails, we have achieved what we wanted. This is what we’ve done: > > Compilation (for 32 bit version, initdb with locale=C): > > CFLAGS="-mx32 -fexcess-precision=standard -O2" > CXXFLAGS="-mx32" > > configure --without-zlib --disable-float8-byval --without-readline > --host=x86_64-linux-gnux32 > > We also have installed libx32. > > Right now we received cluster that is fully manageable from both systems. > Anyone see something dangerous with this compilation? That seems to cover a fair amount of territory, but it might be unwise to assume that there are no other issues. -- Robert Haas EnterpriseDB: http://www.enterprisedb.com The Enterprise PostgreSQL Company