OSSO ondersteunt op het gebied van ICT-infrastructuur en softwareontwikkeling

About

About OSSO

OSSO specializes in open source {hosting,network,cloud} infrastructure, development and operations. Covering network, system and software engineering (incl. {dev,netdev,sys,sec}ops).

In depth experience with high availability, multi datacenter setups and being able to combine the expertise from the different domains in our services. Among our customers we count ISP’s, SaaS/cloud services and tech-startups. The support we offer our customers ranges from occasional support requests, 24/7 support and kickstarting new infrastructures, to fully handling operations and providing hosting.

Specialized hosting

High Available
Multi site
Performant
10G/25G/100G network

24/7 Operations

Incident response
Active monitoring
SRE (Site Reliability Engineering)

Managed Kubernetes

Cluster management / operations
Developer and implementation support
Batteries included

Features

Engineering

Cloud/ISP infrastructure
High Availabity
Open Networking
Open Source

Information Security

Security minded
ISMS ISO27001:2013 certified
ISMS NEN7510:2017 certified

Independent infrastructure

AS43366 IP network
Datacenter/POP list
25G/100G Open Networking

Blog

mysql binlog replay / max_allowed_packet

03/05/2024

Trying to replay MySQL binlogs? And running into max_allowed_packet errors? Fear not. Likely this is not corruption, but packets that really are that big. In 2021 I wrote about mariabackup and selective table restore. That blog entry shows how one might restore a mariabackup-saved snapshot of a MariaDB (MySQL) database. Specifically, it focuses on recovering only one or two tables selectively and it details optional GPG decryption and decompression. Here's a recap of the mandatory steps for full recovery and additionally how to replay binlogs to a specific point in time.

mariadb check table / galera locking

17/04/2024

After upgrading some database nodes from MariaDB 10.3 to 10.6 we encountered some issues with tables not being fully correct. We'd like to CHECK (and maybe REPAIR) TABLE the entire database. But the database must not block queries on other nodes of the cluster. The corruption we saw might have been a small corruption that had crept in during even earlier upgrades, we don't know. But we do know that we'd like to get this sorted before the corruption gets worse after further upgrades.

systemd-networkd-wait-online / stalling and failing

29/03/2024

systemd-networkd-wait-online.service failing? Maybe it's IPv6. Do you have a list of failed systemd units that looks like this? # systemctl list-units --failed UNIT LOAD ACTIVE SUB DESCRIPTION ● systemd-networkd-wait-online.service loaded failed failed Wait for Network to be Configured Then that could be due to IPv6 networking not being set up properly. Check the interfaces list: # ip -br a lo UNKNOWN 127.0.0.1/8 ::1/128 ens18 UP 10.20.30.41/31 fe80::a124:092f:fa18:109e/64 ens19 UP 192.168.1.3/31 fe80::a124:092f:fa15:01d5/64 Proper IPv4 IPs, and only link-local IPs for IPv6?

Go to our blog