<p>I am the main dev on <code>db-sync</code>.</p>
<blockquote>
<p>&quot;Deleting 8751 blocks up to slot 55342638&quot;</p>
</blockquote>
<p>The message that is to be expected right after that is &quot;Blocks deleted&quot;, but deleting 8751 blocks should only take 10s of minutes at most providing the machine you are running on <a href="https://github.com/input-output-hk/cardano-db-sync#system-requirements" rel="nofollow noreferrer">meets the minimum system requirements</a>.</p>

CC BY-SA 4.0
2022-03-26T16:36:28.287Z
Hello, thank you for the support!  Yes, the machine has been configured to exceed the requirements you referenced.  It would be great if there was a way to trace the events to help diagnose the issue.  As the main dev, could you please help me in producing the necessary logs so that I can troubleshoot this issue?  Thank you again.
Nicholas
CC BY-SA 4.0
2022-03-27T03:45:43.590Z
If there is nothing in the `db-sync` logs, then this is a PostgreSQL issue.
Erik de Castro Lopo
CC BY-SA 4.0
2022-03-28T13:00:11.523Z
Thank you Erik.  PostgreSQL logging it is then!  I'll be sure to update once I have this issue identified.
Nicholas
CC BY-SA 4.0
2022-03-25T22:12:33.600Z
2022-03-25T22:12:33.600Z
Erik de Castro Lopo
<p>I have the same issue. Because of corrupted connection to a remote cardano-node.
After connection got fixed, db-sync still wants to remove 203 blocks (the other day 213) and that takes forever.</p>
<blockquote>
<p>Mar 31 14:13:46 ip-10-31-12-145 cardano-db-sync[682]: [db-sync-node:Info:59] [2022-03-31 14:13:46.35 UTC] Deleting 203 blocks up to slot 57168135</p>
</blockquote>
<p>Actually, I have never seen db-sync to finish that procedure and I was always switching to manual snapshot restore procedure, that is more predictable in that case.</p>
<p>My machine is beefy AWS instance running dbsync and postgres v14 only.</p>
<p>I would appreciate any Postgres troubleshooting tips.</p>
<p>db-sync logs show nothing after message about deletion.
In processes I see:</p>
<blockquote>
<p>postgres     776     663 98 14:13 ?        00:17:00 postgres: 14/main: cardano mainnet [local] DELETE</p>
</blockquote>

CC BY-SA 4.0
2022-04-07T04:04:06.730Z
Hello,

Thanks so much for commenting on this thread.  My db sync node has been operating without issue after completing the block deletion.  I continue to research Postgres DB logging / profile trace methods, but "work" keeps getting in the way.  I'm sorry I cannot provide further support, but I will be sure to update once I have established the appropriate DB profile tracing to help troubleshoot issues such as this.
Nicholas
CC BY-SA 4.0
2022-03-31T14:35:41.550Z
2022-03-31T14:35:41.550Z
iDen
<p>Apparently, the DB sync process just takes a really long time to &quot;initiate&quot;.  Not sure if that is the right term, but I will use it for now.</p>
<p>I just checked the db-sync status and it has completed the deletion operation and has moved on to processing the deltas.</p>
<p>I believe that the db-sync utility is an absolute must in the Cardano Ecosystem and I look forward to the opportunity to further improve this technology.</p>
<p>Happy exploring everyone!</p>

