Posts

Yugabyte Major Upgrade, p4: Actual Upgrade.

Image
TL;DR: Run the check and then upgrade the database in careful steps. All implemented by just replacing containers and running a few (scripted) commands.  Success!   (but I did pop some questions at the bottom) The upgrade was Plug and Play with containes, more or les... Background. After preparation (link), my cluster is ready for upgrade. My cluster looks like this: Notice three containers running the yb-master-processes, node2, node3 and node4. And another three containers running the yb-tserver processes, node5, node6 and node7 (see prep-steps in earlier blog p3). I can now follow the required sequence: a) upgrade masters, by replacing three containers. b) run the check and the catalog upgrade, using 1 of the new containers. c) upgrade tservers by replacing three containers. d) finalize the upgrade. And if so desired, I can also re-distribute the load over all six containers again. Replacing the first container, fast. I will use node2 to introduce the new software-vers...
Post a Comment
Read more

Yugabyte Major Upgrade part-3: setup and preparation

Image
 [DRAFT] TL;DR: I managed to upgrade yugabyte from pg11 to pg15, using just the container images. This page describes the system and the preparations. Spoiler: Yes! worked. But feel free to use / comment / improve on this. Background. As described in earlier blogposts, I am in the process of upgrading a yugabyte RDBMS from one Major Version to the next. Insert link p1, and link p2... Previous posts describe the summary of steps (p1), and the background to some of my choices (p2).  Now let me describe how this system was built and prepared for upgrade. The next blog (p4) will contain the report of the actual upgrade. Setup: create the containers. Normally I try not to modify a given container-image. Depending on how "strict" you are in containerisation, I do break some of the rules. I took a container image from the official repository (link), but I modified the run-command.  My command notably allows me to issue a "yugabyted stop" without the container coming down. ...
Post a Comment
Read more

Yugabyte Major Upgrade p2: background and self-imposed limitations.

TL;DR: I managed to upgrade yugabyte from pg11 to pg15, using just the container images. Major Upgrades are Necessary, so I better study this process. Using Containers-only is one of my goals. And Zero-Downtime is very desirable for a Database.  Spoiler: Yes! it all worked. But feel free to use / comment / improve on this. In this part, I describe some of my reasoning: Notably why I limited myself to container images, treat my containers as "little servers". And of course I wanted to keep the database "open" during upgrade... Zero Downtime! Note: this is part-2 of a multi-part blog series, I'll put more details on the actual steps, with command and scripts, in the next parts. PostgreSQL: Vendor- and cloud-independence for my RDBMS. Data is always the Core of any IT system. And I do not want my data to be hostage in some vendor-specific RDBMS or vendor-controlled cloud.  Hence PostgreSQL . I also am a fan of Distributed Databases, and I think some of them have th...
Post a Comment
Read more

Yugabyte Major Upgrade, p1: summary

T;DR: I upgraded a running yugabyte database from pg11 to pg15, using just the container images. At RF=3, I used 6 containers. Maybe others can use / comment / improve on this. Note: this will be part of a multi-blog series. This page will give the summary, and some of the background. If needed, I'll put more details on the actual steps in the next parts. Summary up front  : From reading the doc-pages, I distilled the principle steps: a) - Prepare and check. Also add parameters (gflag) for mixed mode. b) - Upgrade masters and run masters in new version, keep tservers on old version. c) - Upgrade catalog . I frankly have no clue how that happens in the background, but I  understand this is needed. Every database has this "critical moment" of "catalog upgrade" d) - Upgrade all tservers, do this 1 by 1 to keep quorum at all times. e) - Finalize upgrade. f) - Cleanup, remove parameters (gflag) for mixed-mode to allow complete usage of new features. From these princi...
Post a Comment
Read more

[DRAFT] Yugabyte and Postgres - Finding information.

Image
 TL;DR: [DRAFT] Could not resist creating an ERD of tables to collect metrics. I have put "Session" central to my information. Considering it is the application-connect that initiates the session and is the main "customer" causing all activity in a database. Regarding Session: a Datamodel... Aim is currently to find heavy processes and heavy queries.  Spotting underlying tablets / tables may/should follow from that.  But other may be more interested to dive directly into the storage-layer  (as thew metrics on port 9000 seem to focus on rocksdb) Central, I think, is the "Session". as identified from from pg_stat_activity and from. the ps -ef list on the host. I then built a number of entities (tables) around the Session with the aim of collecting data. Relevant Data (I hope).  Metrics... I did get lost a bit in the huge amount of text coming from ports 7000 and 9000. They seem to provide a lot of rocks-db and program/process info. But I could not (yet) rel...
Post a Comment
Read more