For completion sake, I accidentally obfuscated my root folder from SQL Developer. I was able to fix it by deleting all my old config files.

What you needed to set up was "dual-Primary" (aka "dual master"). This is where each of the two servers was both Primary and Replica to the other. That way, you would already have set up the replication mechanisms so that failover and fallback would be the same process.

It is correct that InnoDB tablespace files never shrink. There may be unused space within a large file after you delete a lot of rows, but the file still occupies a lot of space on your filesystem. The only way to make the file smaller is to copy the remaining data to a new tablespace and then drop the original tablespace. This is what the ALTER statement you described does. Alternative forms of this statement are: ALTER TABLE FORCE; OPTIMIZE TABLE ; They all do the same thing. I like the one with FORCE because it's most clear to me what it's doing. Copy a lot of data to a new tablespace takes a long time, and blocks access to the table while it's running. What I've done at some jobs in the past is to use the free tool https://www.percona.com/doc/percona-toolkit/LATEST/pt-online-schema-change.html to run this task without blocking access to the table. It may in fact take longer than it does to run the ALTER TABLE directly, but since it does not block access, that does not cause an outage, so no one gets upset that it takes a long time. We have run this on tables much larger than the one you describe, so large that it took days to complete. You use MariaDB. I don't, and I have never personally used pt-online-schema-change with MariaDB. But I understand from other users that it works the same, since MariaDB is similar enough to MySQL that the features needed by pt-online-schema-change work the same. MariaDB is not the same product as MySQL, but in this case it is close enough.

sudo apt install postgis postgresql-13-postgis-3-scripts create extension postgis;

1.use pt-table-checksum tool for master and slave data 2.skip the error mysql> stop slave; mysql> set @@session.gtid_next='xxxxx'; mysql> begin; mysql> commit; mysql> set @@session.gtid_next=automatic; mysql> start slave; mysql> show slave status \G

That is probably CHARACTER SET ucs2. mysql --default-character-set=ucs2 -u root -p database < dumpfile.sql That does not impact what charset is used in the tables, only for reading the file. History MySQL 5.0.67 (Aug, 2008): "ucs2 does not work as a client character set, but attempts to use it as such were not rejected. Now character_set_client cannot be set to ucs2. This also affects statements such as SET NAMES and SET CHARACTER SET. (Bug #31615)". MySQL 8.0.28 (Jan, 2022): ucs2, macroman, macce, dec, hp8 and "their collations in SQL statements or elsewhere in the MySQL server now produces a deprecation warning." (That is, they are still supported, but not for very long.) Conclusion: It may not be possible to import that data.

Based on some of the comments on https://github.com/ValveSoftware/steam-for-linux/issues/730 , this message is triggered if Steam is unable to launch a child process by executing a script which it creates under the affected library. Here are some reasons why that might happen: The script lacks execute permission in its filesystem mode (the x flag in ls -l's output). But Steam created this script, and it should have set the appropriate permissions automatically. Fix with https://linux.die.net/man/1/chmod . Any directory in the path to the script lacks execute permission. But I would expect this to cause much more substantial problems because you would be unable to even browse your Steam library in the file explorer. You can also fix this with chmod(1). Do not pass the -R flag unless you are sure you know what you are doing. Steam is running as a different user, which is not the normal way of setting things up, and that user lacks permissions as above. You may need to either chmod the library to add permissions, set up group permissions with https://linux.die.net/man/8/groupadd and https://man7.org/linux/man-pages/man1/chgrp.1.html , and/or use https://linux.die.net/man/1/chown to give the library (recursively if necessary) to Steam's user. Or you may simply need to make sure that Steam is running as you and not as some other user. The drive is mounted noexec, which prevents anyone from executing any binaries on the filesystem. Some Linux distributions do this automatically for removable drives, as a security measure, but I think we can rule this out based on your mount output. For completeness, this can be temporarily fixed with https://linux.die.net/man/8/mount but the permanent fix will depend on how your OS is mounting the drive. https://man7.org/linux/man-pages/man3/system.3.html is unable to find /bin/sh. But then your whole OS should be broken. A security tool such as SELinux or AppArmor is preventing Steam from executing binaries on this drive. These are very complicated to monkey around with. Some of the discussion on that bug suggests it might be a problem with case sensitivity. Try renaming the library (and in particular, the SteamApps subdirectory) to all lowercase. If you try to run that script yourself (it should be named .steam_exec_test.sh, and may not be visible unless you show hidden files), it may provide output to help you further diagnose the problem.

