Performance Monitoring and Tuning in Relational Databases: With Observability Lagniappe

This is a continuation of my posts on relational databases, started here. Previous posts on this theme, “Data Modeling“, “Let’s Talk About Database Schema“, “The Exasperating Topic of Database Indexes“, “The Keys & Relationships of Relational Databases“, “Relational Database Query Optimization“, “Normalization in Relational Databases“, “Database (DB) Caching and DB Tertiary Caching“, “Security and Authentication in Relational Databases“, A Guide to Backup and Recovery Options for Relational Databases: Focusing on SQL Server, Oracle, MariaDB/MySQL, and PostgreSQL, and Concurrency Control in Relational Databases.

In the ever-evolving landscape of software development, the performance of relational databases isn’t just a feature; it’s a critical component of system health that can dramatically influence user satisfaction and operational efficiency. We’re starting a deep dive into the world of performance monitoring and tuning for relational databases, uncovering practices essential for maintaining robustness and speed during database interactions in this post.

Continue reading “Performance Monitoring and Tuning in Relational Databases: With Observability Lagniappe” →

Starting a New Project – Let’s Choose a Tech Stack!

It’s time to start a new project. Because one can never have enough side projects! /s

This particular project I’ll be writing about in this post is derived from the multi-tenant music collector’s database I’ve already started working on. I’ve finally gotten back to it, during a slight break in collecting and music listening, to write up some of my thinking about this particular project.

Stated Objectives For This Application

  1. Personal Reasons: I always like to have side projects that I could make use of myself. Since I’ve recently started collecting music again, and in that am a new collector of vinyl albums, I wanted a better way to organize all that music and the extensive history, members, song, lyrics, and related information about the music and artists.
  2. For Everybody: Beyond the desire to have a well built application to provide the capabilities I’ve described above, I also want to provide this capability to others. In light of that capability, I’ll be designing this application as a multi-tenant application so that you too dear reader, once I get it built can use the application for your own music collection.
  3. Choose The Tech Stack: I’ll need to write this application in something, obviously, so this post is going to cover my reasoning for the tech stack I’m going to use. The application will be built in three core pieces: the database, the services and middle tier layer, and the user interface. I’ll detail each and cover the reasoning for the stack I’ll choose for each section.
Continue reading “Starting a New Project – Let’s Choose a Tech Stack!” →

Speaking of Spring Boot Java Logging, Some Misadventures

Preface: I set out upon a task to incorporate some masking, redaction, or filtering of some sort on PII (Personally Identifying Information) for the log files and log data an application service is producing. The application pre-exists, so this isn’t entirely a green field situation, but the application generally fits a Spring Boot Service style application. The one key thing I wasn’t sure about when starting, was what kind of logging was already incorporated into the operational service.

Log Masking for Different Logging Libraries

The first solution I came up with was to incorporate a converter or appender of some sort that would mask PII with a string of some sort, like “****” or “—–“. This solution that I came up with, upon checking, looked like it would work out ok with or for a number of the top logging libraries for Java, specially libraries that run with or as a Spring Boot service like LogBack or Log4j.

Continue reading “Speaking of Spring Boot Java Logging, Some Misadventures” →

Using Multiple SSH Keys for Multiple Github Account

FIRST – Setup the Keys

If there is already a key, I can use this one to start with, but if there is no key to start with I’ll need to generate one. I can do this with the following command:

ssh-keygen -t rsa

When generating the keys, best to go with the default location, which is ~/.ssh/id_rsa. This will create two files, id_rsa and id_rsa.pub. The id_rsa file is the private key, and the id_rsa.pub file is the public key. The private key should be kept secret, and the public key can be shared with anyone.

For the next account, which I’ll just call the work account, I’ll generate another new key. This time I’ll hand off the following parameters to the key generation to provide the work account email and the file name:

ssh-keygen -t rsa -C "adron.account@work_mail.com" -f "work_account_one"

I’ve now got two keys, one for my personal account and one for my work account.

~/.ssh/id_rsa

~/.ssh/work_account_one

I’ll need to add these to the ssh-agent and the respect Github (or git whatever servers) so that I can use them.

SECOND – Add the Keys to Github

Adding the keys to Github. We’ll start with the personal account and then add the work account. Copy the public key using pbcopy < ~/.ssh/id_rsa.pub. With that copied log into the Github account that this key should be associated with.

1. Got to *settings*.
2. Select *SSH and GPG keys* from the account user menu.
3. Navigate into `New SSH Key`, give it a title, and paste the key into the key field.
4. Click *Add SSH Key*.

Now log out of that Github account and into the other account, the work account. Repeat the steps above, but this time use the work account email and the work account key.

THIRD

Register the new keys with ssh-agent. Start by checking that the ssh-agent is running with eval "$(ssh-agent -s)". In the past we would add the keys to the agent with ssh-add -K ~/.ssh/id_rsa and ssh-add -K ~/.ssh/work_account_one. Now the keys are registered with the agent with the following.

ssh-add --apple-use-keychain ~/.ssh/id_rsa
ssh-add --apple-use-keychain ~/.ssh/work_account_one

FOURTH

There is one last step, I need to tell the ssh client which key to use for which account. I can do this by adding the following to the ~/.ssh/config file.

# Account 1 - Primary
Host github.com
  HostName github.com
  User git
  IdentityFile ~/.ssh/id_rsa
  AddKeysToAgent yes
  UseKeychain yes

# Account 2 - Second Account
Host github.com-work_user_account_name
  HostName github.com
  User git
  IdentityFile ~/.ssh/work_account_one
  AddKeysToAgent yes
  UseKeychain yes

Note that work_user_account_name is the name of the work account, not the email address. I can now use the following commands to clone repositories from the respective accounts. This tells ssh-agent to use the id_rsa key for Git URLs starting with github.com and the work_account_one key for Git URLs starting with github-work_user_account_name.

FIFTH

One active SSH key per working session.

This is a good practice to follow. I can use the following command to start the ssh-agent and add the key to it.

eval "$(ssh-agent -s) ssh-add -K ~/.ssh/id_rsa ssh-add ~/.ssh/id_rsa

The same can then be done when the other key needs to be used.

Ubuntu on Hyper-V, Insuring Enhanced Session Works

Enhanced session mode provides significantly higher performance, hardware utilization, and things like copy & paste between the host and the VM. To make the best use of the VM as a work station this feature is a must have. However, an Ubuntu (or other) installation doesn’t have this capability provided by default, additional software and steps are required to get it working. Those steps are what follows.

Continue reading “Ubuntu on Hyper-V, Insuring Enhanced Session Works” →