CC BY-SA 4.0
2022-03-25T15:20:06.527Z
2022-03-25T15:20:06.527Z
Nicholas
<p>Took about 2 hours for me to delete 318 Blocks... My Read IOPS is a bit low (133K Read / 44.5K Write), 2 x 500GB SSDs Raid1, Intel Xeon-E 2136 - 6c/12t - 3.3 GHz/4.5 GHz</p>
<pre><code>2022-06-07T02:21:37.182748120Z [db-sync-node:Info:57] [2022-06-07 02:21:37.18 UTC] Rolling back to slot 62991407, hash b3adef1cb2d8f642f51d60212a719f92080f94b3455c8001e211bf244fbbac3b
2022-06-07T02:21:37.184475177Z [db-sync-node:Info:57] [2022-06-07 02:21:37.18 UTC] Deleting 318 blocks up to slot 62998495
2022-06-07T02:21:37.193243543Z [db-sync-node.Subscription:Notice:47] [2022-06-07 02:21:37.19 UTC] Identity Required subscriptions started
2022-06-07T04:02:32.178760338Z [db-sync-node:Info:57] [2022-06-07 04:02:32.17 UTC] Blocks deleted
2022-06-07T04:03:31.899791964Z [db-sync-node:Info:57] [2022-06-07 04:03:31.89 UTC] Found snapshot file for slot 62991407, hash b3adef1cb2d8f642f51d60212a719f92080f94b3455c8001e211bf244fbbac3b
2022-06-07T04:03:44.397586843Z [db-sync-node:Info:60] [2022-06-07 04:03:44.39 UTC] getHistoryInterpreter: acquired
</code></pre>

CC BY-SA 4.0
2022-06-07T05:19:33.157Z
> 133K Read / 44.5K Write

