Cloud SQL minor patch upgrade not working for MySQL - mysql

As per release notes I should be able to upgrade the minor patch of the database, which by default is 8.0.26 in newly fresh instances:
May 26, 2022
Cloud SQL for MySQL now supports minor version 8.0.29. To upgrade your existing instance to the new version, see Upgrade the database minor version.
I triggered a minor patch upgrade using GCP CLI for MySQL. The command output is successful but the database patch didn't change. Used the following command:
$ gcloud sql instances patch mysqldb
The following message will be used for the patch API method.
{"name": "mysqldb", "project": "myproject", "settings": {}}
Patching Cloud SQL instance...done.
Updated [https://sqladmin.googleapis.com/sql/v1beta4/projects/myproject/instances/mysqldb].
It didn't upgrade, so I restarted the MySQL instance, and even after that the version remained 8.0.26.

This is expected because when you execute gcloud sql instances patch mysqldb this will do nothing about an upgrade because actually you're not setting what to patch.
If you look at the body sent to the API it is almost "empty"
{"name": "mysqldb", "project": "myproject", "settings": {}}
Moreover, in the docs you link it mentions that to upgrade the instance you should specify the new version.
gcloud sql instances patch mysqldb --database-version=MYSQL_8_0_29
which results in
{"databaseVersion": "MYSQL_8_0_29", "name": "mysqldb", "project": "myproject", "settings": {}}

Related

Problem with adding tables with TypeOrm and Nest.js

I am backend amatheur, you can see my project repo here. Today I added author entity and noticed that no table was added on data base. I deleted data-base completly but after that even one table wasn't created.
This is how my ormconfig.json looks:
"type": "mysql",
"host": "localhost",
"port": 8889,
"username": "root",
"password": "root",
"database": "Library",
"entities": ["dist/**/*.entity{.ts,.js}"],
"synchronize": false
}
I am launching mySql by MAMP (I am using MacOS).
as MySQL is RDBMS (Relational Database) you must perform migrations every time you create or modify existing Entities. To automate the migration process I would suggest doing what TypeORM says in the docs. Now in the docs, they describe how to do migration description on your own. But in this section TypeORM says it is possible to automate the migration code. There you should see this piece of CLI code:
typeorm migration:generate -n PostRefactoring
Let me explain the code above. typeorm is the CLI command to refer to typeorm-related tools. migration:generate is for generating the migration code. -n PostRefactoring is the naming of the migration file where the migration code is placed.
Obviously in your ormconfig.json, you didn't include the entity and migration files folder.
"migrations": [
// string can contain regular expressions
'your/path-to/entities/*.ts', // sample: 'src/modules/*.entity.ts'
],
"cli": {
// string can contain regular expressions here too
migrationsDir: 'src/migrations',
}
After generating the migration file which contains the information for the database to update and/or create, you easily run:
typeorm migration:run
The code above automatically finds the latest updates in the migrations folder and apply the updates to your connection db.
Hope it helped you.

Configuring Apache drill for Cassandra

