![]() Additionally, we shall try to look at specific areas in this synchronous archival processing of WAL, and how it is hurting the speed of archival and becoming a challenge. ![]() ![]() In this blog, we are going to look at a bit of internals on how the archiver process works and how it deals with the external shell command specified inĪrchive_command in a synchronous fashion. Unless monitored and handled properly, it can lead to disaster. Moreover, users/organizations are becoming increasingly familiar with cloud storage, and this increase in comfort level is the major driving force in the decision-making towards cloud storage for backups.īut this rapid generation of WAL segments + slow/remote location of storage as the archive location is a deadly combination for the overall WAL archival process. Meanwhile, remote cloud storage is becoming a more attractive choice for storing archive WAL due to the price advantage over costly backup appliances and time-tested reliability. How backup solutions like WAL-G and pgBackRest solve this with built-in compression features is also discussed in that blog post. The reason why WAL compression is becoming a pressing need is also not different. Basically, more work is getting done per server, and as a consequence, a huge amount of WAL generation is also becoming the new normal. The recent increase in such cases is mainly triggered by an increase in processing power per host server, ever-increasing the scalability of PostgreSQL (eg, recent advancements in partitioning features, bulk data loading improvements, etc.), and faster, new-generation storage. Obviously, “slow” is subjective and mostly users refer to “slow” compared to the speed at which the WAL segment generation is happening. However, a different type of case started appearing in recent years, which is in the title of this post. ![]() The most common reasons we used to find were: Panicking customers generally ask “Why isn’t PostgreSQL deleting them?”. It is very common to see many customer cases where a sudden increase in disk space usage is caused by a lot of WAL segments filling up the WAL directory (pg_wal). ![]()
0 Comments
Leave a Reply. |
AuthorWrite something about yourself. No need to be fancy, just an overview. ArchivesCategories |