# PITR has errors "scan binlogs: sql: expected 2 destination arguments in Scan, not 3"

**URL:** <https://forums.percona.com/t/pitr-has-errors-scan-binlogs-sql-expected-2-destination-arguments-in-scan-not-3/10505>\
**Category:** Percona Operator for MySQL\
**Created:** [May 18, 2021, 2:09pm UTC](https://forums.percona.com/t/pitr-has-errors-scan-binlogs-sql-expected-2-destination-arguments-in-scan-not-3/10505 "2021-05-18T14:09:58Z")\
**Posts on this page:** 3\
**Page:** 1

<div class="post-metadata">

**Author:** ![kim.attree](https://sea1.discourse-cdn.com/flex019/user_avatar/forums.percona.com/kim.attree/32/3558_2.png) [@kim.attree](https://forums.percona.com/u/kim.attree)\
**Post date:** [May 18, 2021, 2:09pm UTC](https://forums.percona.com/t/pitr-has-errors-scan-binlogs-sql-expected-2-destination-arguments-in-scan-not-3/10505/1 "2021-05-18T14:09:58Z")

</div>

I’ve rolled out a new cluster, integrated Google bucket storage in S3 mode, done a manual backup without any issue, and am now trying to get PITR to S3 working, but I keep getting this error from the PITR pod:

> 2021/05/18 13:50:08 ERROR: get binlog time get binlog list for host lithium-pxc-0.lithium-pxc.percona.svc.cluster.local: scan binlogs: sql: expected 2 destination arguments in Scan, not 3  
> 2021/05/18 13:50:08 ERROR: get binlog time get binlog list for host lithium-pxc-1.lithium-pxc.percona.svc.cluster.local: scan binlogs: sql: expected 2 destination arguments in Scan, not 3  
> 2021/05/18 13:50:08 ERROR: get binlog time get binlog list for host lithium-pxc-2.lithium-pxc.percona.svc.cluster.local: scan binlogs: sql: expected 2 destination arguments in Scan, not 3  
> 2021/05/18 13:50:08 ERROR: new db connection: get host: can’t find host

binary logging is definately enabled:

> BMySQL [lithium\_accounting\_internal]\> SHOW BINARY LOGS;  
> ±----------±-----------+  
> | Log\_name | File\_size |  
> ±----------±-----------+  
> | ON.000001 | 1074370202 |  
> | ON.000002 | 1074262473 |  
> | ON.000003 | 1074567455 |  
> | ON.000004 | 1074773930 |  
> | ON.000005 | 1074377427 |  
> | ON.000006 | 1074027489 |  
> | ON.000007 | 232224147 |  
> ±----------±-----------+  
> …  
> BMySQL [lithium\_accounting\_internal]\> show master status;  
> ±----------±----------±-------------±-----------------±------------------+  
> | File | Position | Binlog\_Do\_DB | Binlog\_Ignore\_DB | Executed\_Gtid\_Set |  
> ±----------±----------±-------------±-----------------±------------------+  
> | ON.000007 | 232224147 | | | |  
> ±----------±----------±-------------±-----------------±------------------+

Cluster is ready and working, everything is in sync, just dont know whats going on here with PITR.

Thanks in advance,

K

---

<div class="post-metadata">

**Author:** ![Sergey\_Pronin](https://sea1.discourse-cdn.com/flex019/user_avatar/forums.percona.com/sergey_pronin/32/14887_2.png) [@Sergey\_Pronin](https://forums.percona.com/u/Sergey_Pronin)\
**Post date:** [May 27, 2021, 7:18am UTC](https://forums.percona.com/t/pitr-has-errors-scan-binlogs-sql-expected-2-destination-arguments-in-scan-not-3/10505/2 "2021-05-27T07:18:55Z")

</div>

I saw your message in discord. Seems you are running MySQL 5.7. PITR is supported in 8.0 for now as per [About backups - Percona Operator for MySQL based on Percona XtraDB Cluster](https://www.percona.com/doc/kubernetes-operator-for-pxc/backups.html#storing-binary-logs-for-point-in-time-recovery:)

> Point-in-time recovery is off by default and is supported by the Operator only with Percona XtraDB Cluster versions starting from 8.0.21-12.1.

---

<div class="post-metadata">

**Author:** ![kim.attree](https://sea1.discourse-cdn.com/flex019/user_avatar/forums.percona.com/kim.attree/32/3558_2.png) [@kim.attree](https://forums.percona.com/u/kim.attree)\
**Post date:** [May 27, 2021, 8:04am UTC](https://forums.percona.com/t/pitr-has-errors-scan-binlogs-sql-expected-2-destination-arguments-in-scan-not-3/10505/3 "2021-05-27T08:04:01Z")

</div>

Hi @Sergey_Pronin 100% correct yes,

I will be upgrading my cluster shortly, just waiting to upgrade my database connection pools to Hikari in our java apps first.

Thanks for the response.