Received: from malur.postgresql.org ([217.196.149.56]) by arkaria.postgresql.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_CBC_SHA1:256) (Exim 4.89) (envelope-from ) id 1hT7ln-0006mg-2r for pgsql-performance@arkaria.postgresql.org; Tue, 21 May 2019 16:37:43 +0000 Received: from localhost ([127.0.0.1] helo=malur.postgresql.org) by malur.postgresql.org with esmtp (Exim 4.89) (envelope-from ) id 1hT7lk-000844-Dv for pgsql-performance@arkaria.postgresql.org; Tue, 21 May 2019 16:37:40 +0000 Received: from magus.postgresql.org ([2a02:c0:301:0:ffff::29]) by malur.postgresql.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_CBC_SHA1:256) (Exim 4.89) (envelope-from ) id 1hT7lj-00083x-Vi for pgsql-performance@lists.postgresql.org; Tue, 21 May 2019 16:37:40 +0000 Received: from mail-wm1-x342.google.com ([2a00:1450:4864:20::342]) by magus.postgresql.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_CBC_SHA1:256) (Exim 4.89) (envelope-from ) id 1hT7lg-0003s8-LF for pgsql-performance@postgresql.org; Tue, 21 May 2019 16:37:39 +0000 Received: by mail-wm1-x342.google.com with SMTP id q15so3578632wmj.0 for ; Tue, 21 May 2019 09:37:35 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=2ndquadrant-com.20150623.gappssmtp.com; s=20150623; h=date:from:to:cc:subject:message-id:references:mime-version :content-disposition:in-reply-to:user-agent; bh=Kwaei6JxvRi/thBob0PZ6IkNgzD3d9hUm/B/4iI5r70=; b=bq+Av5D9WhL46nD/M1ZUF1r2d1nWbGzNg2fPPYjjh74ES4Uw9rIL7HQFoyZBLmECAC OINRk1PIRTQjq6EmFiK7fRb9mMHa43rzRJqXod/p+n9bYJVDgdT5zgiFmPT6ttgZDa7K mAFKEzK/yJCkAQcw4uNS+Fofo8KmF08AHQNy3i2UUfRHEUuvGG5WVl29NTSZe/bK+4Mr +OJ9dU2Z6E7JmiJt1iD6wpuY118JNEDzbiWgMm49ZX1+KXR9ZnLOIz/5vJ/sqeqXIuKh fD6HN8ZBSVJKRlaJQ+7I7Tgk/In+riEySEmCmruj5GevCzA/NE/PDVCx7Ik4kxLa6TQ7 EUIA== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:date:from:to:cc:subject:message-id:references :mime-version:content-disposition:in-reply-to:user-agent; bh=Kwaei6JxvRi/thBob0PZ6IkNgzD3d9hUm/B/4iI5r70=; b=hCwmDbVT036386w2addc090c1gyr5PeQJte6m9yZwIJ/FJ+luY3xMoP+VyUl99FkdJ w3wXh+ya6aTOGlvnmnMFkEeg/VExs5C6vyNp1PIJCOSUSGIsqLIbbCowsDZr0WoDnmH3 JUMyE04QnoFrZ1geV+8ubYGWGFonbH+z0oCapkT1DORriwh5wiUlcFK9piMFNUETqAQw tqT2z+oEhZ9k4C9i4owq5NTmA6YR+KmoEZH7PvMwSrNy5cOQRfGpiN0fQfxBeL0al6H/ 83z5nRCNfUjH1nSrGPGleAMyraOwd2+3i68h7+3ClJvOtQ4wATqOXll3YtT0/G2/gQa0 h/cA== X-Gm-Message-State: APjAAAWsqu5n066561T2nKitcBFRNbz279SL+NzmVQyk8VLZQptXIHXt WkaPgjxrrTxsKtlaZ6uv8aaBFQ== X-Google-Smtp-Source: APXvYqyzcjhjXAYMHes/mVrZj2WWBUQO2jVQ1YhF1Hl/fE4uGbPbSnGNEmWPiUOQkWP/ksZ6aaCtMQ== X-Received: by 2002:a1c:9c8c:: with SMTP id f134mr3928037wme.95.1558456654554; Tue, 21 May 2019 09:37:34 -0700 (PDT) Received: from localhost (static-84-42-175-93.net.upcbroadband.cz. [84.42.175.93]) by smtp.gmail.com with ESMTPSA id m17sm4104400wmc.6.2019.05.21.09.37.28 (version=TLS1_3 cipher=AEAD-AES256-GCM-SHA384 bits=256/256); Tue, 21 May 2019 09:37:29 -0700 (PDT) Date: Tue, 21 May 2019 18:37:27 +0200 From: Tomas Vondra To: Greg Clough Cc: Mariel Cherkassky , Bimal , PostgreSQL mailing lists Subject: Re: Trying to handle db corruption 9.6 Message-ID: <20190521163727.kdcvkpwm2n3fliou@development> References: <1909968146.4951657.1558369245203@mail.yahoo.com> <20190520210406.5paaijqd5no6imez@development> <20190521130714.4ncqlri3o224ptpx@development> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii; format=flowed Content-Disposition: inline In-Reply-To: User-Agent: NeoMutt/20180716-1444-295967-dirty List-Id: List-Help: List-Subscribe: List-Post: List-Owner: List-Archive: Precedence: bulk On Tue, May 21, 2019 at 04:03:52PM +0000, Greg Clough wrote: >> My restore command copy the wals from archive dir in the primary to an >> archive dir in the secondary(different from the pg_xlog in the >> secondary) > >I think that you're restore command puts them back into the archive, and >then uncompresses them into pg_xlog, which is what %p represents. > > >> Should I run it manually and see if the archives are copied to the >> archive dir in the secondary or should I just copy all of them to the >> xlog dir in the secondary ? > >That would be my first test, but as Thomas mentioned, you don't have any >hint of WAL archives being restored in the postgresql.log... so it's not >even trying. It's not likely that archive_command is your problem at the >moment. > > >> I tried to start the secondary as a primary (I have a backup..) but I >> still got an error (invalid checkpoint record from primary./ >> secondary). Does it means that my backup is corrupted ? > >I think so, but Thomas could probably confirm if all hope is lost. Also, >I'm not sure if there is a terminology difference but a "standby" is >never considered a "backup". I realise it's late in the day, but even if >you have a correctly configured Standby you should also take backups with >pg_basebackup, Barman, pgBackRest, etc. > Well, I have no idea. We still got no information about how the standby was created, if it was ever running fine, and so on. Considering it does not seem to be getting data from the archive, it might be the case it was created in some strange way and never really worked. And if there really are no log messages about the restore_command, it probably fails before the standby even tries to execute it. So I don't know. >Restoring backups is where I would be heading now, as things seem >terribly broken. > Right. But my impression is there are no backups ... regards -- Tomas Vondra http://www.2ndQuadrant.com PostgreSQL Development, 24x7 Support, Remote DBA, Training & Services