I'm going to answer this question a different way. When we're talking about database servers, the data within said databases is typically far more valuable than anything sitting on the file system. Database servers can be brought back online, databases can be restored from backups, etc... Not to diminish the fact that a user with OS access can wreck havoc and take a database offline. I'd be far more concerned what a malicious user would do to a database with write permission. They can manipulate data, delete data, insert bad data, etc. If a user is truly wanting to be malicious, this is all the access the would need to be destructive. Depending how aggressive they are, data changes could go undetected for weeks or months, making the chance of recovery challenging. So in this case, what are you trying to protect against? Preventing a trusted database users from making accidentally changes at the OS level? Making sure the scope of a malicious user is limited?

The key point here is a missing dependency: libqt5sql5-odbc and/or libqt5sql5-tds. Here a complete guide: Install ODBC and FreeTDS packages: sudo apt install unixodbc odbcinst freetds-bin tdsodbc Install additional packages required by QGIS for ODBC connection: sudo apt install libqt5sql5-odbc libqt5sql5-tds Install Microsoft SQL Server driver following the instructions on https://docs.microsoft.com/en-us/sql/connect/odbc/linux-mac/installing-the-microsoft-odbc-driver-for-sql-server Check the content of /etc/odbcinst.ini to make sure FreeTDS and MS SQL Server drivers are listed: [FreeTDS] Description=v0.91 with protocol v7.2 Driver=/usr/lib/x86_64-linux-gnu/odbc/libtdsodbc.so [ODBC Driver 18 for SQL Server] Description=Microsoft ODBC Driver 18 for SQL Server Driver=/opt/microsoft/msodbcsql18/lib64/libmsodbcsql-18.0.so.1.1 UsageCount=1 Create a MS SQL Server datasource in /etc/odbc.ini according to example below: [ODBC Data Sources] MSSQLQGIS = ODBC Driver 18 for SQL Server [MSSQLQGIS] Driver=ODBC Driver 18 for SQL Server Description=QGIS Sql Server Server=tcp:<mssql host name/ip>,1433 TrustServerCertificate=Yes Make sure Driver and the value after datasource name match the name of driver listed in /etc/odbcinst.ini Test your connection with isql command template: isql -v e.g.: isql -v MSSQLQGIS jhon pwd321 Rename, delete or backup files /usr/local/etc/odbc.ini and /usr/local/etc/odbcinst.ini Create symbolics links to odbc ini files: sudo ln -s /etc/odbcinst.ini /usr/local/etc/odbcinst.ini sudo ln -s /etc/odbc.ini /usr/local/etc/odbc.ini In GIS Desktop, add a MSSQL connection as the example bellow:

max_connections = 500000 No! That the max simultaneous connections. Recommend 1000 until you can demonstrate a need for more. Also lower max_user_connections. 10k node js instances If that doesn't choke MySQL, it will choke the webserver. If this is a "stress test", then dial it back. When you find how big a burst you can handle, then ask how you will get that many jobs across the network, through only 64 cores, into the web server's queue, etc. A more realistic test is to crank it up from, say 100, until things saturate and it all goes to hell in a handbasket. nothing executes for a long time MySQL's logic is to give each connection a fair share. The result is that all connections take "forever" to finish. Would you send 10K people into a grocery store all at the same time? Space them out; then measure "completions per second". Another tip. It is best to throttle the thundering herd at the webserver. by 1000 at a time it somehow operates much better and does not hangs I see you have figure out what I just said.

IIRC there is no way with apt directly, but you can more manually as in the answer to this question: https://askubuntu.com/a/482936 The process would be: Install the dependencies Get and unpack the package with apt-get download ; sudo dpkg --unpack *.deb Edit /var/lib/dpkg/info/.postinst (the linked answer just deletes it, but there may be other tasks you still require it to perform) Complete the instead with sudo dpkg --configure ; sudo apt-get install -yf #To verify/fix dependencies That final step might be sufficient to allow you to skip installing dependencies beforehand in step 1, if that it the case then there is also the advantage that they'll be automatically removed if you remove pg and nothing else requires them. A manual approach like this might be fine for a one-off, and personally when upgrades happen the post-install script won't see the need to run something like initdb as things are already configured being the point where that is needed. If you need this a lot, as part of a product install perhaps, then it could be cumbersome, the other options then are to have a script to undo what initdb does after the fact, or maintain your own apt repo containing modified versions of this package (which in itself is a chunk of admin).

From what I read in the man page of pg_upgradecluster, there might be a typo in your command. Here is the synopsis from the man page: pg_upgradecluster [-v newversion] oldversion name [newdatadir] Either keep -v and explicitly add the new version number : pg_upgradecluster -V -v 14 13 main /srv/local/postgresql/data/14 or remove -v altogether (will default to the latest available version) : pg_upgradecluster -V 13 main /srv/local/postgresql/data/14

