Do you mean making a backup?
If yes sql server can do backups locally or on a shared folder so you have to setup a SMB share on your laptop and make it accessible to the service user of sql server.
If you are remote you have to pick it up from local disks in tipical ways like RDP + cut and paste or FTP. Or you can eventually 'dump' on a Azure storage and the ...
I would say the best practice would be to ensure that one node is always still running, when the others have stopped normally. (systemctl stop mysql/mariadb)
Then restart one of the previously stopped nodes, and when that restarted node reports in logfiles that it connected to the running old node, and that it's ready to serve connections, you may restart ...
Had the same error (47106) - the reason was that SQL Servers (SQL01 and SQL02) were running under local accounts (e.g. NT Service\MSSQLServer) and therefore granting connect permissions were required.
CREATE LOGIN [DOMAIN\SQL02$] FROM WINDOWS
GRANT CONNECT ON ENDPOINT::Hadr_endpoint TO [DOMAIN\SQL02$];
CREATE LOGIN [DOMAIN\SQL01$] FROM ...
In SQL Server you use BACKUP and RESTORE commands for this. These both read and write files relative to the server, not the client. So you'll need to write the backup to a storage location accessible to both SQL Server instances. Backups can be written to and read from the local filesystem, SMB shares, or Azure Blob Storage.
second with this
an error occurred when the nodes were disconnected without order, as in my cluster, my main node is not connecting anymore.
erro of mysql:
[ERROR] WSREP: It may not be safe to bootstrap the cluster from this node. It was not the last one to leave the cluster and may not contain all the updates. To force cluster bootstrap with this ...
ZFS, etc, are not the main problems. (See Comments for a rebuttal on ZFS.)
Use InnoDB, not MyISAM.
Fix the indexes in postmeta, as discussed here: http://mysql.rjweb.org/doc.php/index_cookbook_mysql#speeding_up_wp_postmeta
Avoid index prefixing. (The above link discusses that, too.)
(If you must use MyISAM, then the indexes recommended ...
Don't worry. Unless memory gets swapped back in from swap, there is no problem. You can reduce vm.swappiness even more, down to 0, but if the system still swaps without memory pressure, it is just a Linux oddity. Again, don't worry unless you see high disk activity that indicates that memory is swapped in.
When running SQL Server in a container you'll want to use either bind mounts or named volumes to persist the databases.
By using either bind mounts or named volumes what you're doing is separating out the data from the SQL instance so that if a container has an issue and needs to be removed, you can spin up another one and mount the databases into it.
The error just means that the shared_pool ran out of free space. This can be caused by many things, mostly application related. Make sure your shared_pool has a minimum size needed to run your application.
Sometimes it helps to increase the shared_pool_reserved_size so larger objects can be loaded in there.
You should tell them the way you generated the dump, since it is somewhat unusual. One obvious problem may be that they tried a decompression program that does not understand GNU zip.
I recommend to use the custom format:
pg_dump -F c -U postgres -f outfile.dmp $x
That can be restored with pg_restore, and it is automatically compressed.
Since you didn't specify the -h option, PostgreSQL connects via local Unix socket. This is governed by the local entry in pg_hba.conf. Hence you are authenticated with "peer" authentication. But since you are not operating system user test, peer authentication fails.
To get PAM authentication, connect with -h 127.0.0.1.