The next 4 bytes, also 0x00000002, indicate the database size, in pages, after the transaction. This is saying that our page data following the header is meant to overwrite page 2. The first 4 bytes, 0x00000002, are the page number for the entry. The WAL works by appending new data to the -wal file so we’ll see an entry for a single page in our WAL file. If we accidentally overwrite half the header and then the computer shuts down, we can detect that by calculating and comparing the checksum. If SQLite encounters a frame whose salt doesn’t match the header’s salt, then it knows that it’s a frame from an old version of the WAL and it ignores it.įinally, we have an 8-byte checksum of 0x0dd5236d9972220b which is meant to verify the integrity of the WAL header and prevent partial writes. In order for SQLite to know which WAL pages are new and which are old, it writes the salt to the WAL header and every subsequent WAL frame. Instead it just overwrites the previous WAL data. Sometimes the WAL needs to restart from the beginning but it doesn’t always delete the existing WAL data. The term “salt” is typically used in cryptography (and sandwiches, actually) but in this case it’s a little different. We’ll discuss checkpointing later in this post.Īfter that, we have an 8-byte “salt” value of 0x5a20ee38f926b5d3. This is a number that gets incremented on each checkpoint. The next four after that are 0x00000000 which is the checkpoint sequence number.
We’re using the default page size of 4,096 bytes. The next four bytes, 0x00001000, are the page size. There’s currently only one version number for WAL files. This is the big-endian integer representation of 3007000 which means it’s the WAL version created in SQLite 3.7.0. Next, the 0x002de218 is the WAL format version. Nearly all modern processors are little-endian so you’ll almost always see 0x377f0682 as the first 4 bytes of a SQLite WAL file. Every WAL file starts with either 0x377f0682 or 0x377f0683 which indicate whether checksums in the file are in little-endian or big-endian format, respectively. Most SQLite files start with a magic number and the WAL is no exception. You can add these photos to a binder and now the inventory folks can see a point-in-time snapshot of the ingredients without interfering with the sandwich maker. For example, if you’re making a grilled cheese then you’re not going to touch the pickles, right? Right!?Ī better solution would be to only take photos of the ingredients you took from after each sandwich. However, it would be slow and inefficient to take a photo of every ingredient after a sandwich since many ingredients wouldn’t change. That way inventory counters could look at the photos to take inventory. Also, a single slow inventory counter will prevent any sandwiches from being made.Ī simple solution would be to take a photo of every ingredient after a sandwich is made. This is a problem since making a complicated, time-consuming sandwich will prevent inventory from being taken. This is how the rollback journal works a writer can alter the database or readers can read from the database-but not both at the same time. In our sandwich shop example, we had to choose between a single sandwich maker making sandwiches and one or more inventory specialists inventorying ingredients. So how does this simple change enable SQLite to scale? Let’s revisit our sandwich shop example from the last post to see how the WAL would make things run more smoothly. It writes the new version of a page to another file and leaves the original page in-place in the main database file. The rollback journal worked by copying the old version of changed pages to another file so that they can be copied back to the main database file if the transaction rolls back. In 2010, SQLite introduced a second method called the write-ahead log, or as it’s more commonly referred to: the WAL. That was SQLite’s original transactional safety mechanism and it left much to be desired in terms of scaling. In our last post, we talked about the rollback journal. Like any folklore, it has some historical truth.
If you scour Hacker News & Reddit for advice about databases, some common words of caution are that SQLite doesn’t scale or that it is a single-user database and it’s not appropriate for your web-scale application. Give us a whirl and get up and running quickly. Sometimes those containers run SQLite and we make that easy too.
Fly.io runs apps close to users around the world, by taking containers and upgrading them to full-fledged virtual machines running on our own hardware around the world.
0 kommentar(er)
