Re: [GENERAL] Advice on contingency plan for DAS array with separate local WAL drives
Jeff Amiel wrote: Recently migrated to a shiny new 8.4.4 postgres instancedata stored on attached storage array. Transaction logs stored on 2 local mirrored drives (local to the database server itself) for best performance. Have you benchmarked that this really helps? Splitting the WAL out onto a drive pair can help a lot in some cases, but given a large attached array the improvement tends to be minimal relative to just lumping those writes in with the rest of the array. The easy way out of your problem is to just not put the WAL on the local drives, and instead use them for things like temp file storage. -- Greg Smith 2ndQuadrant US Baltimore, MD PostgreSQL Training, Services and Support g...@2ndquadrant.com www.2ndQuadrant.us -- Sent via pgsql-general mailing list (pgsql-general@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-general
Re: [GENERAL] Advice on contingency plan for DAS array with separate local WAL drives
On 6/14/10 8:05 AM, "Jeff Amiel" wrote: > What is recommended in terms of prep/switchover in this instance? Should we > be rsyncing or using built-in wal-log shipping of these transaction logs to > our stand-by server? Simply pop out these drives and hand-move them to the > standby-server? (assuming they are not the issue in the first place) I should note that this 'similar' server is not intended to actually be a real warm standby server in the postgres sense...it serves other purposes...it simply possesses the right configuration (memory, cpu) to act as a temporary database server. -- Sent via pgsql-general mailing list (pgsql-general@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-general
[GENERAL] Advice on contingency plan for DAS array with separate local WAL drives
Recently migrated to a shiny new 8.4.4 postgres instancedata stored on attached storage array. Transaction logs stored on 2 local mirrored drives (local to the database server itself) for best performance. While we are replicating (using slony) to our DR site, our first-choice plan (in the event of an issue simply with the database server itself) was to disconnect the SAS cables from it (connected to the DAS) and connect them to a 'similar' box we have on standby. With the WAL logs physically on the drives of the original database server, this obviously becomes an issue. What is recommended in terms of prep/switchover in this instance? Should we be rsyncing or using built-in wal-log shipping of these transaction logs to our stand-by server? Simply pop out these drives and hand-move them to the standby-server? (assuming they are not the issue in the first place) Any thoughts would be appreciated. -- Sent via pgsql-general mailing list (pgsql-general@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-general
