Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

[BUG] postgresql pitr stopTIME is different from the RECOVERABLE-TIME described in the cluster #3938

Closed
JashBook opened this issue Jun 25, 2023 · 1 comment
Assignees
Labels
bug kind/bug Something isn't working
Milestone

Comments

@JashBook
Copy link
Collaborator

Describe the bug
postgresql pitr stopTIME is different from the RECOVERABLE-TIME described in the cluster.

kbcli version
Kubernetes: v1.23.15
KubeBlocks: 0.5.3-beta.6
kbcli: 0.5.3-beta.6

To Reproduce
Steps to reproduce the behavior:

  1. create cluster
  2. logfile backup
  3. see error
➜  kbcli cluster describe cluster-walpjm 
Name: cluster-walpjm	 Created Time: Jun 25,2023 19:52 UTC+0800
NAMESPACE   CLUSTER-DEFINITION   VERSION              STATUS    TERMINATION-POLICY   
default     postgresql           postgresql-12.14.0   Running   WipeOut              

Endpoints:
COMPONENT    MODE        INTERNAL                                                   EXTERNAL   
postgresql   ReadWrite   cluster-walpjm-postgresql.default.svc.cluster.local:5432   <none>     

Topology:
COMPONENT    INSTANCE                      ROLE        STATUS    AZ           NODE                                                           CREATED-TIME                 
postgresql   cluster-walpjm-postgresql-0   primary     Running   us-west1-a   gke-kubeblocks-test-default-pool-77c8b94a-v2xl/10.138.15.240   Jun 25,2023 19:52 UTC+0800   
postgresql   cluster-walpjm-postgresql-1   secondary   Running   us-west1-a   gke-kubeblocks-test-default-pool-77c8b94a-is5q/10.138.15.218   Jun 25,2023 19:52 UTC+0800   

Resources Allocation:
COMPONENT    DEDICATED   CPU(REQUEST/LIMIT)   MEMORY(REQUEST/LIMIT)   STORAGE-SIZE   STORAGE-CLASS   
postgresql   false       100m / 100m          512Mi / 512Mi           data:10Gi      standard-rwo    

Images:
COMPONENT    TYPE         IMAGE                                                      
postgresql   postgresql   registry.cn-hangzhou.aliyuncs.com/apecloud/spilo:12.14.1   

Data Protection:
AUTO-BACKUP   BACKUP-SCHEDULE   TYPE     BACKUP-TTL   LAST-SCHEDULE                RECOVERABLE-TIME                                                
Disabled      <none>            <none>   7d           Jun 25,2023 20:05 UTC+0800   Jun 25,2023 19:55:54 UTC+0800 ~ Jun 25,2023 19:55:54 UTC+0800   

Show cluster events: kbcli cluster list-events -n default cluster-walpjm

➜   kubectl get backups.dataprotection.kubeblocks.io 692c1faf-cluster-walpjm-defaul-logfile  -oyaml
apiVersion: dataprotection.kubeblocks.io/v1alpha1
kind: Backup
metadata:
  annotations:
    dataprotection.kubeblocks.io/target-pod-name: cluster-walpjm-postgresql-0
    kubeblocks.io/cluster-snapshot: '{"metadata":{"name":"cluster-walpjm","namespace":"default","creationTimestamp":null},"spec":{"clusterDefinitionRef":"postgresql","clusterVersionRef":"postgresql-12.14.0","terminationPolicy":"WipeOut","componentSpecs":[{"name":"postgresql","componentDefRef":"postgresql","replicas":2,"resources":{"limits":{"cpu":"100m","memory":"512Mi"},"requests":{"cpu":"100m","memory":"512Mi"}},"volumeClaimTemplates":[{"name":"data","spec":{"accessModes":["ReadWriteOnce"],"resources":{"requests":{"storage":"10Gi"}}}}],"switchPolicy":{"type":"Noop"},"serviceAccountName":"kb-sa-cluster-walpjm"}],"affinity":{"podAntiAffinity":"Preferred","tenancy":"SharedNode"}},"status":{}}'
    kubectl.kubernetes.io/last-applied-configuration: |
      {"apiVersion":"dataprotection.kubeblocks.io/v1alpha1","kind":"Backup","metadata":{"annotations":{},"labels":{"app.kubernetes.io/instance":"cluster-walpjm","dataprotection.kubeblocks.io/backup-type":"logfile","kubeblocks.io/backup-protection":"retain"},"name":"692c1faf-cluster-walpjm-defaul-logfile","namespace":"default"},"spec":{"backupPolicyName":"cluster-walpjm-postgresql-backup-policy","backupType":"logfile"}}
  creationTimestamp: "2023-06-25T11:57:01Z"
  finalizers:
  - dataprotection.kubeblocks.io/finalizer
  generation: 1
  labels:
    app.kubernetes.io/component: postgresql
    app.kubernetes.io/instance: cluster-walpjm
    app.kubernetes.io/managed-by: kubeblocks
    app.kubernetes.io/name: postgresql
    app.kubernetes.io/version: postgresql-12.14.0
    apps.kubeblocks.io/component-name: postgresql
    apps.kubeblocks.io/workload-type: Replication
    apps.kubeblocks.postgres.patroni/role: master
    apps.kubeblocks.postgres.patroni/scope: cluster-walpjm-postgresql-patroni2715afd1
    controller-revision-hash: cluster-walpjm-postgresql-6fd8946858
    dataprotection.kubeblocks.io/backup-type: logfile
    kubeblocks.io/backup-protection: retain
    kubeblocks.io/role: primary
    postgresql-configuration: 8557b89cf7
    statefulset.kubernetes.io/pod-name: cluster-walpjm-postgresql-0
  name: 692c1faf-cluster-walpjm-defaul-logfile
  namespace: default
  resourceVersion: "59764495"
  uid: 183435e9-aca3-405e-b854-1263e0435486
spec:
  backupPolicyName: cluster-walpjm-postgresql-backup-policy
  backupType: logfile
status:
  backupToolName: postgres-pitr
  completionTimestamp: "2023-06-25T12:05:24Z"
  duration: 22s
  expiration: "2023-07-02T12:06:03Z"
  manifests:
    backupLog:
      startTime: "2023-06-25T11:55:54Z"
      stopTime: "2023-06-25T12:04:44Z"
    backupTool:
      filePath: /default/cluster-walpjm-692c1faf-e50f-4710-9123-4cf52715afd1/postgresql/692c1faf-cluster-walpjm-defaul-logfile
  persistentVolumeClaimName: logfile-backup-data
  phase: InProgress
  startTimestamp: "2023-06-25T12:06:03Z"

Expected behavior
postgresql pitr stopTIME is consistent with the RECOVERABLE-TIME described in the cluster.

Screenshots
If applicable, add screenshots to help explain your problem.

Desktop (please complete the following information):

  • OS: [e.g. iOS]
  • Browser [e.g. chrome, safari]
  • Version [e.g. 22]

Additional context
Add any other context about the problem here.

@JashBook JashBook added the kind/bug Something isn't working label Jun 25, 2023
@JashBook JashBook added this to the Release 0.6.0 milestone Jun 25, 2023
@wangyelei
Copy link
Contributor

already fixed at #3854

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
bug kind/bug Something isn't working
Projects
None yet
Development

No branches or pull requests

3 participants