That's almost unmanageable for large database processing, you'd expect your instance to lag a lot
RdLrT
CC BY-SA 4.0
2022-06-07T23:06:27.627Z
Yeah, I've been planning on upgrading the memory, but good to know I need to upgrade the storage as well
yungtechboy1
CC BY-SA 4.0
2022-06-08T06:18:00.403Z
Sure, just to be sure , you might want to double-check [system requirements for dbsync](https://github.com/input-output-hk/cardano-db-sync#system-requirements) if you havent - those are predominantly aimed for mainnet configuration
RdLrT
CC BY-SA 4.0
2022-06-07T04:21:07.137Z
2022-06-07T04:21:07.137Z
yungtechboy1
<p>I recently created a new server and install of Cardano node and db sync (1.34.1 &amp; 12.0.2) on same machine. I implemented the snapshot restore to bring the Postgres DB up to EPOCH 325 and was able to successfully connect and query the data without issue.  However, now I would like for DB sync to start loading any new (delta) data beyond EPOCH 325, but the DB sync appears to be &quot;sitting&quot; at an operation called &quot;Deleting 8751 blocks up to slot 55342638&quot;.  The operation has been running for 10+ hours and I'm starting to become concerned that the DB sync is not working.</p>
<p><em>NOTE</em>
I do understand that the DB sync operation can take a considerable amount of time, especially for the more recent blocks.  However, from a data processing perspective this is getting hard to comprehend, especially without being able to see logs or events that could show progress.</p>
<p>I'm sure others are experiencing the same issue and if you were able to find a solution, please do share.  All help is very much appreciated.</p>

<cardano-db-sync>
DB Sync deleting blocks up to slot operation running for 10+ hours
# DB Sync deleting blocks up to slot operation running for 10+ hours

(Asked by: username_0 on 2022-03-25)

I recently created a new server and install of Cardano node and db sync (1.34.1 & 12.0.2) on same machine. I implemented the snapshot restore to bring the Postgres DB up to EPOCH 325 and was able to successfully connect and query the data without issue. However, now I would like for DB sync to start loading any new (delta) data beyond EPOCH 325, but the DB sync appears to be "sitting" at an operation called "Deleting 8751 blocks up to slot 55342638". The operation has been running for 10+ hours and I'm starting to become concerned that the DB sync is not working.

*NOTE*
I do understand that the DB sync operation can take a considerable amount of time, especially for the more recent blocks. However, from a data processing perspective this is getting hard to comprehend, especially without being able to see logs or events that could show progress.

I'm sure others are experiencing the same issue and if you were able to find a solution, please do share. All help is very much appreciated.

**Tags:** cardano-db-sync

---

## 4 answers

### Answer by username_1 on 2022-03-25. Score: 2

I am the main dev on `db-sync`.

> "Deleting 8751 blocks up to slot 55342638"

The message that is to be expected right after that is "Blocks deleted", but deleting 8751 blocks should only take 10s of minutes at most providing the machine you are running on [meets the minimum system requirements](https://github.com/input-output-hk/cardano-db-sync#system-requirements).

> **Comments:**
> **username_0**: Hello, thank you for the support!  Yes, the machine has been configured to exceed the requirements you referenced.  It would be great if there was a way to trace the events to help diagnose the issue.  As the main dev, could you please help me in producing the necessary logs so that I can troubleshoot this issue?  Thank you again.  
> **username_1**: If there is nothing in the `db-sync` logs, then this is a PostgreSQL issue.  
> **username_0**: Thank you Erik.  PostgreSQL logging it is then!  I'll be sure to update once I have this issue identified.  

---

### Answer by username_2 on 2022-03-31. Score: 1

I have the same issue. Because of corrupted connection to a remote cardano-node.
After connection got fixed, db-sync still wants to remove 203 blocks (the other day 213) and that takes forever.

> Mar 31 14:13:46 ip-10-31-12-145 cardano-db-sync[682]: [db-sync-node:Info:59] [2022-03-31 14:13:46.35 UTC] Deleting 203 blocks up to slot 57168135

Actually, I have never seen db-sync to finish that procedure and I was always switching to manual snapshot restore procedure, that is more predictable in that case.

My machine is beefy AWS instance running dbsync and postgres v14 only.

I would appreciate any Postgres troubleshooting tips.

db-sync logs show nothing after message about deletion.
In processes I see:

> postgres 776 663 98 14:13 ? 00:17:00 postgres: 14/main: cardano mainnet [local] DELETE

> **Comments:**
> **username_0**: Hello,  Thanks so much for commenting on this thread.  My db sync node has been operating without issue after completing the block deletion.  I continue to research Postgres DB logging / profile trace methods, but "work" keeps getting in the way.  I'm sorry I cannot provide further support, but I will be sure to update once I have established the appropriate DB profile tracing to help troubleshoot issues such as this.  

---

### Answer by username_0 on 2022-03-25. Score: 0

Apparently, the DB sync process just takes a really long time to "initiate". Not sure if that is the right term, but I will use it for now.

I just checked the db-sync status and it has completed the deletion operation and has moved on to processing the deltas.

I believe that the db-sync utility is an absolute must in the Cardano Ecosystem and I look forward to the opportunity to further improve this technology.

Happy exploring everyone!


---

### Answer by username_3 on 2022-06-07. Score: 0

Took about 2 hours for me to delete 318 Blocks... My Read IOPS is a bit low (133K Read / 44.5K Write), 2 x 500GB SSDs Raid1, Intel Xeon-E 2136 - 6c/12t - 3.3 GHz/4.5 GHz
2022-06-07T02:21:37.182748120Z [db-sync-node:Info:57] [2022-06-07 02:21:37.18 UTC] Rolling back to slot 62991407, hash b3adef1cb2d8f642f51d60212a719f92080f94b3455c8001e211bf244fbbac3b
2022-06-07T02:21:37.184475177Z [db-sync-node:Info:57] [2022-06-07 02:21:37.18 UTC] Deleting 318 blocks up to slot 62998495
2022-06-07T02:21:37.193243543Z [db-sync-node.Subscription:Notice:47] [2022-06-07 02:21:37.19 UTC] Identity Required subscriptions started
2022-06-07T04:02:32.178760338Z [db-sync-node:Info:57] [2022-06-07 04:02:32.17 UTC] Blocks deleted
2022-06-07T04:03:31.899791964Z [db-sync-node:Info:57] [2022-06-07 04:03:31.89 UTC] Found snapshot file for slot 62991407, hash b3adef1cb2d8f642f51d60212a719f92080f94b3455c8001e211bf244fbbac3b
2022-06-07T04:03:44.397586843Z [db-sync-node:Info:60] [2022-06-07 04:03:44.39 UTC] getHistoryInterpreter: acquired

> **Comments:**
> **username_4**: > 133K Read / 44.5K Write  That's almost unmanageable for large database processing, you'd expect your instance to lag a lot  
> **username_3**: Yeah, I've been planning on upgrading the memory, but good to know I need to upgrade the storage as well  
> **username_4**: Sure, just to be sure , you might want to double-check [system requirements for dbsync](https://github.com/input-output-hk/cardano-db-sync#system-requirements) if you havent - those are predominantly aimed for mainnet configuration  

---