I am trying to configure Cassandra with Drill. I used the same approach given on the link: https://drill.apache.org/docs/starting-the-web-ui/.
I used the following code for New Storage Plugin:
{
"type": "cassandra",
"hosts": [
"127.0.0.1"
],
"port": 9042,
"username": "<username>",
"password": "<password>",
"enabled": false
}
I have attached the Screenshot here.
But I'm getting the following error:
Please retry: Error (invalid JSON mapping)
How can I resolve this?
All the code :
Git: https://github.com/yssharma/drill/tree/cassandra-storage
Patch: https://gist.github.com/yssharma/2581ae8a97c559b2677f
1. Get Drill: Lets get the Drill source
$ git clone https://github.com/apache/drill.git
2. Get Cassandra Storage patch/Download the Patch file from:
https://reviews.apache.org/r/29816/diff/raw/
3. Apply the patch on top of Drill
$ cd drill
$ git apply --check ~/Downloads/DRILL-92-CassandraStorage.patch
$ git apply ~/Downloads/DRILL-92-CassandraStorage.patch
4. Build Drill with Cassandra Storage & export distribution to /opt/drill
$ mvn clean install -DskipTests
$ mkdir /opt/drill
$ tar xvzf distribution/target/*.tar.gz --strip=1 -C /opt/drill
5. Start Sqlline.
That it we have finished with the Drill build and installation – and its time we can start using Drill.
$ cd /opt/drill
$ bin/sqlline -u jdbc:drill:zk=local -n admin -p admin
Drill-Sqlline
Hit ‘show schemas‘ to view existing schemas.
Drill-Sqlline-schemas
6. Drill Web interface
You should be able to see the Drill web interface on localhost:8047, or whatever your host/port is.
Use this as your config:
{
"type": "cassandra",
"config": {
"cassandra.hosts": [
"127.0.0.1",
"127.0.0.2"
],
"cassandra.port": 9042
},
"enabled": true
}
Also, if this doesnt work, know that they are working on a plugin for it now: https://github.com/apache/drill/pull/1960
I'll give an update here as well. We're doing some serious refactoring of the how Drill works with storage plugins. Specifically, we're working to incorporate the Calcite Adapter1 for Cassandra. The reason for this is that the hard part of storage plugins isn't the connection, it's the optimizations. Calcite already does query planning for Drill and already implemented a bunch of these adapters which means that the work of figuring out all the optimizations (AKA pushdowns) is largely done.
In the case of Cassandra/Scylla, this is particularly important because some filters should be pushed down to Cassandra, and some should absolutely not be pushed down. The adapters also include aggregate pushdowns--something which no Drill plugins currently do. Again the point of this is that once we commit this, the connector should work VERY will with Cassandra/Scylla. We have one for ElasticSearch that is very near completion and once that's done the Cassandra plugin is next. If you have any suggestions/comments or other feedback, please post on the pull request linked above.
** UPDATE 11 April 2021: Cassandra/Scylla Plugin Now Merged in Drill 1.19.0-SNAPSHOT **

Invalid Dockerrun.aws.json version, abort deployment

Why would I be getting invalid for this? Version 1 works fine but for some reason I can't get this to load.
{
"AWSEBDockerrunVersion": 2,
"containerDefinitions": [
{
"name": "islandsound_vowpal_wabbit_test",
"image": "islandsound/vowpal_wabbit_test",
"memory": 128,
"portMappings": [
{
"hostPort": 26542,
"containerPort": 26542
}
]
}
]
}
AWSEBDockerrunVersion version 2 is not supported by single container platforms, create an environment with a multi container platform and deploy to it.
To create a multi container platform from the CLI, you can run: eb create --elb-type application -p "64bit Amazon Linux 2018.03 v2.15.2 running Multi-container Docker 18.06.1-ce (Generic)"
Answer is here:
multicontainer vs single container Dockerrun version
... the issue is because the environment created is using a "Single
Container" platform ...
If you want to run a multi-container docker instance, you must select it when creating your environment.
Through AWS portal
Platform: Docker
Platform branch: Multi-container Docker running on 64bit Amazon Linux
Platform version: (recommended)

Updating issue using Redmine API

I'm trying to make a little app which updates redmine issues. To start with I wanted to test the API calls to make sure I knew what I'm doing and already hit a wall.
I fired up postman with a PUT
URL
http://address:port/issues/1.json
headers:
Content-Type:application/json
X-Redmine-API-Key:MYKEY
X-Redmine-Switch-User:MYUSERNAME
body:
{"issue": { "id":"5729", "subject": "This change happens", "status": { "id": "1", "name": "This change is ignored" } } }
However when I hit send and look in redmine only the subject has been updated, the status doesn't change. I can see also that the last updated field updates to the current time/date.
I've seen several answers to questions like this already, but the solution always seems to be adding the content type to the header... and I've already got that.
Am I missing something obvious?
Here is my redmine environment if relevant:
Environment:
Redmine version 2.5.1.stable
Ruby version 1.9.3-p0 (2011-10-30) [i386-mingw32]
Rails version 3.2.17
Environment production
Database adapter PostgreSQL
SCM:
Subversion 1.8.13
Mercurial 3.4
Git 1.9.5
Filesystem
Redmine plugins:
clipboard_image_paste 1.8
redmine_backlogs v1.0.6
redmine_ckeditor 1.0.16
redmine_dashboard 3.0.0.dev0
redmine_issue_checklist 2.0.5
redmine_questions 0.0.5
redmine_release_notes 1.3.1
redmine_repobrowser 1.3.0
redmine_user_specific_theme 0.0.1
redmine_wiki_extensions 0.6.3
redmine_wiki_lists 0.0.3
According to http://www.redmine.org/projects/redmine/wiki/Rest_Issues#Updating-an-issue, it looks like you should only pass in the status id, as "status_id". Could you try something like this?
{"issue":
{
"id":"5729",
"subject": "This change happens",
"status_id": "1"
}
}

Composer hanging while updating dependencies

I tried updating a Laravel project I'm working on today using composer update
But it hung on Updating dependencies (including require-dev)
So I tried things like updating composer, dump-autoload, but nothing seemed to work. Then I ran it in verbose mode: composer update -vvv
And I noticed it hung while reading this json:
Reading path/to/Composer/repo/https---packagist.org/provider-cordoval$hamcrest-php.json from cache
I tried searching for cordoval/hamcrest-php on packagist.org and couldn't find it. This isn't listed as a dependency in my composer.json
Searching through my vendor folder, I notice the mockery/mockery package I use requires hamcrest/hamcrest-php, but I can't find anything that makes any reference to cordoval.
Any idea what's wrong and how I can fix it so that I can do the update?
Here's my composer.json:
{
"name": "laravel/laravel",
"description": "The Laravel Framework.",
"keywords": ["framework", "laravel"],
"license": "MIT",
"require": {
"laravel/framework": "4.2.*",
"iron-io/iron_mq": "dev-master",
"phpunit/phpunit": "4.2.*",
"mockery/mockery": "dev-master",
"xethron/migrations-generator": "dev-master",
"mailgun/mailgun-php": "dev-master"
},
"autoload": {
"classmap": [
"app/commands",
"app/controllers",
"app/models",
"app/database/migrations",
"app/database/seeds",
"app/tests/TestCase.php"
]
},
"scripts": {
"post-install-cmd": [
"php artisan clear-compiled",
"php artisan optimize"
],
"post-update-cmd": [
"php artisan clear-compiled",
"php artisan optimize"
],
"post-create-project-cmd": [
"php artisan key:generate"
]
},
"config": {
"preferred-install": "dist"
},
"minimum-stability": "stable"
}
Update
I've tried removing some of the packages from my composer.json, including the "mockery/mockery" package. The only change it made was that Composer would hang on a different file.
After leaving Composer running like that for quite a long time, it finally exited with an error such as the following:
/path/to/ComposerSetup/bin/composer: line 18: 1356 Segmentation fault php "${dir}/composer.phar" $*
Not sure what to do about that...
In my case, it was simply taking a very long time on my 8GB ram Mac. To check the progress and verify that it is going through the dependencies, run composer in verbose mode. This was an approach I missed in the question so worth re-stating here.
composer update -vvv
So it turns out the problem was with php's xdebug extension. After disabling it in my php.ini, composer ran without any problems.
And just to note, the hang-up wasn't actually occurring while reading files from the cache. It was the step right after where composer was trying to resolve dependencies. It just never finished that step and never printed the output. That's why no matter what I did, it always appeared to be stuck reading a file from the cache.
1st of all : Check firewall and proxy connections. If everything is ok but composer is still hanging try to clear composer cache:
composer clear-cache
https://getcomposer.org/doc/03-cli.md#clear-cache
2nd option If these steps does not repair your composer then it's possible that the system does not have enough RAM memory available (I faced this problem and the symptomps were the same that you describe). At this point you have two options:
a) Increase memory (Virtual Machines or Docker) : Your container or VM needs more available memory. Follow this guide: https://stackoverflow.com/a/44533437/3518053
b) Generate swap file (Linux) : Try creating a swap file to provide more memory:
(Above commands are from composer killed while updating)
free -m
mkdir -p /var/_swap_
cd /var/_swap_
#Here, 1M * 2000 ~= 2GB of swap memory
dd if=/dev/zero of=swapfile bs=1M count=2000
mkswap swapfile
swapon swapfile
chmod 600 swapfile
echo "/var/_swap_/swapfile none swap sw 0 0" >> /etc/fstab
#cat /proc/meminfo
free -m
Some times it is stuck because it is trying to use HTTP instead of https so just run this
composer config --global repo.packagist composer https://packagist.org
Working for me.
First Run command for auto load, then clear cache and run update.
composer dump-autoload
php artisan cache:clear
php artisan view:clear
composer update
For me the issue was with xDebug. I was using IDE's terminal, and the debugger was listening to incoming connections (as always). Turning the listening off (without requiring to disable the extension) solved the issue.
this worked for me:
composer self-update
I solved it by running command NOT IN VS CODE TERMINAL
I found this in another article, I found that doing the following below worked. It seemed to be a cache/download issue into the composer packages cache.
composer update -vvv
Then doing the following:
Add or edit your composer file to have these settings.
"repositories": [
{
"type": "composer",
"url": "https://packagist.org"
},
{ "packagist": false }
]
Restart your system.
I faced the same problem today. Going by advice, turned off xdebug, but did not help. Verified all files were present. Restarted my system, and it worked.
Check if you are running the minimum required php version
Compare with the specified required php version in the composer.json file
Open terminal run
php -v
Cross check in composer.json file see example below
"require": {
"php": "^7.1.3",
}
check the path of [xdebug] zend_extension = "file/path" in php.ini
I solved it by editing php.ini file in order to set de cacert required for ssl verification:
Download the file http://curl.haxx.se/ca/cacert.pem
Edit php.ini to set the pat:
[openssl]
; The location of a Certificate Authority (CA) file on the local filesystem
; to use when verifying the identity of SSL/TLS peers. Most users should
; not specify a value for this directive as PHP will attempt to use the
; OS-managed cert stores in its absence. If specified, this value may still
; be overridden on a per-stream basis via the "cafile" SSL stream context
; option.
openssl.cafile=C:\web\certs\cacert.pem
curl.cainfo=C:\web\certs\cacert.pem
Try again
Personally, I discovered using free that my system had 0kb of swap storage. Creating a 1GB swap file using https://linuxize.com/post/create-a-linux-swap-file/ solved the problem instantly.
My problem solved with: Change the wifi (I use my phone) - Waiting (about 5 minutes)
Here is the output.
Creating a "magento/project-community-edition" project at "/tmp/exampleproject"
Installing magento/project-community-edition (2.4.5-p1)
- Installing magento/project-community-edition (2.4.5-p1): Loading from cache
Created project in /tmp/exampleproject
Loading composer repositories with package information
Warning from https://repo.packagist.org: Support for Composer 1 is deprecated and some packages will not be available. You should upgrade to Composer 2. See https://blog.packagist.com/deprecating-composer-1-support/
Info from https://repo.packagist.org: #StandWithUkraine
Updating dependencies (including require-dev)
After waiting I saw the following output:
Updating dependencies (including require-dev)
Package operations: 546 installs, 0 updates, 0 removals
- Installing laminas/laminas-dependency-plugin (2.4.0): Loading from cache
Not sure what is the reason but I also run the following commands.
To diagnose the problem you should run the following:
composer diagnose
If you get OK from each line (it should be a warning but not important I had to), That means there is no problem with the composer. Try to switch wifi and do not forget to wait!!!