The protocol changes of MySQL-8.0 replication and some of its syntax aren't compatible with any Mariadb version. Recommend looking for options where both master and replica are the same version.

there are multiple tools to backup and restore mysql faster like innobackupex , mysqlbackup , mydumper , mysqlpump. Personally innobackupex , mysqlbackup should be an ideal choice for databases in TBs. else you can try out my dumper as well. mysqldump is not a recommended solution for huge databases in 100s+ GBs

Appears to be a bug with 8.0.27: https://bugs.mysql.com/bug.php?id=105288

I wouldn't suggest making a 16.04 image since that was EOL as of April 2021. You can search the docker hub for "ubuntu 16.04" and find several instances of it $ docker pull ubuntu:16.04 Trying to pull repository docker.io/library/ubuntu ... 16.04: Pulling from docker.io/library/ubuntu 58690f9b18fc: Pull complete b51569e7c507: Pull complete da8ef40b9eca: Pull complete fb15d46c38dc: Pull complete Digest: sha256:0f71fa8d4d2d4292c3c617fda2b36f6dabe5c8b6e34c3dc5b0d17d4e704bd39c Status: Downloaded newer image for docker.io/ubuntu:16.04 and then run it with: $ docker run -it --rm ubuntu:16.04 /bin/bash root@b912d2c0db04:/# cat /etc/os-release NAME="Ubuntu" VERSION="16.04.7 LTS (Xenial Xerus)" ID=ubuntu ID_LIKE=debian PRETTY_NAME="Ubuntu 16.04.7 LTS" VERSION_ID="16.04" HOME_URL="http://www.ubuntu.com/" SUPPORT_URL="http://help.ubuntu.com/" BUG_REPORT_URL="http://bugs.launchpad.net/ubuntu/" VERSION_CODENAME=xenial UBUNTU_CODENAME=xenial and you can use FROM ubuntu:16.04 in your docker files to reference it. The 16.04 after the colon in the name identifies which version you're pulling down, if you don't specify it, there's some convention that defaults to latest, which would be 20.04, until sometime in April 2022.

Yes, when your terminal closes the stdout file descriptor for that process closes as well and it does not have where to write. First thing which would make me nervous is that you do not store the output to a file, so you are NOT doing any backups. You have to store the backup somewhere. One way how to do it to redirect the output to a file: mysqldump > backup_file_name.sql - you will see not output on the terminal, but you will see the file growing until the backup is ready. You can also use programs like screen or tmux for "keeping the term open" for the program. When you connect back, you can re-attach your terminal to that output. But again - do not backup to screen. When you want to see the output while storing it also to a file you can use tee: mysqldump | tee backup_file.sql - it will split the output and write it both to terminal and to file. Writing to terminal is really slow and you should not do it anyway. If you backup an AWS RDS instance, it is already has some automatic backup and you can trigger manual ones via UI or programatically. If you backup mysql running on your instance and you backup it onto the same instance it is not a very good backup after all. You should then copy that file to s3 or somewhere.

After https://github.com/ipfs/go-ds-s3/issues/213 in the GitHub of https://github.com/ipfs/go-ds-s3 , got to know from https://github.com/ipfs/go-ds-s3/issues/213#issuecomment-999061181 that Ah, I see. At the moment, plugins only work on 64bit Linux for the pre-built binaries (because they're built on 64bit linux and building go-ipfs with CGO support for foreign architectures is tricky). For now, you'll have to build go-ipfs from source or use the 64bit version (or use the go-ipfs docker container). I've filed an issue to support this in our build system ( https://github.com/ipfs/distributions/issues/546 ).

I hit this question trying desperately to figure out why Visual Studio wasn't appearing as a capability. It turns out my installation of Visual Studio on the build machine required a restart. However because I has installed the Azure Pipeline agent before restarting the machine, the capability wasn't registered with Azure DevOps, so subsequent restarts didn't help. I had to uninstall the azure pipelines agent from the build machine and remove the agent from my pool. When I reinstalled the agent (after a reboot of the machine) then the Visual Studio capability was present.

It's almost certainly a false positive if you've installed the snap from a reputable (e.g. the official snap outlet by Canonical). Furthermore, it's Windows executables and Windows malware - which should never be executed on a Ubuntu system anyway. It's simply packed in the library because of convenience. The reason you can't remove it is that Snap's is a read only file system image. It's not meant to have parts of